Comment by edvinbesic | Hacker News Reader

Comment by edvinbesic | Hacker News Reader

Parent Full thread

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 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

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'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.

Reply on news.ycombinator.com