XZ
Size: a a a
2019 March 19
EW
обновлять кеш вроде бы как надо только в тех местах которые видны на странице в данный момент
XZ
но не стабильно(
XZ
@AlpacaGoesCrazy да, их много больше 15
EW
Тоесть у тебя 15 разных запросов на одни и теже данные на одной странице?
XZ
да, с разными параметрами и разные квери надо апдейтить еще зашквар удалять фк на удаленную модель -.-
2019 March 20
P@
Тогда положи эти данные в схеме на 1 уровень ниже и прикрути к ним глобальный айдишник.
Потом сможешь по глобальному айдишнику обновить во всех кверях данные
Потом сможешь по глобальному айдишнику обновить во всех кверях данные
P@
Ну это конечно бэкендеров надо просить сделать.
XZ
@nodkz я на двух стульях. Найс идея, спасибо. Но звучит как хак только. Надеюсь сделают что то типо этого : https://github.com/haytko/apollo-link-watched-mutation
P@
Это не хак. Ты просто выносишь общие часть в свой отдельный тип. И потом по айдишнику он обновляется в аполловском нормализованном сторадже. Где все данные из твоего графа хранятся в плоском виде. Т.е. ты используешь встроенный механизм работы стора.
P@
В Релее работает точно так же.
A
Это не хак это дичь)
P@
Мне наоборот apollo-link-watched-mutation кажется дичью если его использовать для обычных объектов. Но вот для списков он может быть полезен.
A
Можете закидать меня какахами но мой опыт говорит о том, что использовать кэш аполо как стейт приложения худшее архитектурное решение что я когда-либо принимал
NT
Можете закидать меня какахами но мой опыт говорит о том, что использовать кэш аполо как стейт приложения худшее архитектурное решение что я когда-либо принимал
почему?
A
почему?
Я счас пишу статейку на эту тему, поделюсь когда допишу. Тезисно - призводительность ниже, читаемость хуже, дебажить сложнее
NT
а что тогда лучше выбирать для связки с аполло ?)
A
Я за то чтобы оставить граф как апи, транспорт между фронтом и бекендом. Пихать его еще куда-то не дает столько профита сколько создает проблем