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:

  1. react makes sure render fires once @ end if setstate called multiple times.
  2. 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.

image

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

Popular posts from this blog

php - failed to open stream: HTTP request failed! HTTP/1.0 400 Bad Request -

java - How to filter a backspace keyboard input -

java - Show Soft Keyboard when EditText Appears -