storybook: [Bug]: `useParameter` behaviour as you change between stories

Describe the bug

  • Currently the manager only knows the parameter of stories it has rendered before.
  • When you select a story it emits a STORY_PREPARED event which reaches the manager after some delay.
  • Many addons (such as backgrounds) cannot work, and must hide themselves if they don’t see the right parameter.

The net effect of this is when you browse between stories, there is a “flash of hidden toolbars” as the addons hide themselves while they wait for the new story to prepare.

We might also consider the behaviour as the first story loads, as similarly we don’t have parameter information.

To Reproduce

  • Refresh the browser
  • Browse around a sandbox
  • Observe the backgrounds addon carefully.

System

No response

Additional context

To fix this, we might consider:

Falling back to the component + project parameters (we could make them available ala this unmerged PR: https://github.com/storybookjs/storybook/pull/22071)

This generally speaking would work well, but in some examples it might have similar issues of things flashing on and off as it loads. For example when you move between two stories with non-standard settings for the add (perhaps hiding it), the addon would briefly appear.

Continuing to return the previous story’s value until the new story is prepared.

This might be complex to implement, but could be the best solution.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 1
  • Comments: 19 (11 by maintainers)

Most upvoted comments

@tmeasday in DM you proposed a solution where the user can also export parameters from .storybook/manager.js to make sure they are instantly available in the manager.

The behavior would then be:

  • manager.js provides parameter defaults which are available on load
  • those parameters get overwritten by the preview parameters when stories are loaded

This means that you’ll get a FOUC if you don’t specify manager.js parameters OR if they differ from the story parameters. This feels like a really reasonable solution to me, though it does add some weird edge cases, e.g. will there be manager-only parameters if the user adds manager.js parameters that they don’t add to the preview? do we still need localStorage? etc.

what does everybody else think?

Ultimately what I’m looking to achieve is a way for an addon to have config that’s available immediately from anywhere in storybook, regardless of docs or component story type.

I thought preview.js was the right place to initialize that, but if you’re saying it isn’t then yeah we need some documentation explaining the happy path for truly global addon config that doesn’t wait for stories or docs to be loaded before being available.

If it isn’t the fallback parameters, should we add some API to allow addons to get those and fallback themselves?

I think a some addons may have the need to get story meta data a priori (or before rendering) to make assumptions about a story (at least ours do 😄). A declarative way to fetch thosethis meta data would be awesome. At the same time I understand that keeping the API surface small is also something to strive for in terms of maintainability.

Hey @raphaelokon, yes! Sorry I didn’t link them together yet. This is basically a follow-on issue from that discussion that we’ll think about for 7.1. Because we are in post-release mode for 7.0 we are trying to make the change there as small as possible, I hope that makes sense!