Relatedly, I wanted to highlight that Dan Abramov is currently working on a refactor of ReactPerf [1] which will make the performance measurements more accurate.
Great post! I found Fenwick trees particularly useful when I was implementing layout / view recycling. The problem is that you need to keep track of a large number of vertically stacked elements with dynamic & varying heights, and you need a way to efficiently get the prefix sum. Would be curious if anyone else has real life use cases of these.
For me, the part of Flux that's difficult to understand is how server data flows into the cycle (left-hand side of the diagram). The Flux docs only recommends that server interactions should be done from the Action Creators. However, things are actually more complicated than that:
- how do you resolve server / client data conflicts?
- how do stores work with a RESTful API?
- how do you handle network failures, retries, etc?
At Quizlet, we designed a hybrid solution [1] with "syncers" that act as the gateway for network I/O. Syncers are responsible for taking view-level data (ViewModels) and exchanging them with the server (ServerModels). It works well with our REST API. Yahoo has also released their own thing called Fetchr [2] which is more tightly integrated to stores.
I'm curious to see how other people are approaching this problem.
Point #2 is especially spot on. Right now TransitionGroup clones every child [1] to preserve children for unmounting, but it's incredibly inefficient, especially if you have thousands of elements. Not to mention, as a side-effect, it requires wrappers to preserve refs. [2]
We recently adopted this architecture for a medium-scale project. The unidirectional data flow has greatly reduced code complexity for us. We're still not satisfied with our server syncing strategy. Seems like actions are the best place to sync data, but how do you deal with interdependent actions?
https://twitter.com/FamousCeleb/status/834567373214539776/ph...