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

Portable stories: Improve existing APIs, add loaders support #26267

Merged
merged 11 commits into from
Mar 4, 2024

Conversation

yannbf
Copy link
Member

@yannbf yannbf commented Feb 29, 2024

Closes #26251

What I did

This PR adds a few (big impact) bug fixes to the portable stories APIs:

  • Portable stories for Vue3 now support decorators correctly
  • Project annotations passed to composeStory are now merged correctly with the default project annotations coming from the renderers (can be seen as a breaking change)
  • Globals can be passed as project annotations

It also adds the following features/improvements:

  • Loaders are now supported
  • The play function does not need context anymore (but can still be passed)

Apart from the fixes, this PR introduces a breaking change to a portable story's play function, described below:

When reusing a story that has a play function, you don't have to pass the context anymore, not even the canvasElement. The context is built-in and if you don't pass overrides, it will still be present. It is still possible to pass overrides to the context, if you'd like.

const { Primary } = composeStories(stories);
test("load and render", async () => {
  const { container } = render(<Primary />);
  // before:
  await Primary.play({ canvasElement: container, ...ArgsOrWhateverElse });

  // after:
  await Primary.play();
});

In order for this to be possible, the portable stories API now adds a wrapper to your stories with a unique id based on your story id, such as:

<div data-story="true" id="#storybook-story-button--primary">
  <!-- your story here -->
</div>

This means that if you take DOM snapshots of your stories, they will be affected and you will have to update them.

The id calculation is based on different heuristics based on your Meta title and Story name. When using composeStories, the id can be inferred automatically. However, when using composeStory and your story does not explicitly have a storyName property, the story name can't be inferred automatically. As a result, its name will be "Unnamed Story", resulting in a wrapper id like "#storybook-story-button--unnamed-story". If the id matters to you and you want to fix it, you have to specify the exportsName property like so:

test("snapshots the story with custom id", () => {
  const Primary = composeStory(
    stories.Primary,
    stories.default,
    undefined,
    // If you do not want the `unnamed-story` id, you have to pass the name of the story as a parameter
    "Primary"
  );

  const { baseElement } = render(<Primary />);
  expect(baseElement).toMatchSnapshot();
});

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

  • stories
  • unit tests
  • integration tests
  • end-to-end tests

Manual testing

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

Documentation

  • Add or update documentation reflecting your changes
  • If you are deprecating/removing a feature, make sure to update
    MIGRATION.MD

Checklist for Maintainers

  • When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

  • Make sure this PR contains one of the labels below:

    Available labels
    • bug: Internal changes that fixes incorrect behavior.
    • maintenance: User-facing maintenance tasks.
    • dependencies: Upgrading (sometimes downgrading) dependencies.
    • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
    • cleanup: Minor cleanup style change. Will not show up in release changelog.
    • documentation: Documentation only changes. Will not show up in release changelog.
    • feature request: Introducing a new feature.
    • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
    • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

Copy link
Contributor

github-actions bot commented Feb 29, 2024

Fails
🚫 PR is marked with "BREAKING CHANGE" label.

Generated by 🚫 dangerJS against 6dae91d

@yannbf yannbf force-pushed the feature/portable-stories-optional-context branch from cfb4efc to 5430cf4 Compare March 4, 2024 10:54
@yannbf yannbf changed the title Portable stories: Make canvasElement optional in the play function Portable stories: Improve existing APIs, add loaders support Mar 4, 2024
@yannbf yannbf force-pushed the feature/portable-stories-optional-context branch from 5430cf4 to 6dae91d Compare March 4, 2024 10:58
Copy link
Contributor

@JReinhold JReinhold left a comment

Choose a reason for hiding this comment

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

LGTM! ❤️

@yannbf yannbf merged commit d7900ad into next Mar 4, 2024
55 of 56 checks passed
@yannbf yannbf deleted the feature/portable-stories-optional-context branch March 4, 2024 12:30
@github-actions github-actions bot mentioned this pull request Mar 4, 2024
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Portable stories - Make context optional in reused play function
2 participants