Подтвердить что ты не робот

Какова основная разница в методе сокращения и рефлюкса при использовании приложения на основе реакции?

Недавно я провел предварительное исследование по созданию сайта электронной коммерции и обнаружил, что redux и reflux оба из флюсовой архитектуры в Facebook, и оба они популярны. Я смущен различием между ними.

Когда я должен использовать redux vs reflux и который является наиболее гибким на этапе разработки веб-приложения электронной коммерции?

4b9b3361

Ответ 1

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

Flux (Быстрый обзор)

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

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

введите описание изображения здесь

рефлюкс

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

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

В терминах того, как он отличает себя от Flux, не так уж много. Вы по-прежнему создаете свои собственные действия и создаете свои собственные магазины, и у вас все еще есть свои магазины, которые слушают действия. Я считаю, что наибольшая разница заключается в том, что для того, чтобы компоненты View отображали действия непосредственно в хранилище, а не через диспетчера, компоненты имеют свойство хранилища, которое происходит от расширения 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 и как правильно создавать компоненты с помощью это в виду

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

Redux

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

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

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

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

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

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

введите описание изображения здесь

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

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

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

Ответ 2

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

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

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

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

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