Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template cloning? #60

Closed
WorldMaker opened this issue Dec 5, 2023 · 0 comments · Fixed by #81
Closed

Template cloning? #60

WorldMaker opened this issue Dec 5, 2023 · 0 comments · Fixed by #81
Labels
question Further information is requested

Comments

@WorldMaker
Copy link
Owner

Right now the performance experts suggest that building elements inside a <template> and then cloning the <template> Node can have performance benefits over building the elements directly in place. Is this something that makes sense as an additional intermediate step between the JSX description language and the final DOM? Can we reuse templates between instances if the props are the same? How we hydrate binding in that case? Is that similar enough to #10 SSR scenarios to leverage some combined utility?

Is it maybe a different style of component that separates reusable <template> building from binding?

@WorldMaker WorldMaker added the question Further information is requested label Dec 5, 2023
WorldMaker added a commit that referenced this issue Jan 7, 2024
Static nodes take a single static DOM Element and attach it to their container. It's a simpler escape hatch than bfDomAttach and doesn't require you define your container element in JSX like bfDomAttach, but it also is only for *truly* static DOM and provides no further lifecycle events (as opposed to bfDomAttach pipelines into a bindEffect will get unsubscribed on component teardown).

Static seemed a useful compromise to allowing "public" exploration for things like SVG support #32 and Template cloning #60 before official half-ideas such as "Stamp collection" progress beyond half-idea status and while also not opening the can of worms of allowing public Observable Components. It also provides a possible approach to opening public Observable Components via a similar pseudo-component tag and custom flattened node description.
WorldMaker added a commit that referenced this issue Jan 7, 2024
Static nodes take a single static DOM Element and attach it to their container. It's a simpler escape hatch than bfDomAttach and doesn't require you define your container element in JSX like bfDomAttach, but it also is only for *truly* static DOM and provides no further lifecycle events (as opposed to bfDomAttach pipelines into a bindEffect will get unsubscribed on component teardown).

Static seemed a useful compromise to allowing "public" exploration for things like SVG support #32 and Template cloning #60 before official half-ideas such as "Stamp collection" progress beyond half-idea status and while also not opening the can of worms of allowing public Observable Components. It also provides a possible approach to opening public Observable Components via a similar pseudo-component tag and custom flattened node description.
@WorldMaker WorldMaker mentioned this issue Aug 20, 2024
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant