You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building off the outcome of #87 , would like to, and have already started playing around with, a more "fine grained" observability model; one that doesn't require an entire re-render and blowing out innerHTML, but can instead more acutely update DOM nodes (textContent, setAttribute) instead.
It might stand to reason we should map updates back to attributes, to keep things in sync? But not sure if this co-mingling is good or bad? Probably if state is meant to go "out" it should be done through custom events instead? Will need to play around with this a bit
Would be good to explore tagged template functions as part of this, if not for at least the underlying templating mechanics (as opposed to instead of using JSX directly)
Although we only scan the render function for this references, would we do ourselves a service by scanning constructor too, maybe for init values and / or something related to SSR?
Type of Change
Feature
Summary
Building off the outcome of #87 , would like to, and have already started playing around with, a more "fine grained" observability model; one that doesn't require an entire re-render and blowing out
innerHTML
, but can instead more acutely update DOM nodes (textContent
,setAttribute
) instead.Details
So for example, taking our Counter component
Which would produce this compiled output
Instead, we would want the compiled output to look something like this instead
Additional Thoughts:
render
function forthis
references, would we do ourselves a service by scanningconstructor
too, maybe for init values and / or something related to SSR?dataset
could be useful for anything?The text was updated successfully, but these errors were encountered: