Motivation
The workspace store needs to support a local-first editing workflow where users can make changes to documents, save them locally, and later sync those changes back to a remote registry. Currently, when a document is saved, the system overwrites the original document reference, losing track of what the remote version looked like. This makes it impossible to properly sync changes back to the remote registry or to detect conflicts between local and remote versions. A proper document versioning system needs to maintain three distinct states: the original remote version, the last locally saved version, and the current in-memory working version.
Current Behavior
The workspace store maintains only two document states: the original document (before reactive wrapping) and the current reactive workspace document. When saveDocument() is called, changes are persisted directly back to the original document, overwriting the last known remote version. This means there's no way to distinguish between what came from the remote registry and what has been saved locally.
Reproduction Steps:
- Load a document into the workspace store from a remote source
- Make changes to the document in the reactive workspace
- Call
saveDocument() to persist the changes
- Attempt to access the original remote version of the document
- Observe: The original document has been overwritten with the saved changes, and the remote version is lost
Expected Behavior
The workspace store should maintain three distinct document states:
- Original documents: The pristine version as loaded from the remote registry (never modified)
- Intermediate documents: The last locally saved version (updated when
saveDocument() is called)
- Workspace documents: The current in-memory reactive version (may have unsaved changes)
When saveDocument() is called, it should update the intermediate document while preserving the original. When exportDocument() is called, it should export the intermediate (locally saved) version. When syncing with a remote registry, the system should be able to compare the intermediate version against the original to determine what needs to be pushed.
Acceptance Criteria:
Steps To Test
- Load a document into the workspace store with known content
- Verify the original document is stored and matches the input
- Make changes to the reactive workspace document
- Call
saveDocument() and verify the intermediate document is updated
- Verify the original document remains unchanged and still matches the initial input
- Call
exportDocument() and verify it returns the intermediate (saved) version, not the original
- Make additional unsaved changes to the workspace document
- Call
revertDocument() and verify it reverts to the intermediate version, not the original
- Verify all existing tests still pass with the new three-tier state model
Submission
Download https://cap.so/ to record your screen (use Studio mode). Export as an mp4, and drag and drop into an issue comment below.
Guide to submitting pull requests: https://hackmd.io/@timothy1ee/Hky8kV3hlx
Motivation
The workspace store needs to support a local-first editing workflow where users can make changes to documents, save them locally, and later sync those changes back to a remote registry. Currently, when a document is saved, the system overwrites the original document reference, losing track of what the remote version looked like. This makes it impossible to properly sync changes back to the remote registry or to detect conflicts between local and remote versions. A proper document versioning system needs to maintain three distinct states: the original remote version, the last locally saved version, and the current in-memory working version.
Current Behavior
The workspace store maintains only two document states: the original document (before reactive wrapping) and the current reactive workspace document. When
saveDocument()is called, changes are persisted directly back to the original document, overwriting the last known remote version. This means there's no way to distinguish between what came from the remote registry and what has been saved locally.Reproduction Steps:
saveDocument()to persist the changesExpected Behavior
The workspace store should maintain three distinct document states:
saveDocument()is called)When
saveDocument()is called, it should update the intermediate document while preserving the original. WhenexportDocument()is called, it should export the intermediate (locally saved) version. When syncing with a remote registry, the system should be able to compare the intermediate version against the original to determine what needs to be pushed.Acceptance Criteria:
saveDocument()method updates the intermediate document without modifying the originalexportDocument()method exports from the intermediate document, not the originalrevertDocument()method reverts to the intermediate document (last saved state), not the original remote versionSteps To Test
saveDocument()and verify the intermediate document is updatedexportDocument()and verify it returns the intermediate (saved) version, not the originalrevertDocument()and verify it reverts to the intermediate version, not the originalSubmission
Download https://cap.so/ to record your screen (use Studio mode). Export as an mp4, and drag and drop into an issue comment below.
Guide to submitting pull requests: https://hackmd.io/@timothy1ee/Hky8kV3hlx