-
Notifications
You must be signed in to change notification settings - Fork 28
can emitChange from store support passing a paylod that holds an id #34
Comments
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. |
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 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. |
personally 👍 for the ability to attach an optional payload to the Though technically you can "get around this" now since the stores extend 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 So the idea would be that those individual components would return thoughts on that approach @mridgway? |
@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. |
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 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 |
With all of this said, I'm fine with allowing to pass payloads into change event. |
… to the store instance instead of the store class
[resolves #34] Allow param to be passed to emitChange events; Default to...
this could be just something really invalid, so consider this as a question if this is something that doesn't make sense to be implemented.
imagine i have a store, which holds a list of items. and i've an Item renderer component which renders each of these Items. Lets say each of the item component listens to store changes. with the current design, whenever one of the items changes in the store, all the instances of the item components will be re-renderered. assume if the store is able to attach an id in the emitChange call. so store says, i've a change, but only for item with id x. that would let the item renderer component to ignore the change notification if the change is not associated to it.
The text was updated successfully, but these errors were encountered: