интересно, в аполо же нет какого-нибудь колбэка перед запуском мутации, чтобы проверить, например, что-то в кэше и продолжить мутацию, либо остановить?

Ваш резолвер может выступать таким кешем ведь)

у нас достаточно тяжелые запросы, мы создаем еще один уровень хуков, где прячем всю логику - апдейт, ремув,  апдейт кеша и тд. вотчера на генерацию типов и хуков не добавляли нету необходимости. yну и мы еще сидим на 2 аполло)

Мы у себя используем typed document node. Вопрос почему вы не используете?

Ещё мы все запросы и мутации врапаем в хуки ручками и возвращаем нормализованные данные. Это упрощает нам жизнь если что-то меняется в схеме. Также гораздо проще рефакторить код.

Полностью отказались от локального стейта аполло. Есть гараздо проще альтернативы и работают гараздо быстрее, аполло кэш ну очень медленный, когда запросов становится много.

плюсую за typed document node, именно эти и юзаем. а что для стейта используете?

typed-document-node вы скорее всего с urql используете. С аполло клиентом он менее удобен.

У нас все запросы и фрагменты уникальны. К каждой компоненте идет свой набор "запчестей" графкуэль запросов. И эти запчасти всегда лежат рядом с компонентой, чтоб открывая папку сразу видеть насколько компонента и как зависит от сервера. Ну и изменения любой запчасти, не повлияет на другие компоненты, поэтому у нас рефакторинг тоже достаточно простой.

Аполло действительно тормознутый, но для большинства задач его хватает с лихвой. Там где большие таблицы, или идет частое обновление мы без кеша и нормализации юзаем. Но таких мест раз два и обчелся. У вас я так понимаю urql используется?

почитай https://evilmartians.com/chronicles/aborting-queries-and-mutations-in-react-apollo
обсуждение
https://github.com/apollographql/apollo-client/issues/4150

Jotai

интересно. удобна ли такая атомность для хранения больших данных с графкл?

апдейт кеша есть?

Нет мы не дублируем данные из кеша в локальный стейт. Только локальные поля. Могу привести реальный пример: есть массив из тысячи статей. Нам необходимо добавить чекбоксы к каждой статье. Самый очевидный вариант просто расширить тип статьи полем checked, но при таком подходе аполло кеш очень медленный когда нужно выделить все статьи или несколько статей. Что мы делаем, храним ids с клиентскими полями в jotai, пишем локальный резолвер в typePolicies - getArticleById. Каждый компонент статьи получает id и checked и вызывает getArticleById для получения данных с кеша. Убиваем 2 зайцев, убрали проблему с перформансом, переререндер происходит только там где надо. Раньше так делали на редаксе.

У тебя в видео есть кусок про improtReactHooksFrom. Где можно глянуть на твою имплементацию?

Вы не шарите фрагменты в приложении? Т.е. все фрагменты у вас уникальны?

отличнй пример, локальный резолвер в смысле через филд резолвер и @client директивой? Мы конечно с резолверами не заморачиваемся, у нас в кеше нету больших листов максимум 50 айтемов, но да, если надо селектить айтемы то в редаксе храним айдис

Да да филд резолвер

Спасибо)

хмм, так зачем вообще резолвер на чекед, если хранить айдихи в атоме. на бек отправляется скорее всего что-то типа {action: ‘remove’, ids: […]}

Резолвер не на чекед а на данные статьи которые в кеше

Т.е. чекед и айди в атоме, все остальное в кеше