2015-09-18 4 views
0

Я пытаюсь обернуть голову вокруг Flux, и на самом деле у меня есть надуманный пример работы, но я немного запутался в потоке событий. Предположим, я определяю действие под названием TestAction. У моего представления есть onClick, который испускает это событие;Flux события в/из магазина?

Dispatcher.dispatch(new TestAction(this.state.currentValue)); 

Отлично, он стекает в магазин. До сих пор, так хорошо, я понимаю.

Теперь мой магазин делает все, что угодно, что он делает, разговаривает с серверами и т. Д. И сам обновляет. Затем, по некоторым причинам, все примеры показывают, что магазин делает что-то в этом направлении;

Dispatcher.register((action: Action) => { 
    if (action instanceof TestAction) { 
    var text = (<TestAction>action).text; 
    console.log('Store got: ', text); 
    this._text = text + '_'; 
    this.emit(TestStore.TEST_EVENT, this._text); 
    } 
}); 

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

+0

Не могли бы вы уточнить, что вы имеете в виду под «почему это обжиг тот же событие» ? О каком событии вы говорите? –

+0

Я предполагаю, что это скорее семантическая разница, о которой я спрашиваю. У меня есть TestAction, а затем TEST_EVENT. Разве это просто разница в именах, в которых Action is from view -> сохраняет и сохраняет события с возвратом? Я не понимаю поток данных правильно, я думаю. – XeroxDucati

+0

ОК. Я объясню поток данных в ответ. –

ответ

1

Views, которые являются компонентами React, выдает action всякий раз, когда происходит событие (например, щелчок).

Эти действия затем используют utils/apis для извлечения/выталкивания данных на сервер, а затем используют эти извлеченные/отточенные данные для отправки в качестве полезной нагрузки через a через dispatcher.

Dispatcher является центральным механизмом для уведомления нескольких магазинов об обновлении, причем обновление представляет собой полезную нагрузку, отправленную вместе с конкретным action type.

Магазины регистрируются для определенного типа action types. И всякий раз, когда диспетчер отправляет обновление об этом типе действия, магазины обновляют себя этими данными, и они испускают событие изменения, заявляя, что состояние хранилища изменилось.

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

Однонаправленный данные проточного

Views -> Action -> Dispatcher -> Stores -> Views

Это хорошая статья для дальнейшего детали- https://medium.com/brigade-engineering/what-is-the-flux-application-architecture-b57ebca85b9e

+0

Итак это в основном имеет смысл, за исключением того, что я немного запутался в utils/apis - вы говорите, что Action должен вызывать любую логику на стороне сервера? Например, скажем, у меня есть хранилище немых объектов на сервере, в котором хранится общий объект JSON - я предположил, что конструктор Store выполнит GET, чтобы захватить этот объект, и когда он увидит действия, будет обновляться на сервере и испускать обновленный JSON .. Вы говорите, что это должно произойти в Акции так или иначе? – XeroxDucati

+0

@XeroxDucati Да, действие должно вызвать apis, получить данные и отправить его. И магазины должны обновлять себя, используя эту отправку, магазины не должны делать GET, вы, вероятно, поняли. –

Смежные вопросы