holyjs с докладом "Докручиваем ApolloClient до энтерпрайзной разработки".
Есть видео с прогоном секции лайф-коддинга из моего доклада:
https://www.youtube.com/watch?v=uXBr6IHDsvY&list=PLnieus7KgTVFRMDvVc0H4TMnv5CORMig0&index=1
Посмотрите кому интересен АполлоКлиент 3. Зацените как мы у себя на работе его используем (уже года полтора). Вы наверняка, что-то новое и интересное найдете для себя. Репо на гитхабе - https://github.com/nodkz/example-apollo3
Хотелось бы получить от вас фидбек, чтоб я успел до выступления поправиться:
- что было непонятно
- оговорок по видео конечно было много, но что прям я сказал такого, что можно назать "Соврал с большой буквы"
- что вызвало у вас Вау-эффект? (вдруг был такой момент)
- если вы с аполло более 2 лет: что вы нового узнали? (когда уже вроде все знаете, а тут раз и свежак)
- что бы посевотовали добавить или убрать
- ну и в целом как вам видосик?
Мой доклад будет на час (и наверное выйдет в паблик через полгода). Ну и потом еще будет дискуссионка часа на полтора (она к сожалению будет не под запись). Если подумываете купить билет, вот промокод со скидкой 10% – NODKZ2021JRGpc
Привет, а где фидбек оставлять?
можно смело в личку
норм, сжато и четко. у нас на проекте такой же подход на процентов 80-90%. Автоматизация 1 в 1
Может что добавить есть? Интересно в чем разница - в лкчшую или худшую сторону?
у нас достаточно тяжелые запросы, мы создаем еще один уровень хуков, где прячем всю логику - апдейт, ремув, апдейт кеша и тд. вотчера на генерацию типов и хуков не добавляли нету необходимости. yну и мы еще сидим на 2 аполло)
Мы у себя используем typed document node. Вопрос почему вы не используете? Ещё мы все запросы и мутации врапаем в хуки ручками и возвращаем нормализованные данные. Это упрощает нам жизнь если что-то меняется в схеме. Также гораздо проще рефакторить код. Полностью отказались от локального стейта аполло. Есть гараздо проще альтернативы и работают гараздо быстрее, аполло кэш ну очень медленный, когда запросов становится много.
плюсую за typed document node, именно эти и юзаем. а что для стейта используете?
typed-document-node вы скорее всего с urql используете. С аполло клиентом он менее удобен. У нас все запросы и фрагменты уникальны. К каждой компоненте идет свой набор "запчестей" графкуэль запросов. И эти запчасти всегда лежат рядом с компонентой, чтоб открывая папку сразу видеть насколько компонента и как зависит от сервера. Ну и изменения любой запчасти, не повлияет на другие компоненты, поэтому у нас рефакторинг тоже достаточно простой. Аполло действительно тормознутый, но для большинства задач его хватает с лихвой. Там где большие таблицы, или идет частое обновление мы без кеша и нормализации юзаем. Но таких мест раз два и обчелся. У вас я так понимаю urql используется?
интересно. удобна ли такая атомность для хранения больших данных с графкл?
Нет мы не дублируем данные из кеша в локальный стейт. Только локальные поля. Могу привести реальный пример: есть массив из тысячи статей. Нам необходимо добавить чекбоксы к каждой статье. Самый очевидный вариант просто расширить тип статьи полем checked, но при таком подходе аполло кеш очень медленный когда нужно выделить все статьи или несколько статей. Что мы делаем, храним ids с клиентскими полями в jotai, пишем локальный резолвер в typePolicies - getArticleById. Каждый компонент статьи получает id и checked и вызывает getArticleById для получения данных с кеша. Убиваем 2 зайцев, убрали проблему с перформансом, переререндер происходит только там где надо. Раньше так делали на редаксе.
У тебя в видео есть кусок про improtReactHooksFrom. Где можно глянуть на твою имплементацию?
Вы не шарите фрагменты в приложении? Т.е. все фрагменты у вас уникальны?
отличнй пример, локальный резолвер в смысле через филд резолвер и @client директивой? Мы конечно с резолверами не заморачиваемся, у нас в кеше нету больших листов максимум 50 айтемов, но да, если надо селектить айтемы то в редаксе храним айдис
https://github.com/nodkz/example-apollo3/blob/master/src/utils/extendApolloHooks.ts
Да да филд резолвер
хмм, так зачем вообще резолвер на чекед, если хранить айдихи в атоме. на бек отправляется скорее всего что-то типа {action: ‘remove’, ids: […]}
Вот репка с примером из видео https://github.com/nodkz/example-apollo3
Отличный кейс. У нас ребята похожим образом обходили проблему через readFragment
Да у нас квери и фрагменты привязаны строго к компонентам. Это именно то место, гле я ребятам говорю, что copy-paste это хорошо. Т.е. при редактировании требований к данным к компоненте, мы уверены, что ничего по соседству не сломаем. И не начнем тянуть где не надо лишние данные, когда добавим новое поле для доугой компоненты.
Обсуждают сегодня