Pre-rendered / SSR (server side rendered) stories

[peterhass]

This topic has already occurred several times without any proper solutions or discussions on how to implement this in the future.
#8009
#828
#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.js registers a custom SSR middleware
• SSR middleware injects a custom webpackDevMiddleware and listens to requests to /ssr-iframe
• On GET /ssr-iframe we 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?

[shilman]

@peterhass thanks so much for filing this and also for the research and prototyping work you've done so far. very exciting stuff!

our focus for 6.1 is performance, so this could be a great fit for that theme. can you share any info (pref quantified, but qualitative fine too) about the storybook performance before and after this modification? if you submit a PR, our CI will run an automated benchmark against it.

• Set previewUrl in main.js or somewhere other than CLI args

I think specifying previewUrl in main.js sounds reasonable.

• Get preview webpack config (don't think there is a way around patching it)

You should be able to do this already with webpack or webpackFinal preset exports, but maybe you have something different in mind.

A few more questions:

1. Aside from performance benefits, what is the other rationale for this change?
2. Do you envision this as an addon, or built into core?
3. Is this react-specific or can this apply to all the frameworks we support?

Please let me know what you think and I'd love to figure out how to make this happen, esp if it benefits browse-time perf.

[shilman]

related: we have a new package called @storybook/server that's for server-rendered pages. it's been used to create a "storybook for rails" for example. i'm wondering if we could use that to achieve your objectives. cc @tmeasday @jonspalmer

https://github.com/storybookjs/storybook/blob/next/app/server/

[peterhass]

You should be able to do this already with webpack or webpackFinal preset exports, but maybe you have something different in mind.

I don't think the current preset api is sufficient for this use case. The original preview cannot be used because I need a webpackDevMiddleware with serverSideRender turned on. That's why I decided to use a custom preview-url so that I can do all that stuff on my own. The preset api would need to provide a way to change webpackDevMiddleware or some way to get the preview webpack config when initialising the SSR webpackDevMiddleware.

To your questions:

1. We built it for the sole purpose of checking how components behave when being pre-rendered and hydrated. Performance improvements may be achievable. The prototype I built renders components on-demand, therefore the performance is currently slower than usual.
2. It’s not react specific. it should work with every framework that supports pre-rendering.
3. Initially I envisioned this as a react-specific addon. I only thought of it as a way to ‘smoke test’ our components for pre-rendering. It would be a bit ‘hacky’ because of the custom framework code and webpack config patching but it would be maintainable. As a performance improvement, it should definitely go into core.

Ideas on how this can improve performance?

• Pre-render components as soon as they change? -> Longer build time, (maybe?) faster on first and continuous visits

Edit: Don't think @storybook/server is very helpful for this purpose. It doesn't need to do the difficult part - the pre-rendering of components. Even if we extract this part to an external server/service, we still need a webpack configuration very near to storybook's one to not loose support for addons, configuration, etc.

[JamieMason]

A few more questions:

Aside from performance benefits, what is the other rationale for this change?

@shilman #12542 (comment)

One use-case we have is wanting to run https://speedcurve.com against static builds of storybook, so we can track things like CLS on a per-component basis over time. This isn't feasible currently as the stories at /iframe.html?id=YOUR_ID&viewMode=story are rendered entirely with JS. Our hope is that the HTML could be rendered at build-time, this is how I stumbled on this issue.

I hope this is useful/relevant, thanks for your time.

[kelly-tock]

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.

[phun-ky]

We would like this,so we can use stories in gatsby builds.

[aarfing]

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.

[maurerbot]

+1

[lednhatkhanh]

Since 7.0 was release with Nextjs support, do you have plans for SSR storybook integration? Thank you.

[rake7h]

+1