Summary

Back in SB 7, Atlassian maintained a React render performance addon, which shows various render performance metrics:

The addon is unmaintained by its authors, only works for React, and doesn't make use of SB 9's new testing APIs and status store.

Remaking the addon in a modern fashion raises a few questions about how addons can best add tests to the Storybook UI or exploit existing stories as test data. This RFC is about discussing and resolving these questions.

Problem Statement

Contamination of performance measurements

A performance addon must instrument or wrap story render functions without framework-specific code. It needs to accurately measure the performance of render functions.

Wrapping story renders is currently achieved with beforeEach and afterEach hooks. on stories. When doing so, performance measurements can be contaminated by code running from other addons (e.g. addon-a11y). An addon that measures performance must have a way to avoid side effects from Storybook.

Repeat-rendering of stories

A performance addon should be able to run stories multiple times to smooth over noise in performance measurements. To the best of my knowledge, this is not currently possible.

An approach could be to create a custom decorator that renders a story n times in a row, but that poses several issues:

• It's not framework-agnostic
• It means the decorator is tasked with detecting when a story is done rendering, even though Storybook already performs that logic

Other approaches would likely need new API development in Storybook.

Handling detection of render function end

Separately from the issues arising from my attempt to modernise storybook-addon-performance, @Stadly reported on #29583 (comment) that they have use cases where addon-a11y's afterEach hook triggers too early and ignores ongoing animations, resulting in false positives.

There may be other use cases like that where developers should be given a hook that detects when a story is done rendering. This could need to be ordered before or after measurement addons based on what is being measured.

Non-goals

We're not looking for native support of performance tests, but for an addon-based solution. Extending the capabilities of addons will give end users more flexibility and addon authors more options to provide value around stories.

Implementation

Contamination of performance measurements

An API change is needed. Options include:

• letting an addon hook onto a story in isolation from other hooks, or even run tests in isolation on a story (similar to [RFC]: Add the .test method to CSF factories #30119)
• options in the "before/afterAll" hooks to prioritise their order of execution, so that measurements are run closest to the story render and reporting-style hooks like the a11y hooks are run furthest from it
  • either with predefined hook keywords (e.g. 'detectEnd', 'measure', 'test', 'report')
  • or with a numerical order property defined on hooks, with sane defaults for internal Storybook addons that give addon authors flexibility

Repeat-rendering of stories

No clue what the options are here. In the .test RFC, I argued at some point it would be great to let developers load stories in the form of data suites for tests. If that was something addon authors could tap into, the .test method could be given an option to run multiple times, or addon authors could handle multiple runs themselves.

Handling detection of render function end

This is the same issue as the measurement contamination one. Developers would likely want a dedicated hook whose purpose is to hold until animations or other async events are done running.

Prior Art

• The afterEach RFC
• The .test RFC

Deliverables

No response

Risks

No response

Unresolved Questions

• How to allow addon authors to wrap/intercept a story render in isolation from other addons
• How to allow multiple runs of a story for performance measurement
• How to let developers control the logic that detects when a story is done rendering

Alternatives considered / Abandoned Ideas

No response