Pre-rendered / SSR (server side rendered) stories
See original GitHub issueThis topic has already occurred several times without any proper solutions or discussions on how to implement this in the future. https://github.com/storybookjs/storybook/issues/8009 https://github.com/storybookjs/storybook/issues/828 https://github.com/storybookjs/storybook/issues/4271
I think there is definitely a need for server side rendered stories and with some changes to the API it may be possible to create a plugin. We already created a working SSR configuration for storybook (5.xx) (react) but it uses some private functions to create a working webpack configuration. Many corners were cut to get this thing running.
https://github.com/goodhood-eu/goodhood/tree/5f0342b36186f9eccf36930d4cde53626a579b8b/.storybook
In short, it works like this:
start-storybook --preview-url=/ssr-iframe.storybook/middleware.jsregisters a custom SSR middleware- SSR middleware injects a custom
webpackDevMiddlewareand listens to requests to/ssr-iframe - On
GET /ssr-iframewe grab the compiled prerender bundle from webpack and render the requested story - ssr-iframe client side js kicks in and hydrates prerender https://github.com/goodhood-eu/goodhood/blob/5f0342b36186f9eccf36930d4cde53626a579b8b/.storybook/ssr/src/index.jsx#L14
This part only uses public APIs.
The difficult part is to setup a working webpack config. To be able to do this, we access some storybook internals. https://github.com/goodhood-eu/goodhood/blob/5f0342b36186f9eccf36930d4cde53626a579b8b/.storybook/ssr/webpack.config.js#L1
Needed public API for a plugin like this:
- Set previewUrl in main.js or somewhere other than CLI args
- Get preview webpack config (don’t think there is a way around patching it)
Would you accept a PR solving this?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:20
- Comments:8 (3 by maintainers)
Top Related StackOverflow Question
One thing to add is that the project I work on is a server rendered app with react. It would be helpful to have our core ui components being rendered in the same way in storybook, to have more confidence in cases where an engineer might access a client side api incorrectly in a server context for example. It would be caught during dev on storybook and not during feature development.
We have a news-site running primarily as SSR. We tweak a lot of things to squeeze as much performance out of the page-render and get the best Core Web Vital scores as possible, although the SSR nature of the site isn’t reflected in Storybook, which is a hassle sometimes. Testing things with vanilla JS - like banners and tracking - is one thing, but we also do a lot of async-loading of assets, which is hard to get a realworld feel for in Storybook, as everything is JS.
We also had a homecooked SSR solution running as middleware, where we could render a component with something like “/ssr?id=components-accordion–story”, but that broke as of 6.4 and we would prefer not to have to find a new way of hacking a solution together again 😃
So I’ll chime in and say a built-in way of SSR components would be awesome.