search

choojs / choo

:steam_locomotive::train: - sturdy 4kb frontend framework
https://choo.io/
MIT License
6.78k stars 595 forks source link

Question: nested components #77

Closed dy closed 8 years ago

dy commented 8 years ago

Hi @yoshuawuyts!

I was playing with the framework - it is very nice! But I couldn’t figure out what is the best practice to init components declared in views. For example, my view besides some static content has a google map container and a gallery, which init asynchronously and get dynamically updated. Where is the best place to init them? Should I init them once view function is called? Considering that they can asynchronously update their html content - will that conflict with the tree returned from views? How can I manage disabling/enabling them if navigation happened? Is there any way to indicate in views that some tags should be ignored from tree diffing, or the contrary - that only some part of the tree should be diffed?

It seems to be related to state management in yo-yo docs, where only part of view is updated. That would be nice to have something like that in choo.

What are possible approaches/workarounds to init components in views, except for webcomponents?

Thanks

yoshuawuyts commented 8 years ago

haha, excellent timing on your question. Tbh we just solved this one a couple of hours ago haha, so we haven't had a chance to update the docs for this yet. To answer your paraphrased questions:

How should I setup and tear down widgets that contain state of their own? For example a Google Maps widget

Use Shama's on-load package for adding hooks to load and unload. Updating data can be done by diffing state with oldState passed in by views. This API is bound to change in v3 (#42) though.

Do updates in widgets conflict with the diffing algorithm?

The morphdom diffing engine diffs real DOM trees with each other. This means that it doesn't matter what a DOM node is created with, the diffing algorithm can parse it. So as long as your widget returns valid nodes, choo will merrily chug along

I hope this answers your questions. We're def working on making this smoother (see https://github.com/shama/bel/issues/30), so expect to see more of this in the future - I hope this gets you where you want to be tho. Cheers!

dy commented 8 years ago

haha, funny - I used to write lifecycle package a couple of years ago - an analog of on-load. But I don't understand yet - if side widgets have changed the real tree - what tree I should return from the view to avoid rewriting the real "good" tree with outdated one. Should views assemble tree from parts of real one and parts of "default" one?

dy commented 8 years ago

Anyways looking forward to the new API!

yoshuawuyts commented 8 years ago

use on-load to provide hooks for setting up / tearing down, and then keep returning the tree with your widget mounted. The hooks will fire when it's added / removed from the DOM.

Consider reading through the yo-yo and morphdom docs more background info on how the diffing works. Hope this is helpful. Cheers!

yoshuawuyts commented 8 years ago

I'm assuming I've answered your question - closing this issue. If you've got further questions about this we're happy to reopen this, or consider opening a new issue. Thanks again for asking. Cheers! :sparkles:

dy commented 8 years ago

Honestly I read the docs, all of that I knew before and I think that maybe I have conceptual misunderstanding. It is the case when DOM in some or other way contains more actual "model" than the app, therefore it can't be overwritten with any sort of view output. Anyways I will wait for the new API with hopefully more examples. Thank you for your work!