Альтернатива Redux

Недавно я начал изучать React, и я быстро столкнулся с проблемой раздутого родительского компонента, полного функций и состояний. Сначала я посмотрел на Flux, а затем посмотрел на Redux, но оба они казались действительно передовыми решениями.

Мне интересно, почему что-то вроде этого не сделано:

//EventPropagator.js
let EventPropagator = {
    registerListener(listenerObject){
        if (this.listeners == null)
            this.listeners = []
        this.listeners.push(listenerObject)
    },
    fireEvent(eventObject){
        let listenerList = this.listeners.filter(function(listener){
            return listener.eventType === eventObject.eventType
        })
        listenerList.forEach((listener) => {
            listener.callback(eventObject.payload)
        })
    }
}
export default EventPropagator

Чтобы использовать: компоненты просто registerListener и fireEvent:

//main.js
import EventPropagator from './events/EventPropagator'

EventPropagator.registerListener({
    "eventType": "carry_coconut",
    "callback": (payload) => {
        // actually carry coconut
        this.setState({"swallow_type": payload.swallow})
        console.log(payload)
    }
})
EventPropagator.fireEvent({
    "eventType": "carry_coconut",
    "payload": { "swallow": "african" }
})

Это позволит много развязки, и состояние может быть легко передано с помощью такого рода событий. Каковы недостатки этого подхода?

Ответы

Ответ 1

Вы должны попробовать MobX

MobX - это библиотека управления состоянием, которая использует преимущества декораторов и удаляет нежелательный код. Например, в mobx нет концепции reducers.

Надеюсь это поможет!

Ответ 2

Существует Reactn основанный на Reactn.
Это на несколько порядков проще в использовании, по сравнению с Redux. Проверьте https://www.npmjs.com/package/reactn и прочитайте блог Stover.

Ответ 3

Redux является продолжением стиля декларативного программирования React. Простым способом сопоставления вашей логики приложения с компонентами является использование чего-то вроде Backbone.React.Component, но с использованием redux позволит вам использовать все инструмента и промежуточного продукта. Кроме того, неопределенные переходы в приложениях делают отладку намного проще. Теперь я согласен с тем, что вам нужно много проводников и шаблонов, чтобы получить все равно.

Если вы хотите использовать redux, вы можете посмотреть что-то вроде redux-auto

Redux-auto: Redux упростил (с подходом plug and play)

Удаление кода шаблона при настройке хранилища и действий. Зачем? Эта утилита позволяет вам запускать и запускать Rudux за небольшую часть времени!

Теперь вы можете увидеть redux-auto: проект helloworld

Ответ 4

Если вы хотите воспользоваться всеми преимуществами Redux, используйте Redux.

Если вы хотите сохранить синхронизацию между компонентами React, используйте Duix.

Я создатель Duix. Я использую его в течение 1 года, и, наконец, я выпустил его несколько часов назад. Проверьте документ: https://www.npmjs.com/package/duix

Ответ 5

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

До тех пор, пока вы будете следовать шаблону архитектуры, подобному потоку (google it), вы действительно можете сделать это успешно с помощью только объектов javascript и Javascript для хранения данных вместе с системой событий.

Данные следует рассматривать как одно из трех разных состояний. Это либо

исходные данные, извлеченные с сервера
преобразованные данные (преобразованные из оригинала)
Сохранять данные. То, что действует как модель, с которой пользовательский интерфейс связан с

Если вы пишете библиотеку javascript, чтобы обрабатывать перемещение данных между тремя состояниями и обрабатывать преобразования, вы можете использовать систему событий для запуска события "смены магазина", которое компоненты могут прослушивать и выполнять самостоятельно. p >

Ответ 6

https://github.com/deepakpatil84/pure-data Примечание: я являюсь автором этого

Ответ 7

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

Во-вторых, Flux/Redux обеспечивает однонаправленный поток данных. Простым примером может быть около 2 компонентов A и B, потребляющих одни и те же данные X из внешнего источника (API или хранилище). Пользователь может взаимодействовать с любым из них, чтобы получить последние данные X. Теперь, если пользователь просит B обновить X, у нас есть два решения с вашим EventPropagator:

B обновит сам X и сгенерирует событие, чтобы проинформировать A об обновлении, чтобы позволить A повторно выполнить рендеринг. То же самое касается А, если пользователь просит А обновить Х. Это двунаправленный поток данных.
B инициирует событие для A, запрашивающего обновление X, и ожидает, пока A не запустит событие, чтобы получить обновленный X. Если пользователь запрашивает обновление A, A сделает это сам и сообщит B. Это однонаправленный поток данных.

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

Если вы действительно не думаете, что вам нужна еще одна библиотека для управления данными, вам стоит взглянуть на новейшую функцию React: Context. Он предоставляет наиболее важные функции, которые может иметь библиотека управления данными, и это только React. Отмечено, что вы должны обновить версию своего проекта React до 16.3, чтобы использовать эту функцию.

Ответ 8

Еще одна скромная альтернатива для нескольких магазинов - response-scopes

Вот некоторые особенности:

Синтаксис простых декораторов,
Разрешить определение независимой логики хранилища непосредственно в компонентах
Простое подключение магазинов через дерево компонентов
Разрешить шаблонную обработку сложных/асинхронных данных
SSR с асинхронными данными
и т.д