storybook: [Bug]: useParameter() returns nothing for a docs page

@raphaelokon no problem at all, in fact it was helpful to think about this use case! I was just noting it because the focus here is to fix the regression in 7.0, rather than necessarily solve every problem with useParameter()/api.getParameters().

@probablyup yes, in fact as of https://github.com/storybookjs/storybook/pull/22071 we’d supply the component’s parameters (ie. what’s defined in the default export of the CSF file + the project’s parameters defined in preview.js) in this case.

Would that be a good or a bad thing for your use case @raphaelokon? So your call of storybookAPI.getParameters(item.id) would return:

• the project’s parameters before you render any story for the component
• the component’s parameters before you render story in question (if you render a sibling)
• the story’s parameters once you’ve rendered the story.

The inconsistency doesn’t sit super well with me but maybe it’s better than nothing as @probablyup implies.

As an aside the issue of not getting a sibling story’s parameters is an issue in the v7 (on demand) store prior to 7.0, IIUC, whereas this bug specifically talks about a regression in docs pages in 7.0 (just to be clear for anyone following along).

Hey @probablyup, thanks for calling this out. We’ve taken another look at this.

The root of the problem is that with the new docs architecture, when you view docs there isn’t an underlying story. In 6.5 there always was (although it was a bit of a kludge in the case of .mdx files). What that meant in 6.5 was that you could always get parameters when visiting a docs page, because there’d always be a story to read them off. In the case of .mdx files, that was just the project-level parameters (preview.js), which happened to work great for this addon.

In any case, we did look at this problem when migrated some of our own addons but ultimately decided in the cases where they needed useParameter() it didn’t really make sense to even do that on docs pages, and so we thought the changed behaviour was probably the best way forward.

Having seen this example, it does seem like there are/will be other addons that do need the project-level parameters to be available all the time. So we’ll look at making it work again on docs pages.

As we are super late in the 7.0 release cycle, we need to be a bit careful about how we do this. We’ll likely release the new mechanism in a 7.1 alpha in the near future, test it a little, and backport it as a bug fix in 7.0.x patch release.

Hmmm, that’s pretty weird. I’m not sure what to suggest there, can you turn on logLevel: 'debug' and check the console messages for the setIndex event? It should have the parameters in there for the docs entries. In 7.0.6 it wouldn’t have parameters for docs entries. In 7.0.7:

@tmeasday Tested this out and nothing appears to have changed for 7.0.7. Is the useParameter hook re-triggered when that DOCS_PREPARED event is emitted? Trying to understand how to patch https://github.com/hipstersmoothie/storybook-dark-mode/blob/master/src/Tool.tsx to support the new scenario.

Crikey!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.1.0-alpha.6 containing PR #22120 that references this issue. Upgrade today to the @future NPM tag to try it out!

npx sb@next upgrade --tag future

@probablyup can you comment on https://github.com/storybookjs/storybook/issues/22119 with regards to that? I’m interested in both the initial FOUC and the FOUC as you change stories, which potentially could be handled differently.

For SB dark mode it’s unlikely you’d set the parameters differently per story or per component, so changing stories is not really a consideration, but that’s not the only addon that calls useParameters() and changing the behaviour of other addons to fallback to the project parameters may have unexpected issues, which is why we are being cautious here late in the 7.0 cycle.

In terms of https://github.com/storybookjs/storybook/pull/22118, AFAIK it restores the 6.5 behaviour so is safe to merge into 7.0 as a patch release/bug fix.

@raphaelokon so after some discussion with @shilman, we are going to take a simpler approach in https://github.com/storybookjs/storybook/pull/22118.

What this will mean is that getParameters() will still display the current behaviour for stories that haven’t been rendered yet (that is returning nothing).

There seem to be two clear use cases for knowing the project/component parameters on the manager side:

1. To fallback if we don’t yet know the story’s parameters, if you are examining a story that’s not the current story (your use case).
2. To fallback as we wait for the story to prepare (https://github.com/storybookjs/storybook/issues/22119). In this case it isn’t clear that falling back is even the correct solution, would love to hear people’s thoughts.

So regarding 1. I’d like to hear more about your use case. Which parameters do you need exactly to renderLabel? Do they change between components/stories?

@shilman Aye. Interestingly once I browse the other sibling story it gets the parameters and the label is displayed for both.

This is an intentional breaking change. I couldn’t find it in MIGRATION.md, but maybe I just missed it. I realize that doesn’t solve your problem though.

@tmeasday can you please weigh in on this? storybook-dark-mode is a popular addon, and although we don’t maintain it, it would be great if we could figure out how to get it updated.

cc @jonniebigodes @Integrayshaun