I like ReactJS, but I think Flux is overhyped. One-way dataflow is much better handled via RxJS or BaconJS and as with Om thru cursors. Writing stores and dispatchers and actions is a poor substitute for FRP.
shrug They address different problems. Reactive systems are great but they aren't an overall architectural approach. You have to come up with that yourself.
Flux is an architecture.
I used BaconJS and I found that my overall page event and data flow ended up being reactive spaghetti. Architecture is not my strong suit. One of the great things about flux is having extremely strong conventions about where everything goes:
- All interactions are through actions.
- All state is in stores.
- No mutable state in the actual UI.
- etc.
What's your overall dataflow architecture look like using RxJS or BaconJS?
There is nothing stopping you using a flux-like architecture with RxJS or BaconJS. For example, instead of action creators you can push to a Bacon.Bus that is listened to by your store, which can be a Bacon.Property.
I found using BaconJS much nicer if I needed to transform data from asynchronous requests because you end up with a much more functional approach.
- What is the equivalent of the global action bus in Flux?
- How do you handle consuming data from multiple rest endpoints?
- Suppose you want to restructure the components in the app into a different hierarchy, how much refactoring is involved?
- Is there any open source example code of an app built this way that is more complex than a simple todo or simple async example? (I think the biggest challenge with these kinds of apps comes at that next tier of complexity... it's trivial to do a clean TODO implementation that doesn't do anything with server data in nearly any framework).
When a component needs data, it subscribes to the relevant stores, and updates itself on data changes.
When you want to mutate the data, you call an action, which in turns mutate the data in the store. Since the components are subscribed to stores, they get the new data automatically.
Stores subscribe to a central dispatcher, listening to all actions. When an action fires, they look the action's data, and mutate their data if it is relevant to them.
The data flow is action-> dispatcher-> store -> component -> action.
When you want to get data from a rest endpoint, you fire an action from the component. The action fetches the data, and pushes it to dispatcher.
Flux is an architecture.
I used BaconJS and I found that my overall page event and data flow ended up being reactive spaghetti. Architecture is not my strong suit. One of the great things about flux is having extremely strong conventions about where everything goes:
- All interactions are through actions.
- All state is in stores.
- No mutable state in the actual UI.
- etc.
What's your overall dataflow architecture look like using RxJS or BaconJS?