Core: Prevent story-local viewport from persisting in URL#34153
Conversation
…ser globals rather than all globals
📝 WalkthroughWalkthroughThe SET_GLOBALS handler in the globals module has been modified to reference Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes ✨ Finishing Touches
📝 Coding Plan
Comment Tip You can make CodeRabbit's review stricter and more nitpicky using the `assertive` profile, if that's what you prefer.Change the |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
code/core/src/manager-api/tests/globals.test.ts (1)
107-130: Consider asserting post-event state alongside “no emit”.The new test is useful; adding explicit assertions for
globals/userGlobalsafter SET_GLOBALS would make the regression guard tighter and less emission-only.✅ Optional strengthening
channel.emit(SET_GLOBALS, { globals: {}, globalTypes: {}, } satisfies SetGlobalsPayload); expect(listener).not.toHaveBeenCalled(); + expect(store.getState()).toMatchObject({ + userGlobals: {}, + globals: {}, + });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@code/core/src/manager-api/tests/globals.test.ts` around lines 107 - 130, Add assertions after channel.emit(SET_GLOBALS, ...) to verify the module state did not change: assert that store.getState().globals and store.getState().userGlobals remain equal to the pre-event values (the values set via store.setState: globals: { viewport: 'mobile1' } and userGlobals: {}). Locate the test using createMockStore, initModule, and the EventEmitter emitting SET_GLOBALS (and the listener registered on UPDATE_GLOBALS) and add expectations that globals and userGlobals are unchanged in addition to expect(listener).not.toHaveBeenCalled().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@code/core/src/manager-api/modules/globals.ts`:
- Around line 141-147: The current block calls
api.updateGlobals(currentUserGlobals) even when handling non-local refs; tighten
the guard so updateGlobals is only invoked for local refs by adding the same
local-ref condition used elsewhere (the !ref branch) — i.e., ensure you check
the ref/local flag before comparing globals and calling api.updateGlobals (use
the existing symbols currentUserGlobals, globals, deepEqual, and
api.updateGlobals) so non-local SET_GLOBALS cannot trigger an UPDATE_GLOBALS.
---
Nitpick comments:
In `@code/core/src/manager-api/tests/globals.test.ts`:
- Around line 107-130: Add assertions after channel.emit(SET_GLOBALS, ...) to
verify the module state did not change: assert that store.getState().globals and
store.getState().userGlobals remain equal to the pre-event values (the values
set via store.setState: globals: { viewport: 'mobile1' } and userGlobals: {}).
Locate the test using createMockStore, initModule, and the EventEmitter emitting
SET_GLOBALS (and the listener registered on UPDATE_GLOBALS) and add expectations
that globals and userGlobals are unchanged in addition to
expect(listener).not.toHaveBeenCalled().
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c9332071-6db7-40be-bcc3-e6908860604c
📒 Files selected for processing (2)
code/core/src/manager-api/modules/globals.tscode/core/src/manager-api/tests/globals.test.ts
|
View your CI Pipeline Execution ↗ for commit e6470d8
☁️ Nx Cloud last updated this comment at |
Core: Prevent story-local viewport from persisting in URL (cherry picked from commit b00ebfa)
Closes #34133
What I did
When a story has a defined
viewportglobal (in code), that value should not be synced with the URL, because otherwise the value will stick around in the URL and apply to stories which otherwise do not have a viewport specified. To fix this issue, I've updated the globals state handler to only syncuserGlobals(rather thanglobals) back to the globals state whenSET_GLOBALSis emitted.Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
viewportglobal, and some without.Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal,ci:mergedorci:dailyGH 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.tsMake 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 pull request has been released as version
0.0.0-pr-34153-sha-e6470d88. Try it out in a new sandbox by runningnpx storybook@0.0.0-pr-34153-sha-e6470d88 sandboxor in an existing project withnpx storybook@0.0.0-pr-34153-sha-e6470d88 upgrade.More information
0.0.0-pr-34153-sha-e6470d88fix-persistent-story-viewporte6470d881773654173)To request a new release of this pull request, mention the
@storybookjs/coreteam.core team members can create a new canary release here or locally with
gh workflow run --repo storybookjs/storybook publish.yml --field pr=34153Summary by CodeRabbit