Open funkytek opened 7 years ago
Because the render loop is (or should) be run by requestAnimationFrame
, I am not sure what would be the benefit of trying to run more renders/frames. But I probably misunderstand what you mean...
So the problem I am trying to solve is that as the app grows, you nest more and more child state atoms/components which are affected by state changes up the tree. Imagine you have event 2 large components with 5 children each which each have children and so on- composing the top level state atom of these can be problematic.
It's certainly possible I am missing something, and perhaps my architecture is not best-practice for a large app. The designs is very simple: an App
component whose state has several children, with those components in turn having child state and so on.
As the app gets very large, this architecture starts to slow significantly, interfere with sibling state and become difficult to reason about in cases with deeply nested state. Separating out (at least) top level components out and making everything more shallow seems like it would be easier to handle. Not sure what the downsides to this approach could be though.
With an app that is starting to get quite large with many nested components/state atoms what would be the best-practice way to split some of the larger components out into their own render loops? Is there any examples of this?
having multiple
hg.app()
calls works for a simple append, alternatively for more granular appending I've seen one case using anonLoad
hook on load to attach the component via appendChildThoughts, anything that's been done or should not be done?