fix(structure): improve and clean up form ready state

[bjoerge]

Description

Currently, we defer marking the document as "ready" until we have loaded the timeline. This was originally done to avoid the confusion from first loading the current revision of the document and then replacing it when the selected revision is loaded from the timeline.

In a certain cases, loading the timeline can be quite slow, so the changes in this PR only waits if there's actually a selected revision (represented by params.rev being set)

What to review

Does it make sense? Any case I'm not thinking about?

Testing

Unfortunately non-trivial to add automated tests for, but I've verfied that the current behavior is preserved if params.rev is set.

Notes for release

• fixed an issue that could in certain rare cases make loading of a document to take a long time.

[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	Oct 7, 2024 1:43pm
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 1:43pm
test-compiled-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 1:43pm
test-next-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 1:43pm
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 7, 2024 1:43pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)			Oct 7, 2024 1:43pm

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Oct 7, 2024 1:49 PM (UTC)

✅ All Tests Passed -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	49s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	9s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	31s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	37s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	10s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	3m 0s	0	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	44s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 43s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 15s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	8s	3	9	0
formBuilder/inputs/PortableText/RangeDecoration.spec.tsx	✅ Passed (Inspect)	26s	9	0	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	18s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	36s	12	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 Mon, 07 Oct 2024 14:02:04 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	17.4 efps (58ms)	17.2 efps (58ms)	+1ms (+0.9%)	✅
article (body)	56.5 efps (18ms)	59.7 efps (17ms)	-1ms (-5.4%)	✅
article (string inside object)	19.2 efps (52ms)	18.2 efps (55ms)	+3ms (+5.8%)	✅
article (string inside array)	14.9 efps (67ms)	14.9 efps (67ms)	+0ms (-/-%)	✅
recipe (name)	31.3 efps (32ms)	31.3 efps (32ms)	+0ms (-/-%)	✅
recipe (description)	33.9 efps (30ms)	35.7 efps (28ms)	-2ms (-5.1%)	✅
recipe (instructions)	99.9+ efps (7ms)	99.9+ efps (6ms)	-1ms (-/-%)	✅
synthetic (title)	15.0 efps (67ms)	15.2 efps (66ms)	-1ms (-0.8%)	✅
synthetic (string inside object)	15.7 efps (64ms)	15.2 efps (66ms)	+3ms (+3.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)	58ms	65ms	72ms	282ms	1312ms	14.3s
article (body)	18ms	22ms	28ms	115ms	252ms	5.9s
article (string inside object)	52ms	55ms	64ms	157ms	846ms	8.8s
article (string inside array)	67ms	71ms	85ms	177ms	1761ms	10.1s
recipe (name)	32ms	37ms	41ms	73ms	22ms	9.0s
recipe (description)	30ms	33ms	38ms	69ms	76ms	6.5s
recipe (instructions)	7ms	8ms	9ms	10ms	0ms	3.3s
synthetic (title)	67ms	71ms	82ms	339ms	2145ms	16.8s
synthetic (string inside object)	64ms	67ms	77ms	271ms	1805ms	10.2s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	58ms	67ms	71ms	256ms	1315ms	13.7s
article (body)	17ms	18ms	20ms	92ms	264ms	6.1s
article (string inside object)	55ms	59ms	74ms	113ms	1082ms	9.4s
article (string inside array)	67ms	70ms	76ms	174ms	1764ms	9.9s
recipe (name)	32ms	33ms	38ms	76ms	60ms	9.3s
recipe (description)	28ms	29ms	32ms	72ms	26ms	6.1s
recipe (instructions)	6ms	8ms	9ms	10ms	0ms	3.3s
synthetic (title)	66ms	71ms	83ms	407ms	2209ms	15.8s
synthetic (string inside object)	66ms	69ms	77ms	455ms	2334ms	10.5s

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

[robinpyon]

Great catch – this makes sense to me, and I can't think of any problems this would cause.