Открыть список
Как стать автором
Обновить

Комментарии 8

Спасибо за статью. Есть несколько вопросов:
1) Каким образом получилось полностью избавиться от redux? Пробовали apollo-link-state, но появляется много оверхеда (создать запрос, прочитать кеш, выполнить мутацию, записать в кеш).
2) Каким образом управляете частичной очисткой кеша? например пользователь оставил комментарий, поэтому надо не просто рефетчить текущий список, а и удалить из кеша счетчик комментариев у пользователя, например. А в другом месте начислить какие-то баллы за оставленный комментарий.
Спасибо за вопрос.
1 — apollo-link-state на самом деле спорное решение, ибо мешаем состояние с сервера и локальное. У нас глобальные состояния отдаются с бека — права, данные и тд, а остальное (промежуточное состояние формы, переключатели collapse объектов) храним локально в state компонента. 2 — для этого хорошо подходит update, когда можем сами обновлять локальные данные
1) банальный пример — корзина с продуктами: добавляем продукт на странице списка товаров — обновляем на странице с корзиной товаров. локальным стейтом тут не обойдешься, через сервер прогонять данные — не лучшее решение. конкретно в этом случае apollo-link-state подходит на 100%.
2) update хорош, но только когда у вас малое количество обновляемых данных. при росте приложения — растет количество мест, где надо думать об обновлении данных. открыли для себя `reFetchObservableQueries`, добавляет магии, но работает.

А каким образом решали вопросы с пагинацией (если она у вас есть)? Так же как на graphql.org описано со всякими там коннекшенами?


Мне вот этот момент не очень понравился и из-за этого пока решили не использовать GraphQL. А не понравился он тем, что если я запрашиваю коллекцию без пагинации (какая-то короткая коллекиця) то я должен запрашивать в одном виде (просто коллекцию), а если там есть пагинация (а пагинация появляется когда коллекция разрастается) то я должен запрашивать в другом виде (коллекция сама в каком-то отдельном элементе + "служебная информация").


Тот же вопрос по сортировке. Описание данной проблемы вообще не нашел. Проблема в том что когда отдаем коллекцию, то в UI должны показать как она была отсортирована, соотвественно информацию о сортировке нужно в доп. элементе отдавать. Ну и возникает та же проблема что и с пагинацией.

Спасибо за статью!
Вопрос: а была ли необходимость в создании селекторов (reselect?). Если да, то опишите пожалуйста в двух словах нюансы. Если нет — почему нет? :)
Спасибо за вопрос.
По своей сути, graphql запросы уже являются «селекторами», по этому необходимости в reselect не было. Если появляется потребность в reselect, то скорее всего у вас не правильно построен граф. По крайней мере, не получается придумать кейс, где он нужен.
Спасибо за ответ!
Но если предположить кейс — пересчет корзины или чего-то подобного на фронте (и теоретически достаточно «большого»). Каким образом в данном случае её правильно/рекомендуете пересчитать? К графу вроде как отношения быть не должно.
Зависит от того, как устроен graph — можно результирующие значения вынести в служебную информацию (тогда не надо будет все время вычислять), либо, да, использовать мемоизацию вычислений с помощью reselect/lodash.memoize/memoize-one etc… У нас такое используется (мемоизация) для форматирования graphql ответа, для «больших» селектов
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Местоположение
Россия
Сайт
ramblergroup.com
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре