Hacker News Reader

Comment by lux | Hacker News Reader

After implementing Facebook's stock Flux (actions + constants + stores + dispatchers + views), which quickly gets verbose, I saw this on r/reactjs the other day and started playing with it and so far I've been impressed.

It takes some getting used to, but the mixins help reduce your code to actions + store + views and make it easier to reason about. There's a good post about it, including simple server integration, here:

https://www.codementor.io/reactjs/tutorial/flux-reactjs-stat...

I was surprised at the lack of attention it got, but I hope that changes because there are some good ideas here.

View on HN

I have only briefly checked out this library so take what I say with a grain of salt, but from what it looks like we had a very similar implementation to this on the project i'm currently involved with, also very inspired by Om.

At first it worked out great for us but as our application grew both in scope and number of developers involved, we quickly ended up with a 'cursor soup' where too many components were watching for changes individually.

It had a very negative impact on performance since components would potentially re-render multiple times for a single change. In our last implementation we ended up overcoming this by some fancy event consolidation, but even so we had too many components 'touching' our tree.

We ended up reverting to a much simpler architecture and it has both made our application dumber (which is great in terms of maintenance) but also more performant. We currently have actions/stores/views where actions themselves are dispatchers. By creating a few helper functions we overcome a large part of the boilerplate but even without, it has proved worth it for us.

I've been thinking about cursors and the potential for this problem, too. In your experience would you say that a strict flux pattern utilizing the PureRenderMixin and immutable data is a better way to go, and that one should avoid cursors completely for larger projects? It might be my lack of understanding, but cursors bring me back to some of the more annoying aspects of MVC, namely the potential for not knowing what is going on where.

Obviously everything I say is anecdotal since I have no data to share but by making components as dumb (i.e. PureRenderMixin) we reduced the amount of logic within a component and were able to make it both faster and easier to maintain. Maybe our approach was naive and Baobab fares better here.

Another important gain for us was re-usability of components. We have several projects that use the same components that represent the same data but the hierarchy of the internal state of the application can look quite different from one another. Passing everything in as props and avoiding as much state as possible has made this much easier as well.

I guess at the end of the day everything is a tradeoff one way or another and you just have to pick yours, as cliche as that sounds. For us simplicity was more important in this particular case.

Baobab should at least in part mitigate this by not committing changes immediately, but rather in batches as a single change:

https://github.com/Yomguithereal/baobab/wiki/Options

"When you use the mutation methods of Baobab (push, set, merge etc.) it will batch up these changes and make one single commit, which then triggers update events."

I haven't worked with Om on a non-trivial project yet, so please correct me if I'm wrong, but I believe Om might also do similar optimizations (i.e. batching updates and sending notifications in sync with its render on requestAnimationFrame flow).

I believe the idiomatic way to use this library is to treat the tree as an immutable structure. When used this way, it supports the React Immutability Helpers, and the PureRenderMixin. If you treat it as immutable and use the PureRenderMixin, you won't run into the re-render multiple times issue described above.

See this issue for more details: https://github.com/Yomguithereal/baobab/pull/74

Reflux[1] is another Flux alternative without the verbosity of Flux. I have no affiliation to the project, but use it in two of my current projects and am deliriously happy with it

[1] https://github.com/spoike/refluxjs

I haven't read the whole article that you linked, but the diagram seems very similar to Reflux, except that it uses the state tree instead of stores. Have you tried Reflux, if so how would you compare the two?

Reply on news.ycombinator.com