A
Сергей, похоже надо отдельно хранить
- Нотификации (записываются от разных триггеров)
- Пуш уведомлений (тоже от разных триггеров)
- Нотификации (записываются от разных триггеров)
- Пуш уведомлений (тоже от разных триггеров)
Size: a a a
2018 January 31
SP
возможно, так как у тебя пуш нотификация самодостаточная сущность
A
надеюсь она будет умной 🙂
D
Что думаете ребят?
2018 February 01
SP
ничего не думаю, я сейчас просто заставляю при отдаче ответа API проверять ответы на соответствие схемы и чуть что писать в лог
SP
дальше e2e тесты + чуть-чуть интеграционных сделают свое дело. Так же подумываю на тему статического анализа
SP
но тестить филды вот так как предлагают в статье - ну можно но удобно только для примитивных вещей
SP
это как тестить геттеры
SP
зачем если ты можешь типы проверить
KN
Ребят, а покидаете идей как неймспейсы запилить красиво?
Кейворд неймспейса:
1) namespace
2) package
3) module
4) ?
Кейворд импорта
1) use Def as Alias
2) using Def as Alias
3) import Alias from Def
4) ?
Кейворд неймспейса:
1) namespace
2) package
3) module
4) ?
Кейворд импорта
1) use Def as Alias
2) using Def as Alias
3) import Alias from Def
4) ?
KN
За основу взят: https://github.com/facebook/graphql/issues/163
SP
Ребят, а покидаете идей как неймспейсы запилить красиво?
Кейворд неймспейса:
1) namespace
2) package
3) module
4) ?
Кейворд импорта
1) use Def as Alias
2) using Def as Alias
3) import Alias from Def
4) ?
Кейворд неймспейса:
1) namespace
2) package
3) module
4) ?
Кейворд импорта
1) use Def as Alias
2) using Def as Alias
3) import Alias from Def
4) ?
я уже говорил тебе что это тупиковая ветвь?
SP
если тебя интересует именно модульность и разруливание конфликтов имен - то тебе нужны именно модули
SP
import {Foo, Bar} from 'my.graphql'SP
неймспейсы не нужны
KN