-
Notifications
You must be signed in to change notification settings - Fork 1k
[ssr] Fix unknown element attribute rendering #2344
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
Conversation
🦋 Changeset detectedLatest commit: dada6f2 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
reactive-element-list
render
update
update-reflect
|
justinfagnani
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
kevinpschaaf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That reminds me, another reason to go for (2) over (1) is that it preserves the ability for an element renderer to match based on per-instance attributes (we pass op.staticAttributes for the instance to the getElementRenderer call at opcode execution time); looking up the renderer at opcode generation time would remove that flexibility. I thought we might use that for e.g. a client-side-only attribute to choose a FallbackRenderer that doesn't SSR).
So this seems good, at least until we refine the ElementRenderer matching concept and and how we decide to do client-side only components.
Fixes a bug where static attributes on custom elements would not render if the custom element was unregistered or did not have a renderer.
I considered a few ways to solve this and picked [2]. Open to switching to [1] or doing something else:
Don't emit
custom-element-*opcodes at all for un-renderable elements. However, this would makegetTemplateOpcodesdependent onrenderInfo, and it seemed kind of nice to preserve the feature ofgetTemplateOpcodesbeing only a function of the template. If we did this, seems like we'd want to add the rendererinstanceto thecustom-element-openopcode, so that we don't look up the renderer twice.Add a new
FallbackRendererclass which just tracks and renders attributes. This is what I picked, since it seemed pretty undisprutive, and it's sort of nice to not have to handle theundefinedcase as specially in the opcode render loop.Add special tracking for unrenderable elements using a bag of attributes directly in the
customElementInstanceStackstack, and add fallback logic to render static attributes in thecustom-element-attributesswitch case. This just seemed like a less clean way of writing [2].Fixes #2321