would a re-rendering after every javascript execution frame be a good idea?

gistfile1.md

Pete (or anyone else that knows React and wants to weigh in),

I'm a huge fan of React and have been loving it thus far but I'm wondering if there is something that might make it even better. I'm wondering if you could just re-render the whole app after any javacript has run and not make the developer ever have to worry about saying "ok, now re-render".

The idea is to use something like https://github.com/btford/zone.js/ (which monkey-patches all cases of starting js execution: ( setTimeout, setInterval, requestAnimationFrame, xhr.onReadyStateChange, addEventListener, etc and lets you run something before and after) and after any chunck of javascript runs, ensure a forceUpate is called on the top-level component.

So then you wouldn't need to explicitly .setState and more of your code can be completely react-unaware and agnostic. I think this is basically what Om does. It's kind of like this example: https://gist.github.com/jlongster/3f32b2c7dce588f24c92#file-a-increment-js but rather than doing it constantly and needlessly in a requestAnimationFrame you'd only rerender if javascript has run.

Does that make sense? Would the perf of re-rendering the whole app not be fast enough in practice? does that break the philosiphy of the programing model behind react? That was something I liked about angular's dirty-checking approach, you never had to .set or .setState or .reRender, the framework would do that for you atomatically (...mostly, as long as you were using their $http, $interval, etc)

react-raf-batching does exactly what you want :)

https://www.npmjs.org/package/react-raf-batching

@vjeux I don't think that's exactly right.

It would be possible to try to add this though. For large apps it may be prohibitive because if you have a single window-scroll handler or are doing an animation (for example), you probably don't want to rerender your entire app.

@spicyj: even for the scroll case, that is essential what angular does but instead of doing a virtual dom diff it does a dirty-check. so even though you'd think it would be too slow, it might not.

I like what @floydphone said though about how .setState forces you to think about how your data flows, and so is a good constraint to have.

thanks for all of your input though!