С GraphQL вы можете отказаться от Redux

Оригинальное название: Как GraphQL может заменить Redux

«Что?» — воскликнула ты. «GraphQL — это серверный язык запросов, а Redux — клиентская библиотека управления состоянием. Как эти две нерелевантные вещи могут заменить друг друга?!»

Это хороший вопрос. Сидите твердо и поддерживайте, потому что я отвечу прямо и оспорю ваши три взгляда.

Мигрировать на реакцию

Прежде чем ответить, позвольте мне рассказать вам предысторию этой истории. Еще в 2016 г. наша фронтенд-группа в Pathwright перенесла клиентский код из стека технологий Backbone & Marionette в React.Для пользовательского интерфейса декларативная модель гораздо более интуитивно понятна, чем шаблон MVC.

В то время для нас, и это чувство дыхания свежего воздуха, а теперь и много раз есть такое чувство.

Всё так гармонично, кроме государственного управления. Чтобы реализовать управление состоянием, мы быстро начали использовать архитектуру Flux, которая поначалу казалась нам хорошей.

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

В итоге у нас есть несколько хороших и чистых декларативных компонентов React и слой данных, который превращается в кучу мусора. Он содержит кучу действий, редукторов, асинхронного промежуточного ПО, денормированных бизнес-данных и логики.

Это кажется очень неправильным.

Начните работу с GraphQL

Затем мы начали использовать GraphQL. Первоначально мы реализовали GraphQL на панели инструментов с доступом к нескольким источникам данных и быстро влюбились в него, знаете ли, этот сценарий — кошмар для реализации с RESTful API. Было ощущение, что мы впервые встречаемся с React. С энтузиазмом мы работали сверхурочно, чтобы написать код, и, наконец, всего за две недели запустили новый сервер GraphQL!

Затем мы начали заменять некоторые из наших REST API на GraphQL, и это до сих пор прекрасно.

Побочный эффект (сага), который приносит нам этот подход, заключается в том, что компоненты пользовательского интерфейса, использующие GraphQL, больше не нуждаются в хранилище. В начале мы также предварительно реализовали store, action и другие вещи, а в конце удалили их, потому что обнаружили, что им нечего делать.

три удивительных факта

Этот результат привел нас к осознанию 3 удивительных фактов:

1. Большая часть нашего кода управления состоянием предназначена для слияния или изменения данных, полученных из разных REST API (редукторов, селекторов, действий и т. д.);

2. Большая часть наиболее сложного кода управления состоянием заключается в том, чтобы асинхронные данные из разных источников загружались в правильном порядке и доставлялись по указанным маршрутам (saga, middleware, thunk и т. д.);

3. На самом деле, почти для всего, кроме этого, например, для состояния компонента пользовательского интерфейса, достаточно напрямую использовать собственное управление состоянием React.

Как хорошо было бы раньше использовать GraphQL! Мы льем слезы раскаяния за то, что опоздали...

Затем мы удалили много кода, и это было хорошо.

Итак, поговорим о GraphQL и Redux.

Мое более раннее заявление о том, что «GraphQL заменит Redux», может немного ввести в заблуждение, GraphQL действительно заменяет REST API и в результате делает большую часть нашего кода управления состоянием бесполезным.

Эти библиотеки управления состоянием действительно бесполезны, когда клиент может управлять содержимым и форматом состояния в соответствии со своими потребностями, и для этого ему нужен только запрос к серверу.

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

Тогда разговор может выглядеть так:

Многое из того, что делают Redux и сопутствующая библиотека управления побочными эффектами, — это упрощение работы в левой части диалога.

Я думаю, что для большинства клиентских приложений GraphQL может полностью заменить роль Redux.

Это не значит, что Redux бесполезен сам по себе, это отличная библиотека. Модель управления состоянием, представленная Redux, останется надолго.

Например, в некоторых случаях вы не можете вмешиваться в стек серверных технологий, вы можете использовать только REST API, тогда Redux может вам очень помочь.

Есть также случаи, когда вам нужно управлять очень сложным состоянием, которое необходимо отслеживать и контролировать для сохранения, например, некоторые низкоуровневые работы, такие как кэширование на стороне клиента, автономная синхронизация данных и т. д. Redux также полезен для них. Фактически, некоторые популярные библиотеки GraphQL, такие как Apollo, могут использовать Redux в качестве кеша.

но...

Если вы можете заменить REST на GraphQL, вы должны это сделать.Это позволяет значительно снизить сложность управления состоянием клиентского приложения, уменьшить фокус клиентского кода и сосредоточиться на отображении данных в компонентах пользовательского интерфейса.

Конечно, вы по-прежнему можете использовать Redux в своем коде на стороне клиента, просто вы не полагаетесь на него, как раньше. Кроме того, наличие GraphQL дает вам возможность удалить половину вашего кода, что действительно здорово.

Дальнейшее чтение:

Сокращение нашего кода Redux с помощью React Apollo:

https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a

Оригинальный адрес:

https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d