3 ms·

I feel like the problem with Flux is the fact that there are multiple stores that the developer has to deal with. It seems easier to combine them and use a sing

I feel like the problem with Flux is the fact that there are multiple stores that the developer has to deal with. It seems easier to combine them and use a single "store" that has similar properties to Meteor, Firebase, PouchDb, etc..

baddox 11y ago
Is there really a significant difference between having two stores called UserStore and MessageStore, and having a single Store with state like {users: userState, messages: messageState}?
- jblock 11y ago
  I think it really depends on your implementation. For readability, having a `UserStore` and `MessageStore` in one place might get to be troublesome, especially when it comes to separating out business logic. But that said, things like `Om` like to push the idea of a single application state object, so I can forsee an implementation where you have multiple `Store`s that sit atop a single `ApplicationStore`, such that you deal with the keys of `users` and `messages` separately while they are attached to the same parent `ApplicationState` object (which can be immutable and persistent as well).
lewisl9029 11y ago
This is the approach that many ClojureScript frameworks take, and I find it to be a much more elegant approach than Flux proper. You use a single, immutable data structure to store your application state, and components use functional lenses to look into the part of the state they're dependent on and listen for changes. In doing so, you get a free application history stack and deltas (for undo/redo, offline/online sync and some powerful debugging capabilities), extremely efficient shouldComponentUpdate implementations for all components, and opportunities for many more advanced optimizations like batching updates for rendering on requestAnimationFrame. Check out Om if you'd like to take a look at the original ClojureScript implementation, or Morearty.js if you're interested in a pure JS alternative. https://github.com/moreartyjs/moreartyjs https://github.com/moreartyjs/moreartyjs https://github.com/omcljs/om https://github.com/omcljs/om

baddox 11y ago

Is there really a significant difference between having two stores called UserStore and MessageStore, and having a single Store with state like {users: userState, messages: messageState}?

jblock 11y ago
I think it really depends on your implementation. For readability, having a `UserStore` and `MessageStore` in one place might get to be troublesome, especially when it comes to separating out business logic. But that said, things like `Om` like to push the idea of a single application state object, so I can forsee an implementation where you have multiple `Store`s that sit atop a single `ApplicationStore`, such that you deal with the keys of `users` and `messages` separately while they are attached to the same parent `ApplicationState` object (which can be immutable and persistent as well).

lewisl9029 11y ago

This is the approach that many ClojureScript frameworks take, and I find it to be a much more elegant approach than Flux proper. You use a single, immutable data structure to store your application state, and components use functional lenses to look into the part of the state they're dependent on and listen for changes. In doing so, you get a free application history stack and deltas (for undo/redo, offline/online sync and some powerful debugging capabilities), extremely efficient shouldComponentUpdate implementations for all components, and opportunities for many more advanced optimizations like batching updates for rendering on requestAnimationFrame. Check out Om if you'd like to take a look at the original ClojureScript implementation, or Morearty.js if you're interested in a pure JS alternative. https://github.com/moreartyjs/moreartyjs https://github.com/moreartyjs/moreartyjs https://github.com/omcljs/om https://github.com/omcljs/om