fix: creating new release immediately pins as perspective

[jordanl17]

Description

A PR of 2 halves: 1 simple, 1 more involved:

Simple:
For pinning the new release when created from the perspective menu, or from the 'copy to new release' flow, it's possible to just setPerspective to assign the perspective sticky param. This is because we don't navigate elsewhere when a release is created in these flows.

More:
In the other flow where a release can be created - from 'create release' CTA in releases overview, we already navigate to the release detail page after creation.

This causes some issues - calling router.navigateStickyParams (which is used by setPerspective), followed immediately by router.navigate to navigate to the release detail, causes a race, where navigate knows nothing about the perspective stickyParam, so the end result is that the release is not pinned, but you are still navigated to the release details.

One option could be to resolve this by flushing the event loop and making navigateStickyParams async, but that feels rather too hacky.

This PR takes the approach of extending navigate in the router. It's now possible to provide an options.stickyParams object, which is much the same as the argument already passed to navigateStickyParams. Doing this means that navigate can both update the router state and params together.

This perhaps raises a question around whether this approach could deprecate navigateStickyParams - but given navigateStickyParams is already in the wild, perhaps it's best we keep it around.

What to review

• Does extending the options on router.navigate make sense

Testing

Manually verified that pinning works in all places where a new release can be created

Also added tests for RouterProvider given the adjustments there. Ran these tests against the next RouterProvider (only the relevant ones given no stickyParam support for navigate in next, and verified no regressions to functionality

Notes for release

navigate from useRouter now supports a stickyParams option to allow for navigating and updating param state in the studio at once.

navigateStickyParams is deprecated from sanity/router - instead use navigate as follows:

const router = useRouter()

router.navigate(null, {stickyParams: {paramKey: 'paramValue'}, replace: false})

Additionally, it's now possible to update route state and set stickyParams together:

const router = useRouter()

router.navigate({stateKey: 'stateValue'}, {stickyParams: {paramKey: 'paramValue'}})

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 17, 2025 10:57am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 17, 2025 10:57am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 17, 2025 10:57am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Feb 17, 2025 10:57am
test-next-studio	⬜️ Ignored (Inspect)			Feb 17, 2025 10:57am

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.73%	54309 / 127085
🔵	Statements	42.73%	54309 / 127085
🔵	Functions	48.1%	2787 / 5794
🔵	Branches	79.33%	10546 / 13293

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/perspective/useExcludedPerspective.tsx	76.19%	100%	66.66%	76.19%	26-32
packages/sanity/src/core/perspective/useSetPerspective.tsx	69.23%	100%	50%	69.23%	12-17
packages/sanity/src/core/releases/components/dialog/CreateReleaseDialog.tsx	78.37%	100%	100%	78.37%	57-64, 78-94
packages/sanity/src/core/releases/tool/overview/ReleasesOverview.tsx	93.37%	86.25%	75%	93.37%	96, 130-131, 149, 165, 256-267, 274-278
packages/sanity/src/router/RouteScope.tsx	9.09%	100%	0%	9.09%	8-19, 67-126
packages/sanity/src/router/RouterProvider.tsx	96.92%	95.65%	100%	96.92%	156-157, 168-169
packages/sanity/src/router/types.ts	0%	0%	0%	0%

Generated in workflow #30506 for commit bedeabd by the Vitest Coverage Report Action

[github-actions]

No changes to documentation

[github-actions]

⚡️ Editor Performance Report

Updated Mon, 17 Feb 2025 11:03:45 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	27.0 efps (37ms)	25.6 efps (39ms)	+2ms (+5.4%)	✅
article (body)	84.0 efps (12ms)	77.8 efps (13ms)	+1ms (-/-%)	✅
article (string inside object)	29.4 efps (34ms)	27.0 efps (37ms)	+3ms (+8.8%)	✅
article (string inside array)	25.6 efps (39ms)	23.8 efps (42ms)	+3ms (+7.7%)	✅
recipe (name)	52.6 efps (19ms)	52.6 efps (19ms)	+0ms (-/-%)	✅
recipe (description)	58.8 efps (17ms)	58.8 efps (17ms)	+0ms (-/-%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	+0ms (-/-%)	✅
synthetic (title)	20.8 efps (48ms)	20.4 efps (49ms)	+1ms (+2.1%)	✅
synthetic (string inside object)	21.7 efps (46ms)	20.4 efps (49ms)	+3ms (+6.5%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	37ms	43ms	48ms	276ms	125ms	9.9s
article (body)	12ms	14ms	27ms	180ms	219ms	5.4s
article (string inside object)	34ms	35ms	36ms	61ms	119ms	6.1s
article (string inside array)	39ms	43ms	47ms	233ms	244ms	6.8s
recipe (name)	19ms	20ms	23ms	36ms	3ms	7.8s
recipe (description)	17ms	19ms	20ms	33ms	0ms	4.5s
recipe (instructions)	5ms	7ms	8ms	26ms	0ms	3.2s
synthetic (title)	48ms	52ms	67ms	338ms	765ms	14.2s
synthetic (string inside object)	46ms	48ms	53ms	238ms	601ms	8.3s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	39ms	46ms	66ms	432ms	870ms	10.8s
article (body)	13ms	15ms	23ms	224ms	319ms	5.2s
article (string inside object)	37ms	40ms	43ms	273ms	339ms	7.3s
article (string inside array)	42ms	46ms	52ms	155ms	367ms	7.3s
recipe (name)	19ms	20ms	24ms	36ms	0ms	6.7s
recipe (description)	17ms	19ms	21ms	30ms	0ms	4.5s
recipe (instructions)	5ms	7ms	8ms	23ms	0ms	3.1s
synthetic (title)	49ms	51ms	57ms	145ms	824ms	13.5s
synthetic (string inside object)	49ms	52ms	66ms	239ms	593ms	7.8s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[github-actions]

Component Testing Report Updated Feb 17, 2025 11:08 AM (UTC)

❌ Failed Tests (3) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 8s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	12s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	2m 35s	3	0	3
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	52s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	15s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	27s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 8s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 36s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	2m 5s	21	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	27s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 45s	21	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0

[bjoerge]

Seems like this refactor should be the other way around? The replace-option belongs in NavigateOptions, not NavigateStickyParamsOptions, no?

[jordanl17]

Hmm, so the reason I did it this way round was because although it feels more intuitive that NavigateStickyParamOptions extends from NavigateOptions, NavigateOptions is the only one to include options.stickyParams.

Perhaps I can just do type NavigateStickyParamOptions = Omit<NavigateOptions, 'stickyParams'> so it feels more natural?