От автора: Ты удивишься: «Что? 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
Источник: https://hackernoon.com/
Редакция: Команда webformyself.