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

Поток (краткий обзор)

Прежде чем мы углубимся в это, я думаю, одна вещь, которую мы должны иметь в виду, двигаясь вперед, — это думать о текущем Flux и о том, как он в настоящее время справляется с масштабированием приложения со многими компонентами или множеством различных частей состояний, которыми необходимо управлять. Это довольно хороший выступление на React NYC: Scaling Flux, в котором рассматривается проблема и решение, к которому они приходят, не слишком далеко от того, что позволяют вам сделать Reflux и Redux, но в двух словах возникает большой вопрос: «Что мы делаем, когда у нас есть компоненты, которые имеют какое-то общее состояние, которое все они должны поддерживать? Как мы с этим справимся и масштабируем?». В конечном итоге ответ, к которому приходят многие из этих фреймворков, заключается в том, что нам нужна эта идея глобального состояния. Обе платформы неизбежно вводят некоторые схожие концепции для достижения этой цели, о которых мы поговорим ниже.

Поскольку мне нужно будет сослаться на сравнение Flux, я просто хочу показать краткий обзор работы Flux с изображением ниже:

Рефлюкс

В Reflux нет диспетчера, а View Components напрямую взаимодействуют через компоненты через действия.

+---------+       +--------+       +-----------------+
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦
+---------+       +--------+       +-----------------+
     ^                                      ¦
     +--------------------------------------+

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

class MyComponent extends Reflux.Component
{
    constructor(props)
    {
        super(props);
        this.state = {}; // our store will add its own state to the component's
        this.store = StatusStore; // <- just assign the store class itself
    }

    render()
    {
        var flag = this.state.flag; // <- flag is mixed in from the StatusStore
        return <div>User is {flag}</div>
    }
}

У вас также есть возможность подключиться к нескольким хранилищам (есть свойство, которое, как мне кажется, называется stores, которое принимает массив, а Reflux также поставляется с возможностью редактирования mapStoreToState на случай, если вы хотите конкретно контролировать, как хранилища передают состояние компонентам.

Естественно, поскольку вы используете компонент, с которым поставляется Reflux, вам, вероятно, следует прочитать их документацию по Reflux Component и как правильно создавать компоненты с учетом этого

Последнее, что я отмечу, выше, я упомянул, что большой проблемой является глобальное состояние и как это решается. У Reflux есть Reflux.GlobalState, который можно внести как пока вы устанавливаете идентификаторы в своих магазинах. Ссылка выше содержит гораздо больше подробностей, но с этим вы можете получить к ним доступ через Reflux.GlobalState.[StoreID].[property], где StoreID — это идентификатор, который вы назначаете магазину, а property — это фактическая часть состояния, к которой вы хотите получить доступ.

Редукс

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

1. Единственный источник правды
2. Состояние доступно только для чтения
3. Изменения вносятся с помощью чистых функций

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

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

Интересно отметить, что в то время как в Reflux и Flux были действия, когда в хранилищах вы слушали и определяли, какое изменение состояния нужно сделать, хранилища в Redux просто отправляют сообщение с нужной полезной нагрузкой, а затем это проходит через гигантский оператор switch. чтобы определить, что он должен делать с деревом состояний — это то, что они называют редьюсером. Это ничем не отличается от того, как Flux имеет reduce в своих магазинах, но Redux вырывает эту концепцию как свою собственную вещь, и ваше глобальное дерево состояний проходит через rootReducer (Redux поставляется с хорошей функцией для вас, чтобы combineReducers и сделать rootReducer). Хороший способ представить это так: вы отправляете изменение в гигантское дерево состояний, а затем любые изменения, которые вы хотите, сокращаются или сжимаются до желаемого конечного состояния. Это на самом деле влияет на то, как Redux настраивает множество вещей, поэтому он сообщает React, как выполнять повторную визуализацию (при условии, что вы используете Redux с React).

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

Таким образом, основные различия действительно

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

Надеюсь, это поможет лучше понять основные различия между ними.

Flux, Reflux и Redux (и многие другие подобные библиотеки) — это разные способы управления поперечными данными.

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

Flux — это оригинальное решение, разработанное Facebook (как и React), оно мощное, но, вероятно, не самое простое и читабельное. Reflux был разработан частично, чтобы сделать его проще и понятнее. Основное отличие состоит в том, что в Reflux каждый фрагмент данных имеет собственное хранилище и действия, что делает его очень читабельным и легким для записи. К сожалению, Reflux уже не так активно развивается, автор ищет сопровождающих. Но в целом я бы сказал, что Reflux — более элегантная альтернатива Flux.

Redux — еще одно решение, ставшее пока самым популярным. Его преимущество заключается в том, что он предоставляет вложенные хранилища с неизменяемым содержимым, так что вы можете легко реализовать предыдущую/следующую функцию и иметь сквозные действия, которые влияют на многие части хранилища. Недостатки redux заключаются в том, что он довольно многословен и имеет гораздо больше понятий, чем Flux или Reflux. Для тех же базовых действий потребуется гораздо больше кода, а асинхронная реализация не самая чистая. Это, безусловно, мощный и масштабируемый.

Вот ссылка, в которой об этом говорится более подробно: http://jamesknelson.com/what-flux-implementation-should-i-use-with-react/