Зачем использовать Redux вместо Facebook Flux?

Автор Redux здесь!

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

Принципиальной разницы в Redux нет, но я считаю, что некоторые абстракции проще или, по крайней мере, можно реализовать, которые было бы сложно или невозможно реализовать во Flux.

Состав редуктора

Возьмем, к примеру, пагинацию. Мой пример Flux + React Router обрабатывает разбивку на страницы, но код для этого ужасен. Одна из причин, по которой это ужасно, заключается в том, что Flux делает неестественным повторное использование функций в разных хранилищах. Если два хранилища должны обрабатывать разбиение на страницы в ответ на разные действия, они либо должны наследоваться от общего базового хранилища (плохо !, вы замыкаетесь на определенном дизайне, когда используете наследование), или вызываете внешнюю функцию из обработчика событий, которая должна каким-то образом работать с частным состоянием хранилища Flux. Все это грязно (хотя определенно в сфере возможного).

С другой стороны, в Redux нумерация страниц естественна благодаря составу редуктора. Это редюсеры, так что вы можете написать фабрика редукторов, которая генерирует редукторы разбиения на страницы, а затем используйте его в дереве редукторов. Ключ к тому, почему это так просто, заключается в том, что в Flux хранилища являются плоскими, а в Redux редукторы могут быть вложены через функциональную композицию, точно так же, как компоненты React могут быть вложены друг в друга.

Этот шаблон также включает замечательные функции, такие как отсутствие пользовательского кода отменить/повторить. Можете ли вы представить, что подключение Undo/Redo к приложению Flux состоит из двух строк кода? Едва. С Redux это так — опять же благодаря шаблону композиции редуктора. Я должен подчеркнуть, что в этом нет ничего нового — это шаблон, впервые созданный и подробно описанный в Elm Architecture. который сам находился под влиянием Flux.

Рендеринг сервера

Люди прекрасно выполняли рендеринг на сервере с помощью Flux, но, учитывая, что у нас есть 20 библиотек Flux, каждая из которых пытается сделать серверный рендеринг «более простым», возможно, у Flux есть некоторые шероховатости на сервере. Правда в том, что Facebook не занимается серверным рендерингом, поэтому они не очень беспокоятся об этом и полагаются на экосистему, чтобы упростить ее.

В традиционном Flux хранилища — это синглтоны. Это означает, что трудно разделить данные для разных запросов на сервере. Не невозможно, но тяжело. Вот почему большинство библиотек Flux (а также новые Flux Utils) теперь предлагаем вам использовать классы вместо синглтонов, чтобы вы могли создавать экземпляры хранилищ для каждого запроса.

Есть еще следующие проблемы, которые вам нужно решить в Flux (либо самостоятельно, либо с помощью вашей любимой библиотеки Flux, такой как Flummox или Alt):

• Если магазины являются классами, как мне создавать и уничтожать их с помощью диспетчера по запросу? Когда я регистрирую магазины?
• Как гидратировать данные из хранилищ, а затем повторно гидратировать их на клиенте? Нужно ли для этого реализовывать специальные методы?

По общему признанию, фреймворки Flux (не ванильный Flux) имеют решения этих проблем, но я нахожу их слишком сложными. Например, Flummox просит вас реализовать serialize() и deserialize() в ваших магазинах. Alt решает эту проблему лучше, предоставляя takeSnapshot(), который автоматически сериализует ваше состояние в дереве JSON.

Redux идет еще дальше: поскольку существует только одно хранилище (управляемое множеством редюсеров), вам не нужен какой-либо специальный API для управления (ре)гидратацией. Вам не нужно «сбрасывать » или «гидратные» магазины — есть только один магазин, и вы можете прочитать его текущее состояние или создать новый магазин с новым состоянием. Каждый запрос получает отдельный экземпляр хранилища. Подробнее о серверном рендеринге с помощью Redux.

Опять же, это тот случай, когда что-то возможно как в Flux, так и в Redux, но библиотеки Flux решают эту проблему, вводя массу API и соглашений, а Redux даже не нужно ее решать, потому что у него нет этой проблемы в первое место благодаря концептуальной простоте.

Опыт разработчиков

На самом деле я не собирался делать Redux популярной библиотекой Flux — я написал ее, когда работал над своим выступлением ReactEurope. на горячую перезагрузку с путешествием во времени. У меня была одна главная цель: сделать возможным изменение кода редуктора на лету или даже «изменить прошлое», вычеркивая действия, и видеть, как пересчитывается состояние.

Я не видел ни одной библиотеки Flux, способной это сделать. React Hot Loader также не позволяет вам это сделать — фактически он ломается, если вы редактируете хранилища Flux, потому что не знает, что с ними делать.

Когда Redux необходимо перезагрузить код редуктора, он вызывает replaceReducer(), а приложение работает с новым кодом. Во Flux данные и функции запутаны в хранилищах Flux, поэтому вы не можете «просто заменить функции». Более того, вам придется каким-то образом перерегистрировать новые версии в Dispatcher, чего в Redux даже нет.

Экосистема

Redux имеет богатую и быстрорастущую экосистему. Это связано с тем, что он предоставляет несколько точек расширения, таких как промежуточное ПО. Он был разработан с учетом таких вариантов использования, как логирование, поддержка Promises, Observables, маршрутизация, проверки разработчиков на неизменяемость, постоянство и т. д., имея в виду. Не все из них окажутся полезными, но приятно иметь доступ к набору инструментов, которые можно легко комбинировать для совместной работы.

Простота

Redux сохраняет все преимущества Flux (запись и воспроизведение действий, однонаправленный поток данных, зависимые мутации) и добавляет новые преимущества (легкая отмена-повтор, горячая перезагрузка) без внедрения Dispatcher и регистрации в магазине.

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

В отличие от большинства библиотек Flux, поверхность Redux API крошечная. Если вы удалите предупреждения разработчиков, комментарии и проверки работоспособности, это составит 99 строк. Нет сложного асинхронного кода для отладки.

Вы действительно можете прочитать его и понять весь Redux.

См. также мой ответ о недостатках использования Redux по сравнению с Flux.

В Quora кто-то говорит:

Во-первых, на React можно писать приложения без Flux.

Также эта визуальная диаграмма, которую я создал для быстрого просмотра обоих, возможно, быстрый ответ для людей, которые не хотят читать все объяснение: < /а>

Из документов Redux:

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

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

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

С этой сложностью трудно справиться, поскольку мы смешиваем два понятия, о которых человеческому разуму очень трудно рассуждать: мутация и асинхронность. Я называю их Mentos и Coke. Оба могут быть хороши по отдельности, но вместе они создают беспорядок. Такие библиотеки, как React, пытаются решить эту проблему на уровне представления, удаляя как асинхронность, так и прямые манипуляции с DOM. Однако управление состоянием ваших данных остается за вами. Здесь на помощь приходит Redux.

Следуя по стопам Flux, CQRS и Event Sourcing, Redux пытается сделать изменения состояния предсказуемыми, накладывая определенные ограничения на то, как и когда могут происходить обновления. Эти ограничения отражены в трех принципах Redux.

Также из документов Redux:

Основные концепции
Redux сам по себе очень прост.

Представьте, что состояние вашего приложения описывается как простой объект. Например, состояние приложения todo может выглядеть так:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

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

Чтобы что-то изменить в состоянии, вам нужно отправить действие. Действие — это простой объект JavaScript (заметьте, мы не вводим никакой магии?), который описывает, что произошло. Вот несколько примеров действий:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

Обеспечение того, чтобы каждое изменение описывалось как действие, позволяет нам иметь четкое представление о том, что происходит в приложении. Если что-то изменилось, мы знаем, почему это изменилось. Действия — это хлебные крошки того, что произошло. Наконец, чтобы связать состояние и действия вместе, мы пишем функцию, называемую редуктором. Опять же, в этом нет ничего волшебного — это просто функция, которая принимает состояние и действие в качестве аргументов и возвращает следующее состояние приложения. Было бы сложно написать такую ​​функцию для большого приложения, поэтому мы пишем более мелкие функции, управляющие частями состояния:

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

