Skip to content
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: Restore Docs useParameter using DOCS_PREPARED #22118

Merged
merged 7 commits into from Apr 18, 2023

Conversation

tmeasday
Copy link
Member

@tmeasday tmeasday commented Apr 17, 2023

Closes #21798

Telescoping on #22120

What I did

Added a new event DOCS_PREPARED analogous to STORY_PREPARED that emits the parameters of the current docs entry.

  • That's the component's parameters for CSF docs (autodocs + .stories.mdx), and attached MDX docs.
  • That's the project's parameters for unattached MDX docs.

This is in contrast to #22071 which added more impactful events (PROJECT_PREPARED and COMPONENT_PREPARED) which we should think a little more about.

How to test

  1. Run a sandbox, check toolbar (in particular backgrounds) behaviour
    • Check attached MDX, unattached.
  2. Check the same for composition!
  3. See tests

Checklist

  • Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
  • Make sure to add/update documentation regarding your changes
  • If you are deprecating/removing a feature, make sure to update
    MIGRATION.MD

Maintainers

  • If this PR should be tested against many or all sandboxes,
    make sure to add the ci:merged or ci:daily GH label to it.
  • Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

@tmeasday tmeasday force-pushed the tom/21798-fix-useParameter-simpler branch from 77b60e0 to 03fecfe Compare April 17, 2023 04:48
@tmeasday tmeasday changed the base branch from next to tom/21798-add-attached-mdx-to-index April 17, 2023 04:49
@quantizor
Copy link

quantizor commented Apr 18, 2023

Copied from the other thread:

I’d really like to avoid returning nothing during render to avoid FOUC inside the preview window. It would make the dark mode addon have imperfect UX since it couldn’t proactively set dark mode based on config in preview.js.

Really would just love parameters exported from preview to be the default, it would solve all problems I’m aware of. And why wouldn’t you? Isn’t anything in preview.js a global by default?

@tmeasday
Copy link
Member Author

tmeasday commented Apr 18, 2023

I’d really like to avoid returning nothing during render to avoid FOUC inside the preview window. It would make the dark mode addon have imperfect UX since it couldn’t proactively set dark mode based on config in preview.js.

My understanding (based on playing with it and reading the code), is that is what the addon does already in 6.5, at least if you are using storyStoreV7. Were you using ssv7 (code splitting/on demand store) in 6.5 @probablyup?

Really would just love parameters exported from preview to be the default, it would solve all problems I’m aware of. And why wouldn’t you? Isn’t anything in preview.js a global by default?

Yes but it can be overridden on a per-component or per story basis. So you could be browsing from one story to another that both disable an addon, and we could briefly fallback to the project parameters which enable it, and weird things might happen.

@quantizor
Copy link

quantizor commented Apr 18, 2023

My understanding (based on playing with it and reading the code), is that is what the addon does already in 6.5, at least if you are using storyStoreV7. Were you using ssv7 (code splitting/on demand store) in 6.5 @probablyup?

Have not been because CSF doesn’t support dynamic stories, have a big dark mode and variant story generation system I’d love to convert over to a CSF-equivalent when that someday becomes available.

Yes but it can be overridden on a per-component or per story basis. So you could be browsing from one story to another that both disable an addon, and we could briefly fallback to the project parameters which enable it, and weird things might happen.

This is less likely to happen imo and addons can avoid this by listening to events… keeping the default parameter store populated is more important to ensure a consistent experience.

Otherwise you should probably discourage use of parameters to store addon settings, that’s what everyone uses them for.

@tmeasday
Copy link
Member Author

tmeasday commented Apr 18, 2023

This is less likely to happen imo and addons can avoid this by listening to events...

OK, sure but making a change in a patch release (and maybe breaking such addons) is the issue here. I'm open to discussion on what behaviour we want in 7.1 and beyond.

Otherwise you should probably discourage use of parameters to store addon settings, that’s what everyone uses them for.

To be clear most addons use parameters to configure their behaviour in the preview. I'm not sure using parameters to configure manager-side behaviour is a great idea because of exactly this timing issue. I'm not totally sure what the best alternative is though.

@shilman
Copy link
Member

shilman commented Apr 18, 2023

There's a common pattern where addons (backgrounds, i18n, etc) store their state in SB globals, and then parameters set on the story level are used to update the value of the globals are updated by a decorator also provided by the addon.

This is admittedly ugly, but there's no other declarative way to update globals. Would love to find a good way to handle this in the future and it could put a whole swath of related issues--including this one--to bed. Easier said than done, of course!

@shilman
Copy link
Member

shilman commented Apr 18, 2023

@probablyup Re dynamic stories in CSF, we'll be proposing something this quarter over at #9828 in the next month or so. Would love to get your feedback once it's ready. Not a small change, as I'm sure you're aware!

Base automatically changed from tom/21798-add-attached-mdx-to-index to next April 18, 2023 09:56
@shilman shilman changed the title Restore useParameter using DOCS_PREPARED Core: Restore Docs useParameter using DOCS_PREPARED Apr 18, 2023
@shilman shilman merged commit 2c89991 into next Apr 18, 2023
57 checks passed
@shilman shilman deleted the tom/21798-fix-useParameter-simpler branch April 18, 2023 10:03
@tmeasday tmeasday added the patch:yes Bugfix & documentation PR that need to be picked to main branch label Apr 19, 2023
@shilman shilman added the patch:done Patch/release PRs already cherry-picked to main/release branch label Apr 24, 2023
shilman added a commit that referenced this pull request Apr 24, 2023
…-simpler

Restore `useParameter` using `DOCS_PREPARED`
Object.assign(fullAPI, api);

await init();
fullAPI.emit(STORY_PREPARED, {
Copy link

@quantizor quantizor Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential buggy test here @tmeasday, shouldn't this be DOCS_PREPARED?

cc @shilman

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @probablyup

tmeasday added a commit that referenced this pull request Apr 26, 2023
@tmeasday tmeasday mentioned this pull request Apr 26, 2023
5 tasks
JungHoe pushed a commit to JungHoe/storybook that referenced this pull request Apr 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addon: docs bug patch:done Patch/release PRs already cherry-picked to main/release branch patch:yes Bugfix & documentation PR that need to be picked to main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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