feat(core): adds events based history #7922
Merged
Conversation
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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
pedrobonamin
commented
Nov 29, 2024
| @@ -262,6 +262,7 @@ | |||
| "tar-fs": "^2.1.1", | |||
| "tar-stream": "^3.1.7", | |||
| "use-device-pixel-ratio": "^1.1.0", | |||
| "use-effect-event": "^1.0.2", | |||
There was a problem hiding this comment.
This is already part of other packages installed with sanity, like @sanity/ui , portable-text etc.
➜ sanity git:(corel-history) ✗ pnpm why use-effect-event
Legend: production dependency, optional only, dev only
[email protected] /Users/pedrobonamin/code/sanity
devDependencies:
@sanity/tsdoc 1.0.134
└─┬ @sanity/ui 2.10.0-corel.0
└── use-effect-event 1.0.2
@sanity/ui 2.10.0-corel.0
└── use-effect-event 1.0.2
sanity link:packages/sanity
├─┬ @portabletext/editor 1.11.3
│ └── use-effect-event 1.0.2
├─┬ @sanity/insert-menu 1.0.11-release.4
│ └─┬ @sanity/ui 2.10.0-corel.0
│ └── use-effect-event 1.0.2
├─┬ @sanity/presentation 1.17.8-release.4
│ ├─┬ @sanity/ui 2.10.0-corel.0
│ │ └── use-effect-event 1.0.2
│ └── use-effect-event 1.0.2
├─┬ @sanity/ui 2.10.0-corel.0
│ └── use-effect-event 1.0.2
├─┬ react-rx 4.1.7
│ └── use-effect-event 1.0.2
└── use-effect-event 1.0.2
|
No changes to documentation |
|
Component Testing Report Updated Dec 9, 2024 3:56 PM (UTC) ✅ All Tests Passed -- expand for details
|
⚡️ Editor Performance ReportUpdated Mon, 09 Dec 2024 15:58:02 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
pedrobonamin
force-pushed
the
corel-history
branch
from
b2d074e to
f864a15
Compare
pedrobonamin
commented
Nov 30, 2024
pedrobonamin
force-pushed
the
corel-history
branch
from
f864a15 to
ccd45ca
Compare
pedrobonamin
commented
Dec 2, 2024
| const documentTransactionsCache: Record<string, TransactionLogEventWithEffects[]> = | ||
| Object.create(null) | ||
|
|
||
| // Transactions could be cached, given they are not gonna change EVER. |
There was a problem hiding this comment.
I added a ticket to do this as a follow up
There was a problem hiding this comment.
probably a good idea to use an LRU, but you probably also already thought of that :)
There was a problem hiding this comment.
Yes, what makes it a bit challenging and why I created another ticket to do this change is that we could reuse transactions that we have already fetched.
Given transactions are not changing and we know the order.
For example:
-
User inspect the diff from
rev1torev10, we load all the transactions between this two revisions. -
User inspect the diff from
rev4torev5, we are loading again the transactions between this two, but we could reuse the ones loaded in the first diff, given they are contained by this. -
User inspects
rev8torev15, we are loading from rev8, we could avoid this and load only from rev10 because we already have from 8 to 10 loaded from the action 1
pedrobonamin
force-pushed
the
corel-history
branch
from
ebac782 to
47f3bc0
Compare
pedrobonamin
force-pushed
the
corel-history
branch
from
1ccdfa5 to
a920056
Compare
bjoerge
approved these changes
Dec 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Introduces the document group events and adds a feature flag to decide wether to use the new events or the old timeline.
It also refactors the
DocumentPaneProviderto receive the store by props, and support switching betweeneventsandtimelineEvents.API.studio.changes.mov
How events connect with each other and through variants?
From a
publisheddocument you can visit drafts and versions, because a draft or a version when it's published it impacts thepublisheddocument.But drafts and versions are not related between them.
Document group Events
Events API
The Events API introduces a new mechanism for accessing
DocumentGroupEvententries derived from the translog. These events are accessible through the endpoint:This events are accessible through:
This API is designed to be lightweight, providing only the essential data required to render the UI. Additionally, it offers insights into the document variants impacted by each event.
Pre read
With the introduction of releases, users now select the
DocumentVariantType(draft | published | version) they wish to work with in the form. This represents a significant shift from the previous behavior, where users interacted only with two types of documentspublishedor `draft —without the ability to focus on one or the other independently.How
useEventsStoreworks:When a user visits a document, the
useEventsStoreretrieves events relevant to the selected document variant (draft,version, orpublished). It also sets up a listener usinggetRemoteTransactionsto monitor real-time transactions for the document.When a new transaction is received, the system determines whether to reload the events or append the transaction to the existing event list. This decision depends on the transaction type and the specific document variant.
The retrieved events are displayed in the History Inspector. To render a diff, the system uses the
getChangesListfunction, which fetches the transactions between two selected document revisions (sinceandrevision). This process involves:How it worked before:
Previously, we used the
Timelineclass, which always fetched transactions from the translog. It also set up listeners for incoming transactions, using both the draft and published IDs. The system then mapped these transactions into human-readable events like edit, publish, or live edit.Why this is changing
The previous approach was tailored to a simpler model with only two variants (
draftandpublished). It displayed the changes for both document types in a unified view. However, this model does not align with the new paradigm of multiple document variants.Now, each document variant has its own dedicated view, showing only the changes relevant to that specific variant.
Key updates:
draft.publisheddocument, specifying whether the change originated from publishing adraftorversion, or from alive edit.Types of Events and Document Lifecycle
Each event represents a significant state change in the lifecycle of a document, its versions, and its published state. These events help to track the creation, modification, scheduling, publication and deletion of documents.
Version Lifecycle
A version is a short-lived document that undergoes creation, editing, and publication or deletion. Once published, the same ID will not be reused for a new version. The events affecting a version include:
CreateDocumentVersionEvent: Triggered when a version is created.DeleteDocumentVersionEvent: Occurs if a version is deleted, though this is uncommon.PublishDocumentVersionEvent: Marks the publication of the version as part of a release.ScheduleDocumentVersionEvent(not implemented yet): Indicates that the version's release has been scheduled.UnscheduleDocumentVersionEvent(not implemented yet): Indicates that the version's release has been unscheduled.EditDocumentVersionEvent: Triggered when the version is edited.Draft Document
Draft documents are long-lived documents, which could be published and recreated multiple times. Events specific to drafts include:
CreateDocumentVersionEvent: Occurs when a new draft is created, after publishing or deleting a document.DeleteDocumentVersionEvent: Triggered when a draft is discarded.PublishDocumentVersionEvent: Indicates that the draft has been published, either through manual action or a scheduled release.ScheduleDocumentVersionEvent(not implemented yet): Indicates that the draft has been scheduled for publication.UnscheduleDocumentVersionEvent(not implemented yet): Indicates that a scheduled draft has been unscheduled.EditDocumentVersionEvent: Triggered when edits are made to the draft.Published Document
Published documents represent the live, publicly available version of a document. Events specific to published documents include:
UnpublishDocumentEvent: Triggered when the document is unpublished. This deletes the live document and creates a draft with the published document's data if no draft exists.CreateLiveDocumentEvent: Occurs when a live document is created outside the typical publish action, such as through live edits or API-created documents.UpdateLiveDocumentEvent: Triggered when a live document is edited directly, typically in live edit workflows or through API actions bypassing the publish process.PublishDocumentVersionEvent: Captures when adraftorversiondocument is published. This event includes details such as the ID and revision of the document that initiated the modification.Edit Event
The Edit Event is a special case. It is not returned directly by the API but is generated within the Studio by:
What to review
DocumentPaneProviderto a new component that decides wether to use the events store or the timeline store.DocumentPaneProviderInnerand receive the necessary store data as props in the HistoryStoreProps paramevents store.Testing
Will be added in a follow up PR, ticket
corel-235Notes for release