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.

Sign up for GitHub

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

Jump to bottom

Update INTERNALS to reflect undo/redo removal #473

Merged
merged 1 commit into from
Feb 23, 2022
Merged

Update INTERNALS to reflect undo/redo removal #473

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 5 additions & 28 deletions INTERNALS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,7 +160,7 @@ Every change is a JSON object with five properties:
be declared either.
* `message`: An optional human-readable "commit message" that describes the
change in a meaningful way. It is not interpreted by Automerge, only
stored for introspection, debugging, undo, and similar purposes.
stored for introspection, debugging, and similar purposes.
* `ops`: An array of operations that are grouped into this change.

Each operation acts on an object, which is identified by a UUID. There are four
Expand Down Expand Up @@ -359,7 +359,7 @@ frontend to update its state.

Messages from the frontend to the backend are called **change requests** (as
they always represent a change made by the local user, via
`Automerge.{change,undo,redo}`). Messages from the backend to the frontend are
`Automerge.change`). Messages from the backend to the frontend are
called **patches** (because they describe a modification that needs to be made
to the frontend state).

Expand All @@ -370,18 +370,11 @@ protocol has been implemented on the `performance` branch).**
### Change requests

Change requests (sent from frontend to backend) are generated by
`Frontend.from()`, `Frontend.change()`, `Frontend.emptyChange()`,
`Frontend.undo()`, or `Frontend.redo()`. Change requests look very similar to
`Frontend.from()`, `Frontend.change()`, or `Frontend.emptyChange()`. Change requests look very similar to
changes: they have properties `actor`, `seq`, `deps`, `message`, and `ops` as
documented above. The difference is that there is one additional property
`requestType`, whose value must be either `'change'`, `'undo'`, or `'redo'`.

In the case of `'change'`, the other properties describe the change by the local
user that should be applied to the backend state. In the case of a `requestType`
of `'undo'` or `'redo'`, the change request does not contain any `ops` property
(but the other properties `actor`, `seq`, `deps`, and `message` are still
present). In this case, the list of ops is filled in by the backend (since the
backend maintains the undo/redo history).
`requestType`, whose value must be either `'change'` (`'undo'` and `'redo'` are no longer supported as of 1.x). In the case of `'change'`, the other properties describe the change by the local
user that should be applied to the backend state.

A change request from the frontend is applied to the backend using
`Backend.applyLocalChange()`, and the backend responds with a patch describing
Expand All @@ -405,10 +398,6 @@ A patch is a JSON object with the following properties:
* `actor` and `seq`: If the patch is a response to a change request, these
properties are set to match the `actor` and `seq` in the change request.
Not set on patches generated by `applyChanges()` or `getPatch()`.
* `canUndo` and `canRedo`: Booleans that indicate whether, after applying this
patch, `undo()` and `redo()` should be enabled, respectively. Undo is enabled
if there is at least one local change that has not been undone, and redo is
enabled if there has been at least one undo since the last change.
* `clock` and `deps`: Objects in which the keys are actor IDs, and the values
are the highest sequence number that the backend has processed from that
actor. The difference between `clock` and `deps` is that `clock` contains all
Expand Down Expand Up @@ -530,15 +519,3 @@ that would otherwise have to be computed by iterating over the entire history.
* `deps`: A map of the same form as `clock`, but excluding transitive
dependencies — that is, containing only actorID/seqNo pairs that cannot be
reached through the indirect dependencies of another of the dependencies.
* `undoPos`: An integer, representing the current place in the undo stack. At
any point in time, the first `undoPos` elements of `undoStack` (i.e. indexes
0 to undoPos–1) are undoable, and any indexes >= undoPos in `undoStack` have
already been undone.
* `undoStack`: A list of list of operations. One element in the outer list is
pushed when a local change is performed through `applyLocalChange()`, and it
is set to the list of operations that need to be performed in order to undo
that change. Those operations are chosen such that they restore the prior
value(s) of any properties that are updated in the course of the local change.
* `redoStack`: A list of list of operations, similar to `undoStack`. Here, an
element is pushed to the outer list when an undo is performed, and it
contains the operations that we need to perform in order to undo the undo.