You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
update sanity assist to use this and deprecate the forcedVersion in DocumentPaneProvider
refactor the inspect legacy dialog into the new inspectors logic suggestion
Why we need this?
Currently if you want to render a form using the patch mechanism, have presence, validation and compare values you would need to reuse the <DocumentPaneProvider> which bring with it some unnecessary things like history , actions, perspective etc, or you needed to write it in your own like in useTasksFormBuilder. This is not ideal and it takes a lot of effort from the developer.
By implementing this hook you can now do use this minimal implementation to get all the necessary form values and handlers. (see example in code)
const form = useCreateForm({documentId, documentType, initialValue})
This should also be useful for:
Sanity assist replacing the <DocumentPaneProvider> from here
Please help me review in detail this PR as it touches a critical surface which handles a lot of logic, my recommendation is going commit per commit to see how the changes build on top of each other.
Testing
Manual testing has been done to the PR, focusing on history, versions and tasks which are not covered by e2e tests.
Existing tests should cover the rest of the functionality
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
86ms
511ms
1086ms
11.3s
article (body)
14ms
15ms
21ms
146ms
189ms
5.0s
article (string inside object)
37ms
38ms
42ms
79ms
110ms
6.8s
article (string inside array)
42ms
44ms
48ms
258ms
382ms
7.4s
recipe (name)
22ms
24ms
25ms
43ms
0ms
7.6s
recipe (description)
20ms
21ms
24ms
37ms
0ms
4.9s
recipe (instructions)
5ms
6ms
7ms
13ms
0ms
3.0s
synthetic (title)
55ms
58ms
63ms
287ms
1134ms
26.5s
synthetic (string inside object)
51ms
55ms
82ms
351ms
1296ms
9.0s
🧪 Experiment result
The performance result of this branch
Benchmark
latency
p75
p90
p99
blocking time
test duration
article (title)
40ms
45ms
57ms
195ms
211ms
10.5s
article (body)
13ms
14ms
18ms
80ms
64ms
4.6s
article (string inside object)
38ms
41ms
48ms
258ms
312ms
7.3s
article (string inside array)
43ms
46ms
51ms
101ms
318ms
7.5s
recipe (name)
19ms
20ms
24ms
38ms
0ms
7.3s
recipe (description)
17ms
17ms
18ms
30ms
0ms
4.5s
recipe (instructions)
6ms
8ms
8ms
10ms
0ms
3.3s
synthetic (title)
50ms
56ms
69ms
360ms
1221ms
13.0s
synthetic (string inside object)
52ms
55ms
67ms
323ms
692ms
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.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR implements a new hook
useCreateForm
which handles the necessary logic to build a form and pass the values to the<FormProvider>
It also simplifies the logic inside the
<DocumentPaneProvider>
to make it easier to digest:useDocumentPaneInitialValue
useDocumentPaneInspector
Further steps:
forcedVersion
inDocumentPaneProvider
inspect
legacy dialog into the new inspectors logic suggestionWhy we need this?
Currently if you want to render a form using the patch mechanism, have presence, validation and compare values you would need to reuse the
<DocumentPaneProvider>
which bring with it some unnecessary things likehistory
,actions
,perspective
etc, or you needed to write it in your own like in useTasksFormBuilder. This is not ideal and it takes a lot of effort from the developer.By implementing this hook you can now do use this minimal implementation to get all the necessary form values and handlers. (see example in code)
This should also be useful for:
<DocumentPaneProvider>
from hereWhat to review
Please help me review in detail this PR as it touches a critical surface which handles a lot of logic, my recommendation is going commit per commit to see how the changes build on top of each other.
Testing
Manual testing has been done to the PR, focusing on history, versions and tasks which are not covered by e2e tests.
Existing tests should cover the rest of the functionality
Notes for release
adds
useCreateForm
hook