The method that you linked is the one I use currently.
Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly.
Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way.
Thanks for the suggestions. I've looked at immutable data structure libs some, but I haven't seen any real comprehensive examples showing the behavior you describe within the Flux pattern. Do you happen to know of any such examples?
I ask because the examples I see for react-cursor, etc typically show data being mutated directly inside the React component without using Actions/Stores/etc. Going this route means we lose the advantages such as a unidirectional data flow & the ability to centralize logic for interacting with a Store around well-defined Actions.
So if we did merge the Flux idea with Cursors, I assume we would keep a single Cursor as the underlying state inside a Store, and then use the traditional Action/ActionCreator model to allow React components/server updates to mutate this Store?
What is the big win here then vs. traditional (non-immutable) Stores (other than performance gains by using === in shouldComponentUpdate)? It seems to me you would still have to make a separate Store for editing a single item vs editing a collection.
I ask because the examples I see for react-cursor, etc typically show data being mutated directly inside the React component without using Actions/Stores/etc. Going this route means we lose the advantages such as a unidirectional data flow & the ability to centralize logic for interacting with a Store around well-defined Actions.
So if we did merge the Flux idea with Cursors, I assume we would keep a single Cursor as the underlying state inside a Store, and then use the traditional Action/ActionCreator model to allow React components/server updates to mutate this Store?
What is the big win here then vs. traditional (non-immutable) Stores (other than performance gains by using === in shouldComponentUpdate)? It seems to me you would still have to make a separate Store for editing a single item vs editing a collection.