Skip to content
This repository has been archived by the owner on Jun 16, 2020. It is now read-only.

Splitting components out to their own render loop? #217

Open
funkytek opened this issue Apr 4, 2017 · 2 comments
Open

Splitting components out to their own render loop? #217

funkytek opened this issue Apr 4, 2017 · 2 comments

Comments

@funkytek
Copy link

funkytek commented Apr 4, 2017

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 an onLoad hook on load to attach the component via appendChild

Thoughts, anything that's been done or should not be done?

@ashnur
Copy link
Collaborator

ashnur commented Apr 4, 2017

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

@funkytek
Copy link
Author

funkytek commented Apr 4, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants