Полная информация о том, почему нам был нужен Redux в прошлом, и почему мы не нуждаемся в нем больше.
В последние несколько лет интернет-технологии смещаются в сторону интерфейсных JavaScript-фреймворков как метода улучшения пользовательского опыта для веб-приложений и мобильных приложений. Это потрясающе 🔥 Мне лично нравится гибкость, которую дают нам эти фреймворки.
Но неужели гибкость зашла слишком далеко…
Чтобы действительно понять, почему это может быть так, давайте перемотаем время назад и посмотрим, как создавались приложения до того, как появились фреймворки JavaScript.
⏳ Земля до JavaScript…
До разработки первых нескольких интерфейсных фреймворков (наиболее известными из которых являются AngularJS, Backbone и Ember) мы использовали просто для визуализации шаблонов на сервере, а затем для отправки полной HTML-страницы в браузер. Популярные фреймворки в то время включали:
- Django (Python) - первый выпуск 21 июля 2005 г .; ~ 13 лет назад.
- Ruby on Rails - первый выпуск 13 декабря 2005 г .; ~ 13 лет назад.
- Symphony (PHP) - первый выпуск 22 октября 2005 г .; ~ 13 лет назад.
Эти фреймворки вращались вокруг концепции MVC, известной как структура разработки приложений Модель-Представление-Контроллер. Модели демонстрировали «форму» данных, представления были шаблонами, которые показывали, как «отображать» данные, а контроллеры «связывали» их.
Я имею в виду, что был JavaScript, но мы говорим больше о слайдерах jQuery и некоторых странных библиотеках, которые делали бы совершенно ненужные эффекты отскока…
У приложения, построенного на этих фреймворках, было несколько проблем, но в целом; все работало очень хорошо. Однажды Райану Далю пришла в голову потрясающая идея начать использовать JavaScript как нечто большее, чем просто инструмент для создания глупых анимаций. Он разработал первую версию Node.js, которая позволила разработчикам писать JavaScript вне браузера и вместо этого на сервере.
- Node.js - первый выпуск 27 мая 2009 г .; ~ 9 лет назад.
Внезапно люди начали ценить мощь JavaScript и его способность выполнять большую работу с помощью небольшого количества кода. Это открыло другим разработчикам возможности JavaScript. Люди не только начали создавать более мощные инструменты для Node.js, но также начали создавать интересные интерфейсные фреймворки. Это начало эффект снежного кома в разработке JavaScript в течение следующих нескольких лет:
- Express.js (back-end) - первый выпуск 16 ноября 2010 г .; ~ 8 лет назад.
- Backbone.js (интерфейс) - первый выпуск 12 октября 2010 г .; ~ 8 лет назад.
- AngularJS (интерфейс) - первый выпуск 20 октября 2010 г .; ~ 8 лет назад.
- Ember.js (интерфейс) - Первый выпуск 8 декабря 2011 г .; ~ 7 лет назад.
Это положило начало серьезному сдвигу в способах разработки приложений. Фреймворк MVC, который ранее обрабатывался исключительно сервером, разделен на два сегмента - сервер, который обрабатывал MC (или модели и контроллеры), и клиент переднего плана, который обрабатывал представление, используя одну из вышеупомянутых фреймворков JavaScript. В некоторых из этих ранних фреймворков они также включали в представление модели и контроллеры. Двойные модели и контроллеры, некоторые на интерфейсе, некоторые на сервере - теперь это похоже на большой объем кода! 🙇🏽
🤦 У Facebook возникла проблема
Все были очень довольны. Все работало и было относительно легко понять, когда вы потратили пару часов на то, чтобы обдумать это.
Потом что-то случилось…
Facebook быстро рос и стал крупнейшим веб-приложением в мире. Как вы понимаете, быть крупнейшим веб-приложением сопряжено с некоторыми проблемами. Одна из самых больших головных болей была; отображение правильного количества уведомлений в строке заголовка.
Когда люди начали делать что-то в приложении Facebook, ожидалось, что эти маленькие уведомления будут обновляться соответствующим образом. Так было нечасто. Я не знаю, использовали ли вы Facebook в то время или помните, но эти уведомления всегда были неправильными ... Проблема заключалась в том, что веб-приложениям было трудно распознавать изменения в одной части приложения (например, когда вы читали сообщение) и показать это изменение в другой области (например, уменьшить количество непрочитанных уведомлений на одно).
Это не худшая вещь в мире - и ее можно решить, перезагрузив страницу, - но у Facebook было более 1000 увлеченных сотрудников, и они решили, что пора что-то с этим сделать. Поэтому они переосмыслили, как интерфейсный фреймворк обрабатывает информацию, и решил создать свой собственный; Реагировать.
- React (front-end) - первый выпуск в марте 2013 года; ~ 5 лет назад.
Этот новый фреймворк хорошо справлялся с рендерингом HTML, но был очень простым и не давал подробных сведений о том, «как» разрабатывать приложения. Таким образом, они также запустили Flux, который в конечном итоге превратился в то, что мы называем Redux (Redo-Flux). Ниже представлено видео, которое было на сайте Flux еще в 2014/2015 гг. Видео пытается объяснить Flux и React.
🍐… Потом дела пошли грушей
Принцип работы Redux заключается в том, что он по сути хранит всю динамическую информацию приложения в одном объекте JavaScript. Когда когда-либо части приложения требовалось отобразить некоторые данные, оно запрашивало информацию с сервера, обновляло единственный объект JavaScript, а затем показывало эти данные пользователям. Храня всю информацию в одном месте, приложение всегда показывало правильную информацию, где бы вы ни искали. Тем самым была решена проблема уведомлений Facebook.
Так внезапно появилась новая структура для создания приложений; реализация React Redux. Facebook удалось решить свою проблему, и с тех пор все жили долго и счастливо ... не так ли?
✋ Не совсем.
Проблема в том, что люди (включая меня) начали использовать один объект для хранения всей своей информации - каждой части данных, предоставляемых сервером. Конечно, это позволяет поддерживать всю информацию в актуальном состоянии, но у него также есть 3 основных недостатка:
- Для нормальной работы требуется много дополнительного кода, который отнимает все ваше время.
- Сохраняя весь код в одном месте, вы также вводите идею «устаревших данных», что означает, что в вашем приложении могут появиться нежелательные данные из предыдущего состояния.
- Кривая обучения для новых разработчиков зашкаливала, и впоследствии интерфейсная веб-разработка стала очень трудной для освоения новыми разработчиками.
Нам удалось превратить относительно простую задачу отображения данных пользователям из нескольких простых шаблонов еще в 2005 году с фреймворками MVC в монолитные интерфейсные приложения с 10-кратным объемом кода на интерфейсе, чем на сервере. Например, я недавно разработал простое приложение и использовал WakaTime для измерения времени, которое я потратил на кодирование. Вот результаты:
- Фронтенд-репозиторий React Redux - 32 часа.
- Серверный репозиторий Express + Mongoose - 4 часа.
Ты серьезно ?? 🤯 Я потратил в 8 раз больше времени на интерфейс, чем на серверную часть. Давайте углубимся в причину, по которой требуется так много дополнительного кода. Вот пример шагов, которые мне нужно выполнить, чтобы добавить вызов базовой выборки данных (например, получение всех пользователей) в мой внешний репозиторий.
🚧 Warning: the following steps are super techy so don't worry if you get lost.
- Создайте компонент для отображения списка пользователей (здесь нет проблем).
- Создайте
fetchвызов API. - Добавьте новое поле в состояние.
- Добавьте новое действие, которое обновляет состояние данными.
- Добавьте новый метод преобразователя, который выполняет вызов выборки, а затем обновляет состояние, используя наши новые действия.
- Добавьте функцию преобразователя к нашему компоненту, используя
connect(), который обернет его в функцию диспетчеризации. - Извлеките данные из состояния Redux, снова используя
connect(). - Объявите функцию преобразователя и извлеченное поле данных в типах свойств моего компонента.
- Вызовите метод преобразователя в функции
componentDidMount(). - Наконец, визуализируйте данные в DOM.
Holy moly… 10 шагов… Вернувшись в старые добрые времена Ruby on Rails, все, что мне нужно было сделать, это передать данные моему HTML-шаблону и БУМ! Это дало бы тот же результат. Я понял, что нужно что-то изменить.
☝️ Новый подход
Redux отлично подходил для решения проблемы синхронизации вашего интерфейсного приложения, однако он приносил свои собственные проблемы (как упоминалось ранее). Когда вы думаете об этом; сколько дополнительных функциональных возможностей действительно дает нам Redux?
По сути, мы полностью переписали интерфейс, чтобы решить несколько тривиальных проблем…
Во всяком случае, Facebook тоже это осознал и фактически начал работать над новой технологией под названием GraphQL, чтобы помочь решить эту проблему. В настоящее время GraphQL - модное слово, но я не уверен, действительно ли кто-нибудь понимает, почему это так здорово.
GraphQL не похож на Redux. И снова Facebook представил потрясающий продукт, но не смог сформулировать, почему эта жемчужина продукта так чертовски важна; поэтому я потратил последние несколько минут на то, чтобы дать вам некоторый контекст.
Таким образом, GraphQL - это машина, а Redux - это лошадь.
Что? Как Redux - лошадь?
Причина, по которой я описываю их как лошадь и машину, заключается в том, что; Вы ни в коем случае не сочли бы лошадь похожей на машину - одна - живое животное с четырьмя ногами, а другая - машина с колесами. Однако они оба пытаются достичь одной и той же конечной цели, то есть получить человека туда, куда им нужно. Машина ездит по улицам и использует топливо, а лошадь - величественное животное, которое может перепрыгивать через камни. Оба имеют разные преимущества и варианты использования, но в целом; Автомобиль доставит вас к месту назначения намного быстрее, чем лошадь.
Итак, что такое GraphQL?
Официальные документы описывают GraphQL как «GraphQL - это язык запросов для API», что очень неясно. По сути, под языком запросов они подразумевают то, что он заменяет API потенциально сотнями конечных точек HTTP. Поскольку эта технология все еще молода, документация и вспомогательные технологии все еще немного сложны для понимания и как таковые; есть еще кривая обучения. В помощь вот пример.
GraphQL заменит такие конечные точки, как:
- ПОЛУЧИТЬ
/users/1234567890 - ЗАПИСЬ
/cars - PUT
/example/endpoints
С помощью настраиваемых запросов, которые вы создаете только тогда, когда они вам нужны. Например:
{
user(id: "1234567890") {
name,
email
}
}Вернусь:
{
"user": {
"name": "Luke Skywalker",
"email": "[email protected]"
}
}Но подождите - пользовательские запросы… На это уйдет много времени. ~ Ваши мысли.
На самом деле это не так. Причина в том, что; запрашивая только те данные, которые вам нужны, вам внезапно не нужно делать столько запросов к серверу, а это означает, что вам не нужно писать столько кода для обработки этих запросов к серверу. Таким образом, вы сэкономите массу времени на коде, который не нужно внедрять.
🤷 Но как это заменить Redux?
Еще один отличный вопрос, спасибо за вопрос. Проще говоря, нет. Однако он поощряет вас не хранить всю вашу информацию в единственном объекте, который вам предоставляет Redux. Это связано с тем, что каждый запрос специально разработан для получения данных только для одной части приложения, а не для всего. Было бы антипаттерном (и это просто нелогично) хранить информацию, относящуюся к отдельной части приложения, в источнике данных всего приложения.
Используя GraphQL, вы избавляетесь от зависимости от Redux и тем самым удаляете массу ненужного кода.
Также следует отметить следующее: Redux и GraphQL могут сосуществовать в приложении. Это полезно, поскольку вы можете постепенно интегрировать GraphQL в свое приложение Redux, если вы уже реализовали его. Вот несколько документов о том, как вы можете реализовать их вместе.
Тогда вы можете использовать Redux. Используйте его, чтобы решить несколько тривиальных задач и устранить все накладные расходы и проблемы, или заменить эти задачи чем-то другим.
Итак, что вы используете вместо этого?
В то время Redux был хорошим способом решения проблемы. Однако с момента своего создания индустрия веб-разработки значительно продвинулась вперед, и вместе с этим прогрессом последовали внедрение и улучшение в области веб-сокетов.
Веб-сокеты - это открытые соединения между сервером и клиентом, так что сервер может сообщить клиенту, когда конкретно обновлять. И угадай что? GraphQL поддерживает веб-сокеты прямо из коробки в форме подписок. Таким образом, мы можем использовать эти подписки для обновления частей нашего приложения, которые мы хотим синхронизировать.
Основное отличие в том, что; вместо того, чтобы клиент сообщал нам, что что-то нужно обновить (с помощью Redux), вместо этого наши серверы сообщают клиенту, что данные должны быть обновлены. Это дает нам тот же результат. Вот несколько примеров того, как вы можете реализовать веб-сокеты или подписки напрямую с помощью Mongodb или Mongoose.
🚀 Будущее выглядит потрясающе!
GraphQL какое-то время находился в разработке, но сейчас находится на той стадии, когда его можно удобно использовать в производственной среде. Я не буду лгать; документацию довольно сложно разобраться, и она требует хорошего предварительного понимания JavaScript и того, как работают серверы. Однако, если вы еще не совсем достигли цели - по крайней мере, вы знаете, к чему стремиться. Вот ссылка на популярный учебник.
Также существует множество полезных библиотек, которые помогут вам постепенно интегрировать его в существующие продукты. Не волнуйтесь, вам не нужно делать все сразу, библиотеки позволяют легко постепенно преобразовывать ваши приложения с течением времени. Apollo - одна из компаний, которые в настоящее время отлично справляются с этой задачей.
Вот и все. Я надеюсь, что эта статья помогла пролить свет на некоторые более сложные концепции.
Если вам понравилась эта статья, пожалуйста, дайте ей несколько аплодисментов (вы можете оставить до 50) или вы можете прокомментировать, если у вас есть какие-либо вопросы, я сделаю все возможное отвечать! 🙌
Подпишись на меня в Твиттере".
Спасибо!
Еще сообщения Джека Скотта.
