can emitChange from store support passing a paylod that holds an id about dispatchr HOT 6 CLOSED

Is each item in the list listening for the store changes or just the parent? Ideally it's just the parent that is listening for changes and then passing the item details into the list items via props. That way you don't need to worry about ids at all, React will only update the single item in the list.

from dispatchr.

yes, i was thinking of a scenario where each item listens to the store changes. let me try to explain a bit more. lets say items get loaded once into the items store, and there are different components which use a subset of these items.

say for example there's one parent Items renderer which renders item 1 , item 4, item 5
there's another parent items renderer which renders item 3, item 2

so if both the parents are listening to the ItemsStore, even if there's an item that got changed which the parent renderer doesn't care about, it would get notified and it would try to re-render it's children (unless react is smart enough to ignore that? ). But if it's just the items themselves that's listening we can avoid that.

also it looks cleaner to attach the listener in each item, so that the parents don't have to worry about listening to stores and making sure it's children are updated. all that the parent will have to do is to put in an item component and pass in an item id.

from dispatchr.

personally 👍 for the ability to attach an optional payload to the emitChange method on stores.

Though technically you can "get around this" now since the stores extend EventEmitter which does support emitting events with arbitrary payloads.

But then you have to manually manage adding/removing the store listener yourself in your component.

For the example @sfj2 provides though, I was thinking that the flux way would be to:

Not try to optimize, just render and trust React to do the right thing. BUT if performance is a bottle-neck, and you were careful to treat state like the React docs told you, then you can boost perf by implementing a shouldComponentUpdate method on your component(s).

So the idea would be that those individual components would return false in shouldComponentUpdate if they notice that their new props aren't different from their old props.

thoughts on that approach @mridgway?

from dispatchr.

@koulmomo lets assume figuring out shouldComponentUpdate ourselves is going to be difficult (like say the props is not a simple data structure) , then having the id of the item that was changed as a payload would make it so easy.

from dispatchr.

so if both the parents are listening to the ItemsStore, even if there's an item that got changed which the parent renderer doesn't care about, it would get notified and it would try to re-render it's children (unless react is smart enough to ignore that? ). But if it's just the items themselves that's listening we can avoid that.

It sounds like the parent is already determining which children to render from the list, so it seems like the parent can do a check to see if the child items differ in shouldComponentUpdate and which would then cancel the re-render if they do not differ.

Immutable data libraries would helper he as well. You'd be able to check whether a whole object has changed just by doing simple equality checks.

It's not recommended to have too many components listening to stores as you'll probably run into performance concerns with all of the listeners. Try to identify which components in your hierarchy should be "Controller Views" and keep them in control of listening for changes and then pass the data down as props.

Let React handle the grunt work of whether or not it should update and then implement shouldComponentUpdate where you see bottlenecks.

from dispatchr.

With all of this said, I'm fine with allowing to pass payloads into change event.

from dispatchr.