How to lazy load(code splitting) stories(and respective component source)?

Is your feature request related to a problem? Please describe. We have many components(100+) and we want to write stories for all of them, eventually replacing component development with storybook.

The bundle size is growing enormously as we are writing stories for new components. This is affecting initial page load time as all the component JS & stories are loaded on page load.

Describe the solution you’d like We would like to lazy load each story file(which imports component). so that, only JS required to render current stories are loaded. and subsequent navigation to other stories loads additional JS.

Describe alternatives you’ve considered

• Tried dynamically importing each component using react-loadable, but in this case the propTypes/defaultProps/smart-knobs are not read.
• Creating DLL using webpack and injecting it probably(Haven’t tried yet, but this would solve the problem partially)

Are you able to assist bring the feature to reality? May be! Not sure.

Additional context none

[ganapativs]

The official storybook demo has many components and fetches around 8.7MB of uncompressed JavaScript(???).

Lazy loading stories would help in this case. it will also improve the page load performance significantly.

Let’s make this happen! 😬

Update(Feb 2020):

• New storybook examples demo URL: https://next--storybookjs.netlify.com/official-storybook/
• New bundle size: ~8.7MB~9.4 MB uncompressed JavaScript 😱

[tmeasday]

Hey everyone, we’d love to see proper code-splitting in Storybook, we’ve all got big bundles too and it surely isn’t ideal! I know this is one important way Storybook could improve for application development and its definitely something we’ve been thinking about a fair bit.

Let me outline some of the difficulties and ideas/progress towards solutions we’ve had so folks know what’s up and how they can possibly help.

There are two basic ways you could code split in Storybook, both of which have been discussed on this ticket: manual (story-level) and automatic (component-level).

Manual code splitting.

As suggested above by @mcc108, if a story is allowed to be an async function, you use dynamic import()s in the story function:

export const myStory = async () => {
  const MyComponent = import('./MyComponent');
  return <MyComponent x={y} />
}

There’s no fundamental reason SB doesn’t let you do that. In fact we’d like to fully support this in Storybook 6.0 – we have a open ticket about it, and a PR adding support to the html framework.

In fact we kind of need it for the server framework coming in 6.0!

There are probably some kinks with common addons that need to be worked out, and support will need to be framework by framework but if folks pitch in for their favourite framework I think we can make it happen. (NOTE: there are some complexities for React specifically – see this comment – if people have thoughts about that, perhaps reply on that thread).

HOWEVER, there are some serious downsides in using async stories for code splitting:

1. It’s manual, which is a pain.
2. We don’t know about the component for a story until it renders which makes doing stuff like Storybook docs much harder. In theory we could probably make it work (I think?) but it won’t right now. We probably won’t invest in making this happen because of 1.

In short, I really thing async stories is more about other use-cases like loading data/et al. in order to render a story, which is a power tool that should be used with care (can talk more about that elsewhere).

Automatic code splitting

As suggested above by @smurrayatwork, we could use the new stories field of main.js (introduced in 5.3) to generate a lazy require.context (or probably a bewildering array of other webpack techniques to achieve the same effect). However, the details of exactly how the code-split works isn’t the issue.

The challenge is that if you don’t load all the story files right away, how do you display a list of stories in the sidebar? It’s a bit of a chicken and egg problem.

The answer we are moving towards is generating a list of stories (stories.json) at build time. In fact this is something that @ndelangen has already been exploring for the composition feature (coming in 6.0) and it is something that is enabled by the static-exporting CSF feature we shipped back in 5.2 (with one eye on this problem!) [1]

So in short I suspect this is something that is not too far away from being realised although it will require some effort to get it over the line. I am hopeful the building blocks are close to being in place. But we are looking forward to finding what zany things folks are doing in their stories files that breaks stories.json as part of the 6.0 release.

PS – the composition also allows you to break your Storybook up into smaller, more manageable parts and compile them separately, but still load them into a single UI. It’s not exactly a perfect solution (it’s not why we build it) but it could go a long way towards helping with the problem. Perhaps @ndelangen can post a demonstration somewhere.

[1] It’s not really possible to get a list of stories at build time if folks are using storiesOf()