Ответ 1

Редукс автор здесь!

Я хотел бы сказать, что вы собираетесь использовать следующие компромиссы:

• Вам нужно научиться избегать мутаций. Flux не отключен в отношении мутирования данных, но Redux не любит мутации, и многие пакеты, дополняющие Redux, предполагают, что вы никогда не мутируете состояние. Вы можете обеспечить это с помощью пакетов только для dev, таких как redux-immutable-state-invariant, использовать Неизменяемый .js, или доверяйте себе и своей команде писать не-мутирующий код, но это то, что вам нужно знать, и это должно быть сознательным решением, принятым вашей командой.

• Вам придется тщательно выбирать свои пакеты. Хотя Flux явно не пытается решить "близкие" проблемы, такие как отменить/повторить, persistence, или форм, у Redux есть такие точки расширения, как промежуточное ПО и средства для улучшения хранилища, и он создал молодую, но богатую экосистему. Это означает, что большинство пакетов являются новыми идеями и еще не получили критической массы использования. Вы можете зависеть от чего-то, что будет явно плохой идеей несколько месяцев спустя, но пока сложно сказать.

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

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

См. также мой ответ на преимущества использования Redux.

Ответ 2

Оба Redux и Flux требуют значительного количества кода шаблона для покрытия многих распространенных шаблонов, особенно тех, которые включают асинхронную выборку данных. В документации Redux уже есть несколько примеров сокращения шаблонов: http://redux.js.org/docs/recipes/ReducingBoilerplate.html. Вы можете получить все, что вам может понадобиться, из библиотеки Flux, такой как Alt или Fluxxor, но Redux предпочитает свободу над функциями. Это может быть недостатком для некоторых разработчиков, потому что Redux делает определенные предположения относительно вашего состояния, которое может быть непреднамеренно проигнорировано.

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

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

Ответ 3

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

Ответ 4

Flux и Redux.,.

Redux не является чистой реализацией Flux, но определенно вдохновлен Flux. Большая разница в том, что он использует один магазин, который обертывает объект состояния, содержащий все состояние для вашего приложения. Вместо создания таких хранилищ, как вы делаете в Flux, вы будете писать функции редуктора, которые изменят одно состояние объекта. Этот объект представляет все состояние вашего приложения. В Redux вы получите текущее действие и состояние и вернете новое состояние. Это означает, что действия являются последовательными, а состояние является неизменным. Это доводит меня до самого очевидного con в Redux (по-моему).

Почему неизменность?

Есть несколько причин для этого:
1. Когерентность - состояние хранилища всегда изменяется редуктором, поэтому легко отслеживать, кто что изменит.
2. Производительность - потому что она неизменна, Redux нужно только проверить, было ли предыдущее состояние! == текущее состояние, и если это нужно сделать. Не нужно зацикливать состояние каждый раз на определенный рендеринг.
3. Отладка - новые удивительные концепции, такие как Отключение времени путешествия и Hot Reloading.

UPDATE: если это недостаточно убедительно, посмотрите Lee Byron отличный разговор о Неизменяемые пользовательские интерфейсы.

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

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

После этого я должен признать, что Redux - это то, где JS будет развиваться в будущем (как для написания этих строк).

Ответ 5

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

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

Redux имеет Three Principles, который может очень хорошо вносить Redux, и они также являются основным различием между Redux и Flux.

Единственный источник истины

Состояние всего вашего приложения хранится в дереве объектов внутри один магазин.

Это упрощает создание универсальных приложений, поскольку состояние вашего сервер может быть сериализован и гидратирован в клиенте без дополнительных кодирования. Одно дерево состояний также упрощает отладку или проверять заявку; он также позволяет вам сохранять ваши приложения в развитии, для более быстрого цикла разработки. Некоторые функциональность, которую традиционно трудно реализовать - Например, Undo/Redo - может внезапно стать тривиальным для реализации, если все ваше состояние хранится в одном дереве.

console.log(store.getState())

/* Prints
{
  visibilityFilter: 'SHOW_ALL',
  todos: [
    {
      text: 'Consider using Redux',
      completed: true,
    },
    {
      text: 'Keep all state in a single tree',
      completed: false
    }
  ]
}
*/

Состояние доступно только для чтения

Единственный способ изменить состояние - испустить действие, объект описывая, что произошло.

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

store.dispatch({
  type: 'COMPLETE_TODO',
  index: 1
})

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',
  filter: 'SHOW_COMPLETED'
})

Изменения выполняются с помощью чистых функций

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

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

function visibilityFilter(state = 'SHOW_ALL', action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo, index) => {
        if (index === action.index) {
          return Object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)

для более подробной информации посетите здесь

Ответ 6

Redux требует дисциплины в отношении неизменности. Что-то, что я могу порекомендовать, это ng-freeze, чтобы вы знали о какой-либо случайной мутации.

Ответ 7

Насколько я знаю, Redux вдохновлен флюсом. Flux - это архитектура, подобная MVC (контроллер вида модели). Facebook представляет поток из-за проблемы масштабируемости при использовании MVC. Так что поток - это не реализация, а просто концепция. На самом деле излишним является реализация потока.