fix: showing add doc toast once document is received in the subscription

[jordanl17]

Description

The scenario this PR resolves is when 'Add document' is used to create a version document from within a release. When a document is selected, the version document is created, and then the success toast is shown whilst the search dialog is closed.

However, the subscription used in useBundleDocuments must receive the new event and update the store state before this new document will appear in the list on release detail. This creates a weird experience where we say success, but there's a delay before everything looks as would be expected.

This PR changes this flow:

• Instead of closing the search dialog and showing toast once createVersion resolves, closes the toast immediately after selecting a document
• A pending row (skeleton loading) is added to the document list table
• Once the document is retrieved in the bundle documents store, the pending row is replaced with the actual document
• The toast then shows, once the row is fully visible on the table

NOTE: this is throttled, it is never this noticable

What to review

Testing

Existing tests validate no regressions. Should add some tests for showing the pending state - but need to put into a fast follow

Notes for release

N/A

[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 18, 2025 10:23am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 18, 2025 10:23am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 18, 2025 10:23am

2 Skipped Deployments

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

[github-actions]

No changes to documentation

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.76%	54427 / 127271
🔵	Statements	42.76%	54427 / 127271
🔵	Functions	48.12%	2789 / 5795
🔵	Branches	79.35%	10580 / 13333

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/releases/i18n/resources.ts	100%	100%	100%	100%
packages/sanity/src/core/releases/tool/detail/AddDocumentSearch.tsx	100%	100%	100%	100%
packages/sanity/src/core/releases/tool/detail/ReleaseSummary.tsx	67.08%	75%	66.66%	67.08%	92, 102-147, 156-166, 172-173
packages/sanity/src/core/releases/tool/detail/useBundleDocuments.ts	9.43%	100%	0%	9.43%	56-162, 165-230, 233-272, 278-296
packages/sanity/src/core/releases/tool/detail/documentTable/DocumentTableColumnDefs.tsx	85.29%	74.19%	100%	85.29%	72-77, 143, 201-221

Generated in workflow #30614 for commit 8a23539 by the Vitest Coverage Report Action

[github-actions]

⚡️ Editor Performance Report

Updated Tue, 18 Feb 2025 10:28:16 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	28.6 efps (35ms)	27.8 efps (36ms)	+1ms (+2.9%)	✅
article (body)	72.5 efps (14ms)	77.5 efps (13ms)	-1ms (-/-%)	✅
article (string inside object)	27.8 efps (36ms)	28.6 efps (35ms)	-1ms (-2.8%)	✅
article (string inside array)	25.6 efps (39ms)	25.6 efps (39ms)	+0ms (-/-%)	✅
recipe (name)	50.0 efps (20ms)	52.6 efps (19ms)	-1ms (-5.0%)	✅
recipe (description)	55.6 efps (18ms)	58.8 efps (17ms)	-1ms (-5.6%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	+0ms (-/-%)	✅
synthetic (title)	20.0 efps (50ms)	20.0 efps (50ms)	+0ms (-/-%)	✅
synthetic (string inside object)	20.0 efps (50ms)	21.1 efps (48ms)	-3ms (-5.0%)	✅

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)	35ms	38ms	43ms	451ms	234ms	10.9s
article (body)	14ms	16ms	20ms	98ms	44ms	5.0s
article (string inside object)	36ms	39ms	42ms	185ms	145ms	7.1s
article (string inside array)	39ms	42ms	45ms	143ms	131ms	6.5s
recipe (name)	20ms	21ms	25ms	50ms	11ms	6.9s
recipe (description)	18ms	19ms	21ms	31ms	0ms	4.5s
recipe (instructions)	5ms	6ms	7ms	17ms	0ms	3.1s
synthetic (title)	50ms	54ms	66ms	340ms	1084ms	13.1s
synthetic (string inside object)	50ms	54ms	62ms	423ms	910ms	8.1s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	36ms	38ms	52ms	435ms	646ms	10.5s
article (body)	13ms	15ms	18ms	141ms	212ms	5.0s
article (string inside object)	35ms	36ms	38ms	90ms	279ms	6.4s
article (string inside array)	39ms	41ms	43ms	138ms	124ms	6.4s
recipe (name)	19ms	21ms	24ms	56ms	0ms	7.0s
recipe (description)	17ms	18ms	19ms	40ms	0ms	4.4s
recipe (instructions)	5ms	6ms	7ms	8ms	0ms	3.0s
synthetic (title)	50ms	53ms	62ms	363ms	908ms	13.7s
synthetic (string inside object)	48ms	51ms	55ms	404ms	810ms	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 18, 2025 10:30 AM (UTC)

❌ Failed Tests (3) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 20s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	16s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	2m 3s	4	0	2
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	1m 1s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	30s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	17s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 16s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 56s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	❌ Failed (Inspect)	3m 0s	20	0	1
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	15s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	2m 2s	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