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

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

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

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

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

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

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

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

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

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

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

Flux и Redux . , ,

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

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

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

ОБНОВЛЕНИЕ: если это не было достаточно убедительным, наблюдайте, как Ли Байрон отлично говорит о неизменных пользовательских интерфейсах .

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

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

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

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

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

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

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

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

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

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

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)

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

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

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