Apollo Client Cache против Redux

Question

Я пытаюсь перейти с Redux Store на использование Apollo Client Cache , который поставляется с Apollo Graphql Client.

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

В Redux мы должны писать действия, типы и действия по отправке на основе ответа, полученного от побочного эффекта, и устанавливать данные в хранилище с помощью редукторов, что автоматически выполняется клиентом Apollo.

Вопросы :

1) Каковы преимущества перехода с Redux на Apollo Client Cache?

2) Есть ли что-то, о чем я должен беспокоиться перед миграцией в клиентский кеш Apollo?

Answer 1

Ты сравниваешь яблоки с апельсинами. Да, на высоком уровне и redux, и apollo-client предоставляют вам возможность управлять глобальным состоянием приложения. Однако redux позволяет вам создать предсказуемый контейнер состояния, который изменяется в ответ на определенные вами действия. Это означает, что redux предлагает:

• Предсказуемость. Редукторы - это чистые функции - при одинаковом состоянии и действиях редуктор всегда будет давать один и тот же результат.
• Тестируемость. Опять же, поскольку редукторы - это просто функции, их просто протестировать модульно.
• Масштабируемость. Поскольку избыточность вынуждает вас организовывать свой код определенным образом c, это делает ваш код более понятным. Даже если ваша кодовая база растет, ваш код все еще доступен для отладки и понятен другим разработчикам.

Дан Абромов указывает на ряд других преимуществ :

• Сериализация действий пользователя и присоединение их вместе со снимком состояния к автоматическим отчетам об ошибках, чтобы разработчики продукта могли воспроизводить их для воспроизведения ошибок.
• Передача объектов действий по сети для реализации совместной работы. окружения без драматических изменений c изменяют способ написания кода.
• Сохраняют историю отмен или реализуют оптимистичные c мутации без драматических изменений c изменяют способ написания кода.
• Путешествуйте между историей состояний в процессе разработки и переоценивайте текущее состояние из истории действий при изменении кода, например TDD.
• Предоставляйте полный инструментарий для проверки и контроля инструментам разработки, чтобы разработчики продукта могли можно создавать собственные инструменты для своих приложений.
• Предоставить альтернативу Интерфейсы при повторном использовании большинства бизнес-логи c.

Да, redux поставляется с большим количеством шаблонов. Однако и вы, и ваше приложение, и ваша команда потенциально могут получить много преимуществ от его использования, помимо простого управления глобальным состоянием. С другой стороны, если вы не видите ценности в функциях, предоставляемых приставкой, или не думаете, что они стоят косвенности и сложности, которые redux добавляет к вашему коду, не используйте его. Если все, что вам нужно, это способ управления глобальным состоянием приложения, то вы можете использовать apollo-client или какую-либо другую библиотеку или просто использовать Context API и useReducer ловушку для развертывания своего собственного решения.

Клиент Apollo использование директивы @client для управления локальным состоянием очень удобно, особенно если вы уже используете библиотеку для запросов к API GraphQL. Возможность легко декорировать результаты запроса производными полями - это просто. Возможность использовать один и тот же API для запросов к вашему серверу и запросов к локальному состоянию делает для хорошего DX. Но apollo-client не может заменить redux, потому что в конце дня две библиотеки делают совершенно разные вещи по совершенно разным причинам.

Answer 2

Я думаю, что вы хорошо здесь отметили: «С Redux мы должны писать действия, типы и действия диспетчеризации на основе ответа, полученного от побочного эффекта, и устанавливать данные в хранилище с помощью редукторов, что делает Apollo. Клиент автоматически. "

Для побочных эффектов Redux является обязательным, а Apollo - декларативным. Декларативный код обычно короче, поскольку вы делегируете logi c в библиотеку / framework.

---

Даниэль Рарден (David Rearden) подчеркнул, что сравнение Redux и клиентского кэша Apollo похоже на яблоки и апельсины. Яблоки и апельсины здесь - это различные типы состояний , в частности удаленные и локальные состояния. К сожалению, Redux побуждает нас обрабатывать все состояния одинаково.

Я бы использовал кеш Apollo для состояния, которое необходимо извлекать, обновлять и изменять на сервере. Я хотел бы воспользоваться более легкими инструментами, такими как React's Context API, для предотвращения детализации, глобального состояния приложения и хуков для бизнес-логики c (например, useReducer / useState).

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

Answer 3

миграция на apollo имеет смысл только в том случае, если ваш бэкэнд позволяет выполнять вызов graphql, мы перевели наш проект с избыточного на apollo, и он получился очень хорошим.

Прочитайте этот блог тоже из этого блога мы решили перейти на * 1005