Interactions: Add step function and support multiple levels of nesting

[ghengeveld]

What I did

Added a step function on the play function's context object. The step function effectively works like a Jest describe block, where you provide a label and a callback function as arguments:

Demo.play = async ({ args, canvasElement, step }) => {
  await step('One', async () => {
    // do things
  })
  await step('Two', async () => {
    // do more things
  })
}

Note that for the time being it's not possible to debug interactions inside a step function (similar to waitFor). That's out of scope for this PR.

How to test

• Is this testable with Jest or Chromatic screenshots? yes
• Does this need a new example in the kitchen sink apps? no
• Does this need an update to the documentation? yes

If your answer is yes to any of these, please make sure to include it in your PR.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 26ec0e6. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx run-many --target=prepare --all --parallel=8 --max-parallel=15 -- --reset --optimized

---

Sent with 💌 from NxCloud.

[ghengeveld]

@tmeasday @shilman I'd like to get your 👍 on the decision to pass step on the play function's context argument. This way we make it a core part of the play function and avoid having to import it (I wouldn't know where from, except perhaps @storybook/instrumenter). The downside is that @storybook/preview-web gains a dependency on @storybook/instrumenter because of this.

[tmeasday]

Hmm, I'm not sure we want to add that dependency. I wonder if we should have a (basically hidden) mechanism where addons can add fields to the story/play context?

Although even if we do that there's a typing issue (how does Story.play({ step }) get the right type?). It's tricky. WDYT @shilman?

[ghengeveld]

Hmm, I'm not sure we want to add that dependency. I wonder if we should have a (basically hidden) mechanism where addons can add fields to the story/play context?

What would that mechanism look like?

[tmeasday]

OK, let's go for something in between:

• We'll add an undocumented preset export step that ends up on the projectAnnotations, defaulting to f => f()
• We'll add step to the PlayFunctionContext type
• The preview will pass the projectAnnotations.step function to play().

How does that sound @ghengeveld?

[ghengeveld]

• We'll add an undocumented preset export step that ends up on the projectAnnotations, defaulting to f => f()

What happens if someone sets up another addon which exports a step value like that? Do we compose them? I suppose if we default it to f => f() we can just compose that with instrument.

[tmeasday]

I was thinking it's just last one wins with maybe a warning. (Thus the undocumented).

Unless you think composing makes more sense?

[ghengeveld]

@wKich this might be of interest to you.

[ghengeveld]

This should be rebased off future/base

[yannbf]

One note about this change: it will break @storybook/testing-react and the like. The mechanism to get the step function ideally should be simple so it can be automated without the user doing anything

[tmeasday]

@yannbf if the default is f => f() I don't think it'll break anything if it isn't explicitly set anywhere?

[tmeasday]

LGTM!

[shilman]

@ghengeveld can you please review the chromatic change?

[ghengeveld]

The debugger seems broken right now. Need to investigate.

[ghengeveld]

@shilman This is good to go. Not sure what's up with cra-bench, seems like a Playwright or config issue unrelated to this PR.

[IanVS]

I suppose this needs to be added to the vite builder as well now, right?

[tmeasday]

Oh! Yeah definitely. Did we miss this too? 🤦