-
-
Notifications
You must be signed in to change notification settings - Fork 9.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
Core: Show "booting" progress until story is specified or errors #20425
Core: Show "booting" progress until story is specified or errors #20425
Conversation
(Or an error occurs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good first step, makes it way better at least.
But in general I'm not a fan of showing a progress bar to users when progress can't be determined, but that's a minor thing. We probably need an indetermined loading spinner or similar in general in our UI.
What if you added a timeout to only show this after like 100-200ms? |
One issue we are trying to avoid is having too many different spinners[1] flash up in the early stages, so I think a better UI would be some version of a progressbar that is clearly indeterminate. [1] First we show the loading progress bar as the build is compiled, then we show this thing while |
Co-authored-by: Jeppe Reinhold <jeppe@chromatic.com>
Actually @JReinhold @yannbf I changed my mind on this. Looking closer, we already show a circular spinner for a moment when a SB first starts (before the entry loads) so I might as well keep it simple and simply augment the existing logic to wait a bit longer (for the story to be specified by the preview -- which happens after initialization -- rather than when configured). |
Sounds good and looks better! Could you check the behavior with a composed storybook? |
This is all we had for refs too, and the logic for keeping it simple is the same.
Thanks for the prompt to check properly @yannbf. When I did so I ran into some problems and decided I was just adding some extra complexity to some code that was more complex than it needed to be already. So I simplified things to just have a @ndelangen you should probably check this as the original author. |
@tmeasday I'll do a proper review of this next week. |
No, definitely not intended @yannbf, I'll take a closer look. |
Ok, I improved it, although we still need to figure out the old events. Thanks for the tip @yannbf. I think this also highlights that we remove the |
@tmeasday maybe |
@tmeasday I'm taking a look at those errors! The typings of globalThis for this package are defined here:
I was able to get it green, but not without a minor changes to a laundry-list of I'll open a telescope PR, so I can show the changes, and we can discuss further. |
Thanks @ndelangen ! |
…ttps://github.com/storybookjs/storybook into tom/sb-1123-sb20250-vite-does-not-show-a-spinner-2
@ndelangen @yannbf OK, this is ready to go I think, apart from the globals issue. As discussed with @yannbf I:
|
…eck-work-valid make changes to typings files to ensure this the check command succeeds
Thanks for making it green! Any change of a ✅ from @ndelangen or @yannbf? |
@tmeasday will put a calender event om my monday morning to review 👍 |
Issue: #20250
What I did
Show the progress bar on the preview component until we learn the story is specified or an error occurs.
If preview.js takes a long time to load, the story specified event will not fire until it is done.
A (potential) downside here is you always see the above briefly while the SB is loading.
How to test
Add a "speed loop" to a preview.js, then load the SB: