feat: content releases

[bjoerge]

Description

This PR marks the public beta of the Content Releases feature. The content releases feature itself will be opt-in (for now), but these changes also introduces a few key improvements to the Studio UI, most notably the ability to switch between the published document and the current draft, and the ability to browse the Studio by only seeing what's currently published.

The Studio now supports a perspective search param, which is "sticky", meaning that it is preserved when navigating around in the studio. This param can take a comma-separated list of values (referred to as a "perspecive stack", which will then be forwarded to the perspective param used by list queries made by the Studio)

Terminology

With these changes we are introducing three new terms into the codebase, I'll cover them in brief here (there's more details to be found in internal documentation for the curious minded):

• Version - This is comparable to a draft document but with a different prefix: instead of drafts.<publishedId> it will have versions.<releaseId>.<publishedId> . The versions. prefix is fixed, and no documents can have that as a prefix without following the versions.<string>.<id> structure.
• Release – A release is represented by a system document that has an ID on the form _.release.<releaseId>. The <releaseId>-part here is what connects it with version documents. The <releaseId> part conventionally starts with r, and is followed by 8 random characters, e.g. rNe6H9RGZ.
• Bundle - This is an internal, technical name used to connect documents in the release together. You can think of the releaseId as a type of bundle, but there could also be other types of bundles in the future.

There's no change to the semantics around draft documents, other than you can now think of them as version documents with special sematics applied to them.

What to review

This is a rather chonky one, when reviewing feel free to skp fast through things like tests and fixtures and focus on the more substantial stuff. Things in particular to watch out for are:

• Changes to core APIs that could potentially be breaking
• Changes to core that could affect data integrity in any way
• Changes to datastores etc. that could pose performance issues

Note: we'll be using vX for various API calls if the feature is enabled, otherwise we'll stick with stable API versions. While it's not ideal to ship with vX, we have considered it to be an ok tradeoff in this case, given that the feature is opt-in and considered beta. Edit: Seems like this is not the case right now, we will be addressing this before merging, but adding a todo here:

• Use vX only when opting-in to Content Releases

Testing

Most new code includes tests, but our coverage of existing code paths is still aspirational at best, so any manual testing is greatly appreciated.

Notes for release

tbd

[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 4, 2025 3:34pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 4, 2025 3:34pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 4, 2025 3:34pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Feb 4, 2025 3:34pm
test-next-studio	⬜️ Ignored (Inspect)			Feb 4, 2025 3:34pm

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Feb 4, 2025 3:40 PM (UTC)

❌ Failed Tests (1) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 7s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	13s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	1m 20s	5	0	1
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)	14s	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 32s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	2m 3s	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 46s	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

[github-actions]

⚡️ Editor Performance Report

Updated Tue, 04 Feb 2025 15:42:11 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	25.6 efps (39ms)	23.3 efps (43ms)	+4ms (+10.3%)	✅
article (body)	69.9 efps (14ms)	72.5 efps (14ms)	-0ms (-/-%)	✅
article (string inside object)	26.3 efps (38ms)	25.0 efps (40ms)	+2ms (+5.3%)	✅
article (string inside array)	24.4 efps (41ms)	22.2 efps (45ms)	+4ms (+9.8%)	✅
recipe (name)	50.0 efps (20ms)	48.8 efps (21ms)	+1ms (+2.5%)	✅
recipe (description)	58.8 efps (17ms)	55.6 efps (18ms)	+1ms (+5.9%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	-0ms (-/-%)	✅
synthetic (title)	19.4 efps (52ms)	19.6 efps (51ms)	-1ms (-1.0%)	✅
synthetic (string inside object)	19.4 efps (52ms)	20.0 efps (50ms)	-2ms (-2.9%)	✅

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)	39ms	43ms	60ms	307ms	203ms	10.0s
article (body)	14ms	19ms	26ms	178ms	208ms	5.6s
article (string inside object)	38ms	41ms	48ms	156ms	302ms	6.9s
article (string inside array)	41ms	43ms	49ms	266ms	293ms	7.0s
recipe (name)	20ms	22ms	26ms	40ms	0ms	6.8s
recipe (description)	17ms	19ms	21ms	30ms	0ms	4.5s
recipe (instructions)	5ms	7ms	8ms	31ms	0ms	3.1s
synthetic (title)	52ms	54ms	60ms	268ms	980ms	13.2s
synthetic (string inside object)	52ms	58ms	68ms	446ms	1147ms	8.4s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	43ms	48ms	59ms	451ms	490ms	11.0s
article (body)	14ms	18ms	23ms	241ms	317ms	5.6s
article (string inside object)	40ms	42ms	46ms	252ms	296ms	6.9s
article (string inside array)	45ms	47ms	56ms	156ms	346ms	7.5s
recipe (name)	21ms	22ms	25ms	33ms	0ms	7.3s
recipe (description)	18ms	20ms	21ms	37ms	0ms	4.6s
recipe (instructions)	5ms	6ms	7ms	28ms	0ms	3.1s
synthetic (title)	51ms	54ms	69ms	166ms	462ms	12.0s
synthetic (string inside object)	50ms	57ms	74ms	632ms	1260ms	9.1s

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

[pedrobonamin]

Great team work !!! This is amazing @sanity-io/studio-app !