React-styleguidist: Make Styleguidist Fast

[tizmagik]

Objective

This is a biggie, but the core of this issue is: _Make styleguidist fast._

The Problem

Semantic UI Components is a superb example of the type of use case react-styleguidist is so well suited to solve. However, the rendered styleguide is painfully slow. Items like #204 will certainly help, but the root of the problem is that we render _all_ components on the start page.

Proposed Solution

There's probably more than a few ways that we can optimize how styleguidist renders the components, but one that I think might have the biggest bang for the buck is to use something like react-virtualized. Although react-virtualized is pitched as mainly meant for tabular data, I think it can fit this use case as well. The key being that we shouldn't render _all_ of the components, just the ones within the viewport.

Challenge

My hunch is that this will require a re-architecture of how we load in/pass components down the tree in react-styleguidist. Right now they're passed in in such a way that I think it would prove difficult to just "pop in" something like react-virtualized (since the components are split by sections). We would also need to be careful with preserving any modified state in the component (e.g. any edits in the CodeMirror box, etc).

Alternatives

Another approach would be to only render one section at a time. This is probably a relatively low hanging fruit, but I think not as nice of a solution as still being able to scroll through _all_ the components in a project as you can today.

---

Anyway, this just a thought and I wanted to get the ball rolling. What do you guys think?

[sapegin]

I think both are very valuable. I’d start from the second because it’s simpler. It can be very useful if you have Markdown documentation (I mean long Markdown files, not just components) — would be nice to have them on separate pages.

[aaronjensen]

Would we still be able to render the whole thing all at once? It's one of the reasons I chose styleguidist, otherwise I probably would have gone with storybook.

[sapegin]

Yeah, I think it should be optional and probably current behaviour should be default.

[aaronjensen]

If a rearchitecture is necessary, it'd be great to consider addressing #162 / #186 simultaneously.

[sapegin]

I believe #186 should be possible already with makeWebpackConfig API method.

[marvinhagemeister]

The biggest performance bottle neck seems to be the whole Code editing tools. CodeMirror is a huge burden, same for in browser compilations. These two together make out roughly 70% of our bundle size last time I looked.

At work we're using react-styleguidist mainly for UX- and Design-Reviews. The showCode Button is only used to get a quick example for devs on how they can incooperate the component. I can see how it may be useful to see how it reacts to different props though.

Just a thought: Instead of supporting complete jsx compilation we could limit the Code-Editor to adding/updating/removing props only. That way the whole in browser compilation step can be avoided and we could drastically reduce our bundle size.

[sapegin]

@marvinhagemeister I disagree with this idea and don’t see much value in that kind of editor.

CodeMirror is not a big issue anymore because it loads only when you open the code.

Using Buble instead of babel-standalone also made bundle size much much smaller.

[marvinhagemeister]

@sapegin I agree that buble is step in the right direction, I'm just wondering if we can remove even that.

[sapegin]

@marvinhagemeister We can make it optional/replaceable since more browsers support ES6 and the only thing they don’t support is JSX. That’s actually a good idea.

[tizmagik]

If we use babel-preset-env then we can target some more modern browsers and transpile less, right? Not sure if this preset has been explored elsewhere for styleguidist.

[sapegin]

@tizmagik It was — no improvement + problems with UglifyJS. See comments in #258.

[tizmagik]

Ah gotcha. I thought UglifyJS supported ES6, but I guess there's issues. Have you tried babel-preset-env + babili for minification?

[sapegin]

As far as I understand how babili works, we can’t use it since we don’t have babel loader anymore or actually any babel in npm package. And user doesn't necessarily will use Babel as well.

[philholden]

Have you had a look at intersection observer it is already shipping in Chrome (it fires an event when an element comes into view):

https://developers.google.com/web/updates/2016/04/intersectionobserver?utm_campaign=chrome_series_nic011_052516&utm_source=chromedev&utm_medium=yt-desc

[sapegin]

@philholden Looks like react-virtualized but you have to write react-virtualized ;-)

[kopax]

@tizmagik thanks for opening this as this is a major improvement/fix.
We have developed the documentation for the following lib :

• https://bootstrap-styled.yeutech.com/

We first thought that the dev mode was making it slow, but in fact, it appear the production takes about 30 seconds to load our page. We will implement a spinner pre react app to make things loading in a decent way.

We expect to implement react-router 4 in the layout, did you consider this as a possible solution?

[ersel]

We use styleguidist at work for our multi-product component library with a few hundred components. As you can imagine, it is quite slow to render! I was going to open an issue to suggest adopting react-virtualized or maybe react-in-viewport, glad to see this issue already exists.

https://www.npmjs.com/package/react-in-viewport

I would be happy to look into this issue if someone familiar with the codebase can point me in the right direction.

[TejasQ]

it is quite slow to render

For us, rendering isn't the issue but more build-time. We're a typescript codebase and it'll take anywhere from 2-5 minutes to start.

We've used all kinds of optimizations and plugins (including running type-checking on another thread) without much success. 😅

I'm wondering how we can improve things. Is there an issue for build time already since this one seems to be scoped for rendering?