[daveidol]

One thing I would love to see some guidance on with Flux (and potentially with the patterns expressed in Marty.js) is how to handle the use case of Stores for a collection of items as well as a single item.

Right now, if I create a Store for a collection of Users and I want to be able to mutate these User objects then I create actions for each CRUD mutation and then plumb that change through to the in-memory object inside my collection as well as persist the change to my server.

But as soon as I click on a specific User and load up a new page for that User, for example, then I need to create an all new Store just for a single User, which has all of the same mutations/actions available to it as the previously-mentioned collection Store (except now I don't need to pass the ID to every action payload).

The best approach I've seen on this topic is in this example's Readme: https://github.com/gaearon/flux-react-router-example

Does this approach make sense/jive with the Marty.js way of handling Stores, State Sources, etc?

[hakanderyal]

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.

[1]: https://github.com/facebook/immutable-js

[2]: https://github.com/dustingetz/react-cursor

[3]: https://facebook.github.io/react/docs/update.html

[daveidol]

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.