4 ms·

The problem here is the horizontal arrow between two stores. This leads to a web of connections, the usual spaghetti of data binding. There should either be a "

The problem here is the horizontal arrow between two stores. This leads to a web of connections, the usual spaghetti of data binding. There should either be a "store of stores" or another element that would direct the data flow so that it is unidirectional. If anyone knows about a flux implementation that solves this - I'd love to hear about it!

revskill 11y ago
The Store need a root, too. Because the component has tree structure.
- polskibus 11y ago
  Yes but how do we manage inter-store notifications? bubbling up to the root store and down to the other store? Do we post messages/actions for that , or do we call referenced stores directly? It seems flux just pushed the binding thing up a level, but the complexity is still there.
  - revskill 11y ago
    I use BaconJS as a FRP library to deal with async and store communication. In that way, you will have the root store that combines all events from child store. Then the root tree component will listen for these events to render. With this architecture, you need to separate the root stores correctly based on those events, which needs to be independent from each other root stores. One benefit of this approach is that, you don't need to deal with Dispatcher, ActionCreator, Constant, blablahh. You just need actions(optional) and stores.
sync 11y ago
redux composes stores into one, and discourages the "web of connections": https://github.com/gaearon/redux https://github.com/gaearon/redux It is rather immature, but we are using it in production without a problem, and the API is stable as of the 1.0 RC.
- chrisconley 11y ago
  While we're not using Redux in production yet, it's been an amazing library to work with so far.
- nuschk 11y ago
  We're also using redux in production, after having switched from reflux. In redux, it's so much more clear where to put stuff. In reflux, it was never clear to us whether certain async server operations should be handled in stores or in the actions. In general, you would always want them to be with your actions. Though every time you need a store variable to do the server call, you end up putting code in the store again (or passing the needed state through your react components, which is even uglier). Not so in redux, where you have access to the stores in your actions. This way, stores get really dumb, which is the way they should be IMO. And, btw, replacing reflux by redux is relatively easy and straightforward, as the same general concepts (flux) apply. I also find the redux code easier to read, as the whole library is doing less (while achieving the same).
danmaz74 11y ago
The "waitFor" implementation makes the stores ordered and circular dependencies impossible, so the data flow is actually unidirectional. It's just that some stores are "before" other stores, even if I didn't show this in the diagram. Maybe I should update it putting the "destination" store for the horizontal line a bit below the other two - so the line wouldn't be horizontal anymore.
- modarts 11y ago
  waitFor is a code smell to be honest. Switching to a flux implementation that makes it unnecessary is your best bet (like redux)

revskill 11y ago

The Store need a root, too. Because the component has tree structure.

polskibus 11y ago
Yes but how do we manage inter-store notifications? bubbling up to the root store and down to the other store? Do we post messages/actions for that , or do we call referenced stores directly? It seems flux just pushed the binding thing up a level, but the complexity is still there.
- revskill 11y ago
  I use BaconJS as a FRP library to deal with async and store communication. In that way, you will have the root store that combines all events from child store. Then the root tree component will listen for these events to render. With this architecture, you need to separate the root stores correctly based on those events, which needs to be independent from each other root stores. One benefit of this approach is that, you don't need to deal with Dispatcher, ActionCreator, Constant, blablahh. You just need actions(optional) and stores.

sync 11y ago

redux composes stores into one, and discourages the "web of connections": https://github.com/gaearon/redux https://github.com/gaearon/redux It is rather immature, but we are using it in production without a problem, and the API is stable as of the 1.0 RC.

chrisconley 11y ago
While we're not using Redux in production yet, it's been an amazing library to work with so far.
nuschk 11y ago
We're also using redux in production, after having switched from reflux. In redux, it's so much more clear where to put stuff. In reflux, it was never clear to us whether certain async server operations should be handled in stores or in the actions. In general, you would always want them to be with your actions. Though every time you need a store variable to do the server call, you end up putting code in the store again (or passing the needed state through your react components, which is even uglier). Not so in redux, where you have access to the stores in your actions. This way, stores get really dumb, which is the way they should be IMO. And, btw, replacing reflux by redux is relatively easy and straightforward, as the same general concepts (flux) apply. I also find the redux code easier to read, as the whole library is doing less (while achieving the same).

danmaz74 11y ago

The "waitFor" implementation makes the stores ordered and circular dependencies impossible, so the data flow is actually unidirectional. It's just that some stores are "before" other stores, even if I didn't show this in the diagram. Maybe I should update it putting the "destination" store for the horizontal line a bit below the other two - so the line wouldn't be horizontal anymore.

modarts 11y ago
waitFor is a code smell to be honest. Switching to a flux implementation that makes it unnecessary is your best bet (like redux)