feat(sanity): refine release toasts

[juice49]

Description

This branch continues the work of refining toasts, focusing on Content Releases. Primarily, this means removing success toasts when it's apparent in the UI that the operation was successful.

What to review

Do all the removals make sense? The commits are atomic, so it's probably easiest to look over them to see the individual changes.

Testing

Tested in browser. Existing tests succeed.

[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	Mar 12, 2025 2:53pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 12, 2025 2:53pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 12, 2025 2:53pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Mar 12, 2025 2:53pm
test-next-studio	⬜️ Ignored (Inspect)			Mar 12, 2025 2:53pm

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.01%	54419 / 129523
🔵	Statements	42.01%	54419 / 129523
🔵	Functions	46.89%	2729 / 5820
🔵	Branches	79.3%	10181 / 12837

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/i18n/bundles/studio.ts	100%	100%	100%	100%
packages/sanity/src/core/releases/components/dialog/DiscardVersionDialog.tsx	82.25%	9.09%	50%	82.25%	35-50, 76
packages/sanity/src/core/releases/i18n/resources.ts	100%	100%	100%	100%
packages/sanity/src/core/releases/tool/components/ReleaseMenuButton/ReleaseMenuButton.tsx	99.38%	96.29%	100%	99.38%	51
packages/sanity/src/core/releases/tool/components/ReleaseMenuButton/releaseActions.ts	100%	100%	100%	100%
packages/sanity/src/core/releases/tool/components/releaseCTAButtons/ReleasePublishAllButton.tsx	97.36%	94.44%	75%	97.36%	72, 74-75, 157
packages/sanity/src/core/releases/tool/components/releaseCTAButtons/ReleaseScheduleButton.tsx	66.25%	46.15%	50%	66.25%	74, 78-124, 141-144, 150-156, 163-185, 194-196, 247-252, 261-262, 265-266, 269-270
packages/sanity/src/core/releases/tool/components/releaseCTAButtons/ReleaseUnscheduleButton.tsx	48.27%	50%	33.33%	48.27%	33-56, 62-86
packages/sanity/src/core/releases/tool/detail/ReleaseSummary.tsx	70.44%	71.42%	66.66%	70.44%	98, 108-153, 162-166, 172-173

Generated in workflow #32181 for commit fcd3b1f by the Vitest Coverage Report Action

[github-actions]

No changes to documentation

[github-actions]

⚡️ Editor Performance Report

Updated Wed, 12 Mar 2025 15:44:29 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	15.5 efps (65ms)	17.9 efps (56ms)	-9ms (-13.2%)	✅
article (body)	72.2 efps (14ms)	67.6 efps (15ms)	+1ms (-/-%)	✅
article (string inside object)	19.6 efps (51ms)	18.2 efps (55ms)	+4ms (+7.8%)	✅
article (string inside array)	17.9 efps (56ms)	16.7 efps (60ms)	+4ms (+7.1%)	✅
recipe (name)	43.5 efps (23ms)	43.5 efps (23ms)	+0ms (-/-%)	✅
recipe (description)	47.6 efps (21ms)	45.5 efps (22ms)	+1ms (+4.8%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (6ms)	+1ms (-/-%)	✅
synthetic (title)	16.5 efps (61ms)	18.5 efps (54ms)	-7ms (-10.7%)	✅
synthetic (string inside object)	18.9 efps (53ms)	20.0 efps (50ms)	-3ms (-5.7%)	✅

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)	65ms	84ms	107ms	362ms	2018ms	13.8s
article (body)	14ms	16ms	18ms	69ms	192ms	5.8s
article (string inside object)	51ms	54ms	62ms	210ms	1334ms	9.1s
article (string inside array)	56ms	61ms	67ms	254ms	1399ms	9.1s
recipe (name)	23ms	25ms	29ms	43ms	0ms	8.2s
recipe (description)	21ms	22ms	23ms	44ms	0ms	5.0s
recipe (instructions)	5ms	7ms	9ms	18ms	0ms	3.3s
synthetic (title)	61ms	69ms	80ms	257ms	1295ms	13.5s
synthetic (string inside object)	53ms	55ms	60ms	219ms	1110ms	8.1s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	56ms	81ms	103ms	391ms	1668ms	13.3s
article (body)	15ms	16ms	21ms	39ms	73ms	5.2s
article (string inside object)	55ms	57ms	59ms	64ms	968ms	8.5s
article (string inside array)	60ms	65ms	67ms	167ms	1362ms	9.0s
recipe (name)	23ms	24ms	37ms	57ms	14ms	7.9s
recipe (description)	22ms	22ms	24ms	57ms	0ms	5.0s
recipe (instructions)	6ms	7ms	8ms	9ms	0ms	3.2s
synthetic (title)	54ms	57ms	65ms	214ms	938ms	13.1s
synthetic (string inside object)	50ms	52ms	57ms	210ms	727ms	8.0s

📚 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.

[RitaDias]

✅

[RitaDias]

This is not a blocker, I find this one to be the one that I thought might make most sense to keep, but this is a rehash of the discussion we've had in previous PRs. Not a blocker, just a thought that success messages should probably remain in place, not married to this though 🤷

[juice49]

Thanks for pointing it out, Rita. I do share your concern. Removing it is consistent with removing the archive/unarchive success toasts, where the success state is reflected in the view in the same way that publishing the doc is.

I'm going to merge with the removal for now, but I think we should keep it in mind in case it creates confusion down the line.