Instrumenter: Fix userEvent.type performance regression #32439
Merged
+6
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did
Add getKeys filter to exclude 'eventWrapper' property from instrumenter calls to prevent performance regression in userEvent.type operations. This addresses the slowdown reported when upgrading from Storybook 8 to 9 with addon-vitest.
The instrumenter was spending significant time sorting large arrays of calls that included the eventWrapper property, which is not needed for testing interactions. By filtering it out at the instrumentation level, we avoid unnecessary processing overhead.
Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli-storybook/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>
Greptile Summary
Updated On: 2025-09-11 09:06:36 UTC
This PR addresses a performance regression in userEvent.type operations that occurs when upgrading from Storybook 8 to 9, particularly affecting users of addon-vitest. The fix involves filtering out the 'eventWrapper' property from instrumenter calls at two key locations in the testing utilities.
The core issue was that Storybook's instrumenter was processing the 'eventWrapper' property from
@testing-library/user-event
, which contains large arrays of internal call data. The instrumenter would spend significant time sorting and processing these arrays even though this property isn't needed for testing interactions. By adding agetKeys
filter that excludes 'eventWrapper', the PR prevents this unnecessary overhead.The changes are applied consistently across both
testing-library.ts
andpreview.ts
, ensuring that the performance optimization works uniformly for all instrumented testing utilities. The fix is surgical and targeted - it only affects how the instrumenter processes userEvent objects without changing the broader instrumentation behavior or testing functionality.Confidence score: 4/5