Как GraphQL заменяет Redux

Как GraphQL заменяет Redux

От автора: Ты удивишься: «Что? GraphQL — это язык запросов на стороне сервера. Redux — это клиентская библиотека управления состояниями. Как можно использовать вместо Redux GraphQL?» Хороший вопрос. Лучше тебе сесть, потому что я собираюсь ответить на него.

Переключение на React

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

И тогда и сейчас это было глотком свежего воздуха.

Все было красиво, за исключением поддержки нашего приложения. Мы быстро перешли к архитектуре Flux, и это стало важным улучшением. Концепции циркулярного потока данных и единственного источника правды были философски обоснованными и, по крайней мере, более здравыми, чем подход, ориентированный на моделирование, в большинстве библиотек MVC.

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

У нас были эти красивые декларативные компоненты React со слоем данных, который стал «крысиным гнездом» действий, редукторов, асинхронного промежуточного программного обеспечения и де-нормированных бизнес-данных/логики.

Все это было очень неправильно.

Переход на GraphQL

Вот когда мы попробовали GraphQL. Мы начали с его внедрения на новой информационной панели, которая объединила множество разных источников данных (это было бы кошмаром — проделывать такое с нашими RESTfull API) и вскоре влюбились. Это было похоже на открытие React в первый раз. Энтузиазм был достаточно высок, и мы получили доступ к нашему недавно выпущенному серверу GraphQL всего за две недели!

Вскоре после этого мы начали заменять кучу REST API с помощью GraphQL, и это было потрясающе.

Один из побочных эффектов (sagas?) заключается в том, что пользовательские интерфейсы, использующие новые конечные точки GraphQL, больше не нуждались в магазинах. Мы начали, как обычно, с новыми магазинами, действиями и т. д., Но в итоге удалили их, потому что с ними просто нечего было делать.

Три потрясающих реализации

Это привело к трем поразительным, но очевидным, реализациям для нас:

Большая часть кода управления состояла в объединении и мутации данных из дискретных ресурсов REST в правильную форму пользовательского интерфейса (редукторы, селектор, действия и т. Д.).

Большая часть самых сложных состояний управления пытались управлять асинхронным характером получения всех этих данных в правильном порядке для определенного маршрута (sagas, middleware, thunks и т. Д.).

Практически все остальное, состояние пользовательского интерфейса, отлично работало с обычным старым статусом React.

Мы говорили: «черт побери!», закидывая в банку монету за каждое ругательство. Тогда мы удалили большое количество кода. Это было здорово.

Итак, о GraphQL и Redux …

Заголовок статьи не совсем верный (но он ведь заставил вас кликнуть?). То, что мы действительно заменили — это REST API, а затем в результате оказалось, что большая часть кода управления состоянием больше не нужна.

Когда клиент может контролировать точную форму состояния, которое ему требуется с сервера, и вернуть его обратно в один запрос, просто нет необходимости в библиотеках управления состоянием.

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

Так большая часть работы, выполняемой Redux и библиотеками управления побочными эффектами, упрощает верхний левый разговор.

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

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

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

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

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

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

Автор: Mark Johnson

Источник: //hackernoon.com/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: