Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implementation for events in history #7569

Draft
wants to merge 9 commits into
base: next
Choose a base branch
from

Conversation

pedrobonamin
Copy link
Contributor

@pedrobonamin pedrobonamin commented Oct 1, 2024

Warning

Not to be merged yet, this requires approval from the CLDX team on how the events are generated.

Description

Publish is Draft is created Draft is deleted Draft is unedited Draft is upsert
unedited document.createVersion (draft) document.deleteVersion (draft) no-effect (none) document.editVersion (draft)
deleted document.unpublish (published) document.deleteGroup (published) maybeUnpublishMaybeDelete (published) document.unpublish (published)
upsert document.updateLive (published) document.publishVersion (published) document.updateLive (published) document.updateLive (published)
created document.createVersion (published) document.publishVersion (published) document.createLive (published) document.createVersion (published)

What to review

This Pr updates how the chunks are defined, using event based actions. This events in a close future will include also the versions.
Eventually, we will have an events API to get them from, so all the mapping won't need to happen in the client.
To create the necessary events we are using the transactions.

Are this changes correct? Are there any missing pieces?

Testing

Open any document and see the history, it should work as always, no visual or functional changes introduced, this is preparing to use the events api.
Tests have been added for the get events functions.

Also, a story has been created showing how the transactions -> events -> chunks logic work.
Screenshot 2024-10-14 at 10 02 24

Notes for release

feat: introduces event based history.

Copy link

vercel bot commented Oct 1, 2024

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 23, 2024 10:01am
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 23, 2024 10:01am
test-compiled-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 23, 2024 10:01am
test-next-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 23, 2024 10:01am
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 23, 2024 10:01am
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Visit Preview Oct 23, 2024 10:01am

Copy link
Contributor

github-actions bot commented Oct 1, 2024

No changes to documentation

Copy link
Contributor

github-actions bot commented Oct 1, 2024

Component Testing Report Updated Oct 23, 2024 9:53 AM (UTC)

✅ All Tests Passed -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 45s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 8s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ✅ Passed (Inspect) 31s 6 0 0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 38s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 17s 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) 45s 15 0 0
formBuilder/inputs/PortableText/Input.spec.tsx ✅ Passed (Inspect) 1m 44s 21 0 0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx ✅ Passed (Inspect) 1m 17s 18 0 0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx ✅ Passed (Inspect) 9s 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) 37s 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

Comment on lines +194 to +195
export interface EditDocumentVersionEvent extends BaseEvent {
type: 'document.editVersion'

releaseId?: string
versionId: string
versionRevisionId: string
mergedEvents?: EditDocumentVersionEvent[]
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a new event not mentioned in the initial document.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't be part of the events api

Copy link
Contributor

github-actions bot commented Oct 2, 2024

⚡️ Editor Performance Report

Updated Wed, 23 Oct 2024 09:55:59 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 15.7 efps (64ms) 16.7 efps (60ms) -4ms (-5.5%)
article (body) 56.2 efps (18ms) 56.5 efps (18ms) -0ms (-0.6%)
article (string inside object) 17.2 efps (58ms) 16.7 efps (60ms) +2ms (+3.4%)
article (string inside array) 13.7 efps (73ms) 13.3 efps (75ms) +2ms (+2.7%)
recipe (name) 29.4 efps (34ms) 29.4 efps (34ms) +0ms (-/-%)
recipe (description) 33.3 efps (30ms) 33.3 efps (30ms) +0ms (-/-%)
recipe (instructions) 99.9+ efps (6ms) 99.9+ efps (6ms) -0ms (-/-%)
synthetic (title) 15.0 efps (67ms) 14.9 efps (67ms) +1ms (+0.8%)
synthetic (string inside object) 15.6 efps (64ms) 15.6 efps (64ms) +0ms (-/-%)

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) 64ms 67ms 73ms 293ms 536ms 14.1s
article (body) 18ms 20ms 23ms 79ms 281ms 5.8s
article (string inside object) 58ms 62ms 72ms 333ms 507ms 9.0s
article (string inside array) 73ms 79ms 87ms 340ms 1177ms 10.3s
recipe (name) 34ms 36ms 40ms 60ms 14ms 8.8s
recipe (description) 30ms 31ms 37ms 144ms 0ms 6.2s
recipe (instructions) 6ms 9ms 10ms 33ms 0ms 3.4s
synthetic (title) 67ms 71ms 77ms 348ms 1465ms 15.8s
synthetic (string inside object) 64ms 68ms 82ms 606ms 1613ms 11.1s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 60ms 64ms 81ms 220ms 421ms 13.3s
article (body) 18ms 20ms 27ms 72ms 339ms 5.9s
article (string inside object) 60ms 65ms 84ms 286ms 456ms 9.2s
article (string inside array) 75ms 79ms 90ms 230ms 1353ms 10.4s
recipe (name) 34ms 38ms 49ms 86ms 28ms 9.4s
recipe (description) 30ms 33ms 40ms 69ms 0ms 6.3s
recipe (instructions) 6ms 8ms 9ms 10ms 0ms 3.3s
synthetic (title) 67ms 70ms 81ms 385ms 1490ms 15.5s
synthetic (string inside object) 64ms 68ms 81ms 341ms 1311ms 10.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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants