{"id":373787,"date":"2022-10-05T06:05:43","date_gmt":"2022-10-05T13:05:43","guid":{"rendered":"https:\/\/css-tricks.com\/?p=373787"},"modified":"2022-10-05T06:05:44","modified_gmt":"2022-10-05T13:05:44","slug":"using-web-components-with-next-or-any-ssr-framework","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/using-web-components-with-next-or-any-ssr-framework\/","title":{"rendered":"Using Web Components With Next (or Any SSR Framework)"},"content":{"rendered":"\n
In my previous post<\/a> we looked at Shoelace, which is a component library with a full suite of UX components that are beautiful, accessible, and \u2014 perhaps unexpectedly \u2014 built with Web Components<\/a>. This means they can be used with any JavaScript framework. While React’s Web Component interoperability is, at present, less than ideal, there are workarounds<\/a>.<\/p>\n\n\n\n But one serious shortcoming of Web Components is their current lack of support for server-side rendering (SSR). There is something called the Declarative Shadow DOM (DSD) in the works, but current support for it is pretty minimal, and it actually requires buy-in from your web server to emit special markup for the DSD. There’s currently work being done for Next.js<\/a> that I look forward to seeing. But for this post, we’ll look at how to manage Web Components from any SSR framework, like Next.js, today<\/em>.<\/p>\n\n\n\n\n\n\n\n We’ll wind up doing a non-trivial amount of manual work, and slightly<\/em> hurting our page’s startup performance in the process. We’ll then look at how to minimize these performance costs. But make no mistake: this solution is not without tradeoffs, so don’t expect otherwise. Always measure and profile.<\/p>\n\n\n Before we dive in, let’s take a moment and actually explain the problem. Why don’t Web Components work well with server-side rendering?<\/p>\n\n\n\n Application frameworks like Next.js take React code and run it through an API to essentially “stringify” it, meaning it turns your components into plain HTML. So the React component tree will render on the server hosting the web app, and that HTML will be sent down with the rest of the web app’s HTML document to your user’s browser. Along with this HTML are some So, what does this have to do with Web Components? Well, when you render something, say the same Shoelace …React (or honestly any<\/em> JavaScript framework) will see those tags and simply pass them along. React (or Svelte, or Solid) are not responsible for turning those tags into nicely-formatted tabs. The code for that is tucked away inside of whatever code you have that defines those Web Components. In our case, that code is in the Shoelace library, but the code can be anywhere. What’s important is when the code runs<\/em>.<\/p>\n\n\n\n Normally, the code registering these Web Components will be pulled into your application’s normal code via a JavaScript So the problem is that the code to make Web Components do what they need to do won’t actually run until hydration occurs. For this post, we’ll look at running that code sooner; immediately, in fact. We’ll look at custom bundling our Web Component code, and manually adding a script directly to our document’s In our case, we’re just<\/em> looking to run our Web Component registration code in a blocking script. This code isn’t huge, and we’ll look to significantly lessen the performance hit by adding some cache headers to help with subsequent visits. This isn’t a perfect solution.<\/strong> The first time a user browses your page will always block while that script file is loaded. Subsequent visits will cache nicely, but this tradeoff might not<\/em> be feasible for you \u2014 e-commerce, anyone? Anyway, profile, measure, and make the right decision for your app. Besides, in the future it’s entirely possible Next.js will fully support DSD and Web Components.<\/p>\n\n\n All of the code we’ll be looking at is in this GitHub repo<\/a> and deployed here with Vercel<\/a>. The web app renders some Shoelace components along with text that changes color and content upon hydration. You should be able to see the text change to “Hydrated,” with the Shoelace components already rendering properly.<\/p>\n\n\n Our first step is to create a single JavaScript module that imports all of our Web Component definitions. For the Shoelace components I’m using, my code looks like this:<\/p>\n\n\n\n It loads the definitions for the The problem<\/h3>\n\n\n
<script><\/code> tags that load React, along with the code for all your React components. When a browser processes these
<script><\/code> tags, React will re-render the component tree, and match things up with the SSR’d HTML that was sent down. At this point, all of the effects will start running, the event handlers will wire up, and the state will actually… contain state. It’s at this point that the web app becomes interactive<\/em>. The process of re-processing your component tree on the client, and wiring everything up is called hydration<\/dfn><\/strong>.<\/p>\n\n\n\n
<sl-tab-group><\/code> component we visited last time<\/a>:<\/p>\n\n\n\n
<sl-tab-group ref=\"{tabsRef}\">\n <sl-tab slot=\"nav\" panel=\"general\"> General <\/sl-tab>\n <sl-tab slot=\"nav\" panel=\"custom\"> Custom <\/sl-tab>\n <sl-tab slot=\"nav\" panel=\"advanced\"> Advanced <\/sl-tab>\n <sl-tab slot=\"nav\" panel=\"disabled\" disabled> Disabled <\/sl-tab>\n\n <sl-tab-panel name=\"general\">This is the general tab panel.<\/sl-tab-panel>\n <sl-tab-panel name=\"custom\">This is the custom tab panel.<\/sl-tab-panel>\n <sl-tab-panel name=\"advanced\">This is the advanced tab panel.<\/sl-tab-panel>\n <sl-tab-panel name=\"disabled\">This is a disabled tab panel.<\/sl-tab-panel>\n<\/sl-tab-group><\/code><\/pre>\n\n\n\n
import<\/code>. That means this code will wind up in your JavaScript bundle and execute during hydration which means that, between your user first seeing the SSR’d HTML and hydration happening, these tabs (or any Web Component for that matter) will not render the correct content. Then, when hydration happens, the proper content will display, likely causing the content around these Web Components to move around and fit the properly formatted content. This is known as a flash of unstyled content<\/strong>, or FOUC. In theory, you could stick markup in between all of those
<sl-tab-xyz><\/code> tags to match the finished output, but this is all but impossible in practice, especially for a third-party component library like Shoelace.<\/p>\n\n\n
Moving our Web Component registration code<\/h3>\n\n\n
<head><\/code> so it runs immediately, and blocks the rest of the document until it does. This is normally a terrible thing to do.<\/em> The whole point of server-side rendering is to not<\/em> block our page from processing until our JavaScript has processed. But once done, it means that, as the document is initially rendering our HTML from the server, the Web Components will be registered and will both immediately and synchronously emit the right content.<\/p>\n\n\n\n
Getting started<\/h3>\n\n\n
Custom bundling Web Component code<\/h3>\n\n\n
import { setDefaultAnimation } from \"@shoelace-style\/shoelace\/dist\/utilities\/animation-registry\";\n\nimport \"@shoelace-style\/shoelace\/dist\/components\/tab\/tab.js\";\nimport \"@shoelace-style\/shoelace\/dist\/components\/tab-panel\/tab-panel.js\";\nimport \"@shoelace-style\/shoelace\/dist\/components\/tab-group\/tab-group.js\";\n\nimport \"@shoelace-style\/shoelace\/dist\/components\/dialog\/dialog.js\";\n\nsetDefaultAnimation(\"dialog.show\", {\n keyframes: [\n { opacity: 0, transform: \"translate3d(0px, -20px, 0px)\" },\n { opacity: 1, transform: \"translate3d(0px, 0px, 0px)\" },\n ],\n options: { duration: 250, easing: \"cubic-bezier(0.785, 0.135, 0.150, 0.860)\" },\n});\nsetDefaultAnimation(\"dialog.hide\", {\n keyframes: [\n { opacity: 1, transform: \"translate3d(0px, 0px, 0px)\" },\n { opacity: 0, transform: \"translate3d(0px, 20px, 0px)\" },\n ],\n options: { duration: 250, easing: \"cubic-bezier(0.785, 0.135, 0.150, 0.860)\" },\n});<\/code><\/pre>\n\n\n\n
<sl-tab-group><\/code><\/a> and
<sl-dialog><\/code><\/a> components, and overrides some default animations for the dialog. Simple enough. But the interesting piece here is getting this code into our application. We cannot<\/em> simply
import<\/code> this module. If we did that, it’d get bundled into our normal JavaScript bundles and run during hydration. This would cause the FOUC we’re trying to avoid.<\/p>\n\n\n\n