-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimizing page rendering via hiding or deactivating CodeMirror until interaction #86
Comments
Maybe autogrowing height of CodeMirror is the reason? |
What do you expect, putting 40 components on one page. |
We can make editors collapsed by default. |
It's also possible to activate the editor on click, so the source code will be shown always. But really, I would consider allowing to create multiple pages. One page style guide solution does not scale in many ways. |
Then we’ll have to highlight it and pray that it want jump too much on enabling ;-) |
@operatino, it can be fast. Look at https://react-bootstrap.github.io/components.html for example. They have 110 examples on the page (btw, they don't show CodeMirror initially, maybe for the same reason 😉). I do agree that it would be nice to be able to select some component and view it separately, but that's an independent feature request. It should be fast even when they are all displayed on one page. @sapegin, I think enable-on-click could be a good idea. But maybe there's a simpler solution (e.g. fixing some widths in CSS)? It's strange that Firefox renders the page so quickly. |
@mik01aj you're comparing plain CSS bootstrap vs complex single page app with lot's of JS base components on it. Fixing "some widths in CSS" is just a temp hack. This also limits any client side code features, since if you're already at full capacity, there's no place for adding some more advanced stuff. |
It’s fast because they do not show editors by default. But there are three things we can do:
@operatino They do exactly the same thing: show bunch of React components on a single page, they just hide editors. |
@operatino that's react bootstrap, rendered via JS (the doc page is a huge react component) and all the code examples are editable. It's pretty similar. The problem here is not JS code, JS is fast (15.4% of the run time), it's the DOM and layout calculations that are so slow (83.5%). |
Okay, I've missed that you shown React Bootstrap, but look deeper. Every component there is server side rendered, which boosts the performance a lot. Also, it's still Bootstrap, which is a set of simple components. In a decent project, you get a lot more complex components with more functionality, which again, doesn't scale at all. |
@operatino would you mind opening a new issue for separate-pages-per-component feature? I'd like to focus on performance in this ticket. |
It’s much bigger feature: grouping components + table of contents + something else :-) |
I even have a solution already - https://github.com/sourcejs/sourcejs-react-bundle-example ;) Which is a higher level wrapper on top of styleguidist. Treat it as an idea for scaling, not the promotion of some specific implementation. |
In first React implementation https://github.com/szarouski/sourcejs-react (quite limited) we also had server side rendering, which I would really like to pair up with styleguidist somewhere in future. |
@operatino That would be cool! |
The separate-pages-per-component feature suggested above by @operatino is reported in #98. @sapegin do we have any decision on this one? If we decide that we should hide CodeMirror initially, i'd rename this issue and close #12 in favour of this one. |
Yes, with an option to change default visibility. But I’m not sure about the default value. |
I have to admit that styleguidist just currently offer a pretty bad UX just because of this speed issue. |
@MoOx That’s why we have a “help wanted” label here. |
To summarize, we'd like to have
|
Is there any quick workaround to remove codemirror (even if that's involved removing the entire code below demo parts). Currently this project is more and more unusable for me, just with 20 components... |
You can override the |
I successfully used a "pre" tag for the editor, but perfs are still very bad. |
That's a surprise to me! Could you send us a screenshot of the timeline? |
I tried recording the timeline again, and have seen a nice surprise! I have 63 components now and the page loads in around 8 seconds. But around 60% of this time is CodeMirror initialization (the highlighted frame triggers |
Shall we close this, given #150 ? |
Yes :) |
Oringinal title for this issue was: Rendering the styleguide in Chrome is awfully slow (because of CodeMirror)
That's a screenshot of the timeline initial render:
Note that the first render is shown only after 45 seconds. The styleguide has around 40 components.
I looked at the timelines, and from what I understand, CodeMirror somewhat updates the DOM in a way that might change the width of the toplevel container. Or maybe just does some pretty ineffective DOM operations (like mixed read/writes).
Interestingly Firefox doesn't have this problem and shows the whole page after around 8 seconds.
The text was updated successfully, but these errors were encountered: