SSR Testing
When we build a component, it is critical that we test it in a way that is similar to how it will be used by consumers. This includes testing the component in a server-side rendered (SSR) environment.
We use our test-bed project, PIE Aperture, to perform both manual and automated testing of our components in a variety of frameworks such as Nuxt and NextJS.
This project has a shared SSR test that can be used to test components in an SSR environment. It will render the component on the server and then inspect the output to ensure that it is as expected. This includes checking for the presence of a <template> element, with various shadow DOM attributes as well as a <style> element with styles included.
It is vital that an SSR test is included for each component that is built, to ensure that it behaves as expected in an SSR environment. This should be done before the component is moved from alpha to beta status.
Lit has provided some good guidelines on how to avoid creating SSR problems in components.
To avoid repeating what is already documented in their site, the most common mistake that creates SSR issues in our components is using browser-only APIs in parts of component logic that will be run on the server. An example is adding event listeners inside of a lifecycle method such as hasChanged().
Always test in real frameworks as you are developing a component so that you spot any issues like this early on.
