feat: implement DSD polyfill as an optional plugin for FAST SSR #6289
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
📖 Description
This PR embeds the necessary CSS and JavaScript polyfill code to ensure that Declarative Shadow DOM (DSD) is properly handled on browsers that don't yet implement the standard.
The SSR example has been updated to emit the polyfill code into the page.
🎫 Issues
👩💻 Reviewer Notes
The polyfill code is generally available on the web. This PR simply embeds it in our SSR package for convenience.
See the SSR example
server.js
file for usage.📑 Test Plan
No tests added for this as this just provides a convenience API over a well-known polyfill.
✅ Checklist
General
$ yarn change
⏭ Next Steps
An alternative polyfill method that supports streaming could be added. For this, we would embed a small global script in the page head and then emit a script tag immediately following each DSD instance, which called that global function, passing in the
currentScript
. This has some perf implications, since it would block the parser after every DSD instance. It also would require deeper integration into our renderer in order to emit the script tag after the close of the DSD template tag.Due to the downsides and increased complexity of this approach, I'm not pursuing implementing this for now. We can revisit this if there is a specific request for it. Additionally, it will likely be easier to implement into the renderer after the shared styles feature is complete, since both will need renderer configuration that is passed through the tree and both need to custom render content per component.