reactjs - Facebook flux deficiency -
in flux-chat example, messagesection listens both threadstore , messagestore renders when threadstore store changes , once again when messagestore changes. however, since state depends on both, first render done when state not complete.
unless i'm missing not good, no?
this 1 example pattern repeating.
update: after long discussion thread here conclusions:
- react makes sure
render
fires once @ end ifsetstate
called multiple times. - the getter functions build state called multiple times since these pure functions not cause bugs 'small' overhead.
my suggestion use maximum of 1 store per react component gathers state other stores coordinating them using waitfor
, notifies component when state ready. way there no overhead , no reliance on react's internal magic. similar having 'view model' there no 2 way binding , data flows in 1 direction store component.
in general, not problem long each store internally consistent. if there data dependencies between stores, stores can use waitfor
ensure data propagates in correct order.
furthermore, though setstate
called twice (once each change event), react synthetic event system batches multiple setstate
calls 1 render, happens after both actions handled.
to prove case, made following modifications project:
diff --git a/examples/flux-chat/js/components/messagesection.react.js b/examples/flux-chat/js/components/messagesection.react.js index b803174..05bad0b 100644 --- a/examples/flux-chat/js/components/messagesection.react.js +++ b/examples/flux-chat/js/components/messagesection.react.js @@ -50,6 +50,7 @@ var messagesection = react.createclass({ }, render: function() { + console.log("message section render"); var messagelistitems = this.state.messages.map(getmessagelistitem); return ( <div classname="message-section"> diff --git a/examples/flux-chat/js/stores/messagestore.js b/examples/flux-chat/js/stores/messagestore.js index 995ef39..3436a0f 100644 --- a/examples/flux-chat/js/stores/messagestore.js +++ b/examples/flux-chat/js/stores/messagestore.js @@ -94,6 +94,7 @@ var messagestore = assign({}, eventemitter.prototype, { }); messagestore.dispatchtoken = chatappdispatcher.register(function(action) { + console.log("message store", action.type); switch(action.type) { diff --git a/examples/flux-chat/js/stores/threadstore.js b/examples/flux-chat/js/stores/threadstore.js index a73ceb3..e14f35d 100644 --- a/examples/flux-chat/js/stores/threadstore.js +++ b/examples/flux-chat/js/stores/threadstore.js @@ -103,6 +103,7 @@ var threadstore = assign({}, eventemitter.prototype, { }); threadstore.dispatchtoken = chatappdispatcher.register(function(action) { + console.log("thread store", action.type); switch(action.type) {
in javascript console, can see messagesection
not re-rendering until both actions have been processed.
so, in case, work getstatefromstores
being called twice instead of once, believe tiny bit of overhead worth take advantage of simplified mental model of emitting change event store needs update.
remember golden rule of flux is: the way mutate store data via actions. functions exposed on store should never mutate data—they should pure functions. thus, calling them more once not cause bugs.
Comments
Post a Comment