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

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

прежде всего, совершенно возможно писать приложения с React без Поток.

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

но если вам все еще интересно узнать больше, читайте дальше.

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

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

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

С Redux docs:

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

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

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

эта сложность трудно обрабатывать, поскольку мы смешиваем две концепции это очень трудно для человеческого ума рассуждать о: мутации и асинхронность. Я называю их Ментос и кокаин. Оба могут быть большими, когда разделены, но вместе они создают беспорядок. Библиотеки, такие как React попытка решить эту проблему в слое view путем удаления обоих асинхронность и прямая манипуляция DOM. Однако, управление состоянием ваши данные оставлены на ваше усмотрение. Это где, я полагаю, придет.

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

и с Redux docs:

Основные Понятия
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;
  }
}

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

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

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

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

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

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

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

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

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

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

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

дополнительные сведения http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html

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

помимо технических аргументов, описанных в предыдущих ответах, ИМХО две важные причины:

• инструмент: Redux dev tool является удивительным инструментом, делает ваш разработчик / отладка опыт взрыва (машина времени, возможность экспортировать сеанс пользователя и воспроизвести его в локальной среде...).

• Stack overflow friendly: Redux получил более 51000 результатов по stackoverflow, flux 9000.