-
Notifications
You must be signed in to change notification settings - Fork 0
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
Labels
question
Further information is requested
Comments
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?The text was updated successfully, but these errors were encountered: