Зависит от того, как устроен graph — можно результирующие значения вынести в служебную информацию (тогда не надо будет все время вычислять), либо, да, использовать мемоизацию вычислений с помощью reselect/lodash.memoize/memoize-one etc… У нас такое используется (мемоизация) для форматирования graphql ответа, для «больших» селектов
Спасибо за вопрос.
По своей сути, graphql запросы уже являются «селекторами», по этому необходимости в reselect не было. Если появляется потребность в reselect, то скорее всего у вас не правильно построен граф. По крайней мере, не получается придумать кейс, где он нужен.
Спасибо за вопрос.
1 — apollo-link-state на самом деле спорное решение, ибо мешаем состояние с сервера и локальное. У нас глобальные состояния отдаются с бека — права, данные и тд, а остальное (промежуточное состояние формы, переключатели collapse объектов) храним локально в state компонента. 2 — для этого хорошо подходит update, когда можем сами обновлять локальные данные
По своей сути, graphql запросы уже являются «селекторами», по этому необходимости в reselect не было. Если появляется потребность в reselect, то скорее всего у вас не правильно построен граф. По крайней мере, не получается придумать кейс, где он нужен.
1 — apollo-link-state на самом деле спорное решение, ибо мешаем состояние с сервера и локальное. У нас глобальные состояния отдаются с бека — права, данные и тд, а остальное (промежуточное состояние формы, переключатели collapse объектов) храним локально в state компонента. 2 — для этого хорошо подходит update, когда можем сами обновлять локальные данные