И мы пишем еще один редюсер, который управляет полным состоянием нашего приложения, вызывая эти два редуктора для соответствующих ключей состояния:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

Это в основном вся идея Redux. Обратите внимание, что мы не использовали API-интерфейсы Redux. Он поставляется с несколькими утилитами для облегчения этого шаблона, но основная идея заключается в том, что вы описываете, как ваше состояние обновляется с течением времени в ответ на объекты действия, и 90% кода, который вы пишете, — это обычный JavaScript без использования Redux. себя, свои API или любую магию.

Лучше всего начать с прочтения этого поста Дэна Абрамова, в котором он обсуждает различные реализации Flux и их компромиссы во время написания редукса: Эволюция Flux Frameworks

Во-вторых, на этой странице мотиваций, на которую вы ссылаетесь, на самом деле не столько обсуждаются мотивы Redux, сколько мотивы Flux (и React). Три принципа более специфичны для Redux, хотя по-прежнему не касаются отличий реализации от Стандартная архитектура Flux.

По сути, Flux имеет несколько хранилищ, которые вычисляют изменение состояния в ответ на взаимодействие UI/API с компонентами и транслируют эти изменения как события, на которые могут подписаться компоненты. В Redux есть только одно хранилище, на которое подписывается каждый компонент. IMO кажется, по крайней мере, что Redux еще больше упрощает и унифицирует поток данных, унифицируя (или уменьшая, как сказал бы Redux) поток данных обратно к компонентам, тогда как Flux концентрируется на унификации другой стороны потока данных - вид на модель.

Я один из первых пользователей и реализовал среднее одностраничное приложение с использованием библиотеки Facebook Flux.

Поскольку я немного опоздал с разговором, я просто укажу, что, несмотря на мои самые большие надежды, Facebook, похоже, считает свою реализацию Flux доказательством концепции, и она никогда не получала того внимания, которого заслуживает.

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

Мы решили, что в дальнейшем будем переходить на Redux, и я предлагаю вам сделать то же самое ;)

Вот простое объяснение Redux вместо Flux. В Redux нет диспетчера. Он опирается на чистые функции, называемые редюсерами. Ему не нужен диспетчер. Каждое действие обрабатывается одним или несколькими редюсерами для обновления одного хранилища. Поскольку данные неизменяемы, редукторы возвращают новое обновленное состояние, которое обновляет хранилище

Для получения дополнительной информации Flux и Redux

Я довольно долго работал с Flux и теперь довольно долго использую Redux. Как указал Дэн, обе архитектуры не так уж отличаются. Дело в том, что Redux делает вещи проще и чище. Помимо Flux, он учит вас нескольким вещам. Например, Flux — прекрасный пример однонаправленного потока данных. Разделение проблем, когда у нас есть данные, их манипуляции и слой представления. В Redux у нас то же самое, но мы также узнаем о неизменяемости и чистых функциях.

От нового сторонника реакции/редукции, мигрировавшего с (несколько лет) ExtJS в середине 2018 года:

После того, как я скатился вниз по кривой обучения избыточности, у меня возник тот же вопрос, и я подумал, что чистый поток будет проще, чем OP.

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

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

Это было гораздо более интуитивно понятным, чем ванильный редукс, он вырезал 90% шаблона и сократил 75% времени, которое я тратил на редукс (что-то, что, я думаю, должна делать библиотека), я был в состоянии запустить пару корпоративных приложений сразу.

Он также работает с теми же инструментами сокращения. Это хорошая статья, в которой рассказывается о некоторых преимуществах.

Так что для всех, кто пришел к этому сообщению SO в поисках «простого редукса», я рекомендую попробовать его как простую альтернативу редуксу со всеми преимуществами и 1/4 шаблона.

Согласно этой статье: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

Вам лучше использовать MobX для управления данными в вашем приложении, чтобы повысить производительность, а не Redux.