Flux Chat Example about flux

[briandipalma]

I'm outside the React/Flux team but this is my understanding of things, it might be wrong.

1. Stores are the source of truth, they are event emitters and are listened to by the components. The setState call is because React has no observables so it must be told when the component needs to be rendered, that data would almost always come from Stores so in reality it's not state that the React components would mutate, they simply rendered it to the screen.

2. Yes the fact Stores etc are all Singletons is a problem for us in our particular use of Flux. We have solved it by using a factory to return instances of Stores etc. We might write a blog post about it soon.

[gnesher]

@briandipalma

1. React does have a setProps method which re-renders the component. However it can only be called by top level components. They specifically discourage you from using it (or so it seems) but they do suggest in the docs that only one source of truth should exist in the app - aka components should not duplicate it. I just feel like I'm missing something here :)
2. I'd be very interested in reading that - do drop a line if / when you do

[briandipalma]

1. Props are immutable and passed in from your parent, state is mutable and local to the component. This aids in pinpointing bugs. I think if you relied on your parent feeding all data from Stores into you as props you would be asking React to do too much unnecessary work. Anyway the only ways that parents could trigger a render of them self is either via setState or a force update. The Stores are the source of truth, you can't ask your React components for that data, you can only ask the Stores.

2. Will do.

[fisherwebdev]

Thanks, Brian for clarifying this for Guy and other readers! I believe you
have it correct.

I'd like to add that the Sections in this example are at the second level
of the hierarchy, quite near the top. They receive no props -- as
controller-views they are the source of props for all their children.
Please also note that there is no "hard rule" about the level of the
hierarchy where controller-views should live. I find that debugging is
easier when you keep them at the top, but there are benefits to having low
level ones too -- this allows you to encapsulate code better (not pass down
a lot of extra data in the props). Like I said, I much prefer keeping them
at the top and passing data down, but other people here at Facebook feel
otherwise. Different strokes.

I'm very curious as to why stores as singletons were problematic for you,
so I'm looking forward to reading a blog post about that too.

On Sat, Aug 23, 2014 at 12:41 PM, Brian Di Palma [email protected]
wrote:

1. Props are immutable and passed in from your parent, state is mutable
   and local to the component. This aids in pinpointing bugs. I think if you
   relied on your parent feeding all data from Stores into you as props you
   would be asking React to do too much unnecessary work. Anyway the only ways
   that parents could trigger a render of them self is either via setState
   or a force update. The Stores are the source of truth, you can't ask your
   React components for that data, you can only ask the Stores.

2. Will do.

—
Reply to this email directly or view it on GitHub
#41 (comment).

Bill Fisher
510.414.8771
http://fisherwebdev.com

[gnesher]

Thanks @fisherwebdev @briandipalma was somewhat confused about this.

fyi - http://facebook.github.io/react/tips/props-in-getInitialState-as-anti-pattern.html can be interpreted as saying you should use setProps when getting data from stores.

Closing this for now