8151e6f586
Our undo-redo system before this diff is based on commands. A command is: - A function that produces some data required to perform and undo a change - A function that actually performs the change, based on the data - Another function that undoes the change, based on the data - Optionally, a function to _redo_ the change, although in practice we never use this Each command that gets run is added to the undo/redo stack unless it says it shouldn't be. This diff replaces this system of commands with a new one where all changes to the store are automatically recorded in the undo/redo stack. You can imagine the new history manager like a tape recorder - it automatically records everything that happens to the store in a special diff, unless you "pause" the recording and ask it not to. Undo and redo rewind/fast-forward the tape to certain marks. As the command concept is gone, the things that were commands are now just functions that manipulate the store. One other change here is that the store's after-phase callbacks (and the after-phase side-effects as a result) are now batched up and called at the end of certain key operations. For example, `applyDiff` would previously call all the `afterCreate` callbacks before making any removals from the diff. Now, it (and anything else that uses `store.atomic(fn)` will defer firing any after callbacks until the end of an operation. before callbacks are still called part-way through operations. ## Design options Automatic recording is a fairly large big semantic change, particularly to the standalone `store.put`/`store.remove` etc. commands. We could instead make not-recording the default, and make recording opt-in instead. However, I think auto-record-by-default is the right choice for a few reasons: 1. Switching to a recording-based vs command-based undo-redo model is fundamentally a big semantic change. In the past, `store.put` etc. were always ignored. Now, regardless of whether we choose record-by-default or ignore-by-default, the behaviour of `store.put` is _context_ dependant. 2. Switching to ignore-by-default means that either our commands don't record undo/redo history any more (unless wrapped in `editor.history.record`, a far larger semantic change) or they have to always-record/all accept a history options bag. If we choose always-record, we can't use commands within `history.ignore` as they'll start recording again. If we choose the history options bag, we have to accept those options in 10s of methods - basically the entire `Editor` api surface. Overall, given that some breaking semantic change here is unavoidable, I think that record-by-default hits the right balance of tradeoffs. I think it's a better API going forward, whilst also not being too disruptive as the APIs it affects are very "deep" ones that we don't typically encourage people to use. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `improvement` — Improving existing features - [x] `galaxy brain` — Architectural changes ### Release Note #### Breaking changes ##### 1. History Options Previously, some (not all!) commands accepted a history options object with `squashing`, `ephemeral`, and `preserveRedoStack` flags. Squashing enabled/disabled a memory optimisation (storing individual commands vs squashing them together). Ephemeral stopped a command from affecting the undo/redo stack at all. Preserve redo stack stopped commands from wiping the redo stack. These flags were never available consistently - some commands had them and others didn't. In this version, most of these flags have been removed. `squashing` is gone entirely (everything squashes & does so much faster than before). There were a couple of commands that had a special default - for example, `updateInstanceState` used to default to being `ephemeral`. Those maintain the defaults, but the options look a little different now - `{ephemeral: true}` is now `{history: 'ignore'}` and `{preserveRedoStack: true}` is now `{history: 'record-preserveRedoStack'}`. If you were previously using these options in places where they've now been removed, you can use wrap them with `editor.history.ignore(fn)` or `editor.history.batch(fn, {history: 'record-preserveRedoStack'})`. For example, ```ts editor.nudgeShapes(..., { ephemeral: true }) ``` can now be written as ```ts editor.history.ignore(() => { editor.nudgeShapes(...) }) ``` ##### 2. Automatic recording Previously, only commands (e.g. `editor.updateShapes` and things that use it) were added to the undo/redo stack. Everything else (e.g. `editor.store.put`) wasn't. Now, _everything_ that touches the store is recorded in the undo/redo stack (unless it's part of `mergeRemoteChanges`). You can use `editor.history.ignore(fn)` as above if you want to make other changes to the store that aren't recorded - this is short for `editor.history.batch(fn, {history: 'ignore'})` When upgrading to this version of tldraw, you shouldn't need to change anything unless you're using `store.put`, `store.remove`, or `store.applyDiff` outside of `store.mergeRemoteChanges`. If you are, you can preserve the functionality of those not being recorded by wrapping them either in `mergeRemoteChanges` (if they're multiplayer-related) or `history.ignore` as appropriate. ##### 3. Side effects Before this diff, any changes in side-effects weren't captured by the undo-redo stack. This was actually the motivation for this change in the first place! But it's a pretty big change, and if you're using side effects we recommend you double-check how they interact with undo/redo before/after this change. To get the old behaviour back, wrap your side effects in `editor.history.ignore`. ##### 4. Mark options Previously, `editor.mark(id)` accepted two additional boolean parameters: `onUndo` and `onRedo`. If these were set to false, then when undoing or redoing we'd skip over that mark and keep going until we found one with those values set to true. We've removed those options - if you're using them, let us know and we'll figure out an alternative! |
||
---|---|---|
.. | ||
src | ||
api-extractor.json | ||
api-report.md | ||
CHANGELOG.md | ||
LICENSE.md | ||
package.json | ||
README.md | ||
tsconfig.json |
@tldraw/tlstore
tlstore
is a library for creating and managing data.
In this library, a "record" is an object that is stored under a typed id.
tlstore
is used by tldraw to store its data.
It is designed to be used with tlstate
(@tldraw/tlstate).
Usage
First create types for your records.
interface Book extends BaseRecord<'book'> {
title: string
author: ID<Author>
numPages: number
}
interface Author extends BaseRecord<'author'> {
name: string
isPseudonym: boolean
}
Then create your RecordType
instances.
const Book = createRecordType<Book>('book')
const Author = createRecordType<Author>('author').withDefaultProperties(() => ({
isPseudonym: false,
}))
Then create your RecordStore
instance.
const store = new RecordStore<Book | Author>()
Then you can create records, add them to the store, update, and remove them.
const tolkeinId = Author.createCustomId('tolkein')
store.put([
Author.create({
id: jrrTolkeinId,
name: 'J.R.R Tolkein',
}),
])
store.update(tolkeinId, (author) => ({
...author,
name: 'DJJ Tolkz',
isPseudonym: true,
}))
store.remove(tolkeinId)
API
RecordStore
The RecordStore
class is the main class of the library.
const store = new RecordStore()
put(records: R[]): void
Add some records to the store. It's an error if they already exist.
const record = Author.create({
name: 'J.R.R Tolkein',
id: Author.createCustomId('tolkein'),
})
store.put([record])
update(id: ID<R>, updater: (record: R) => R): void
Update a record. To update multiple records at once, use the update
method of the TypedRecordStore
class.
const id = Author.createCustomId('tolkein')
store.update(id, (r) => ({ ...r, name: 'Jimmy Tolks' }))
remove(ids: ID<R>[]): void
Remove some records from the store via their ids.
const id = Author.createCustomId('tolkein')
store.remove([id])
get(id: ID<R>): R
Get the value of a store record by its id.
const id = Author.createCustomId('tolkein')
const result = store.get(id)
allRecords(): R[]
Get an array of all values in the store.
const results = store.allRecords()
clear(): void
Remove all records from the store.
store.clear()
has(id: ID<R>): boolean
Get whether the record store has an record stored under the given id.
const id = Author.createCustomId('tolkein')
const result = store.has(id)
serialize(filter?: (record: R) => boolean): RecordStoreSnapshot<R>
Opposite of deserialize
. Creates a JSON payload from the record store.
const serialized = store.serialize()
const serialized = store.serialize((record) => record.name === 'J.R.R Tolkein')
deserialize(snapshot: RecordStoreSnapshot<R>): void
Opposite of serialize
. Replace the store's current records with records as defined by a simple JSON structure into the stores.
const serialized = { ... }
store.deserialize(serialized)
listen(listener: ((entry: HistoryEntry) => void): () => void
Add a new listener to the store The store will call the function each time the history changes. Returns a function to remove the listener.
store.listen((entry) => doSomethingWith(entry))
mergeRemoteChanges(fn: () => void): void
Merge changes from a remote source without triggering listeners.
store.mergeRemoteChanges(() => {
store.put(recordsFromRemoteSource)
})
createDerivationCache(name: string, derive: ((record: R) => R | undefined)): DerivationCache<R>
Create a new derivation cache.
const derivationCache = createDerivationCache('popular_authors', (record) => {
return record.popularity > 62 ? record : undefined
})
RecordType
The RecordType
class is used to define the structure of a record.
const recordType = new RecordType('author', () => ({ living: true }))
RecordType
instances are most often created with createRecordType
.
create(properties: Pick<R, RequiredProperties> & Omit<Partial<R>, RequiredProperties>): R
Create a new record of this type.
const record = recordType.create({ name: 'J.R.R Tolkein' })
clone(record: R): R
Clone a record of this type.
const record = recordType.create({ name: 'J.R.R Tolkein' })
const clone = recordType.clone(record)
createId(): ID<R>
Create an Id for a record of this type.
const id = recordType.createId()
createCustomId(id: string): ID<R>
Create a custom Id for a record of this type.
const id = recordType.createCustomId('tolkein')
isInstance
Check if a value is an instance of this record type.
const record = recordType.create({ name: 'J.R.R Tolkein' })
const result1 = recordType.isInstance(record) // true
const result2 = recordType.isInstance(someOtherRecord) // false
isId
Check if a value is an id for a record of this type.
const id = recordType.createCustomId('tolkein')
const result1 = recordType.isId(id) // true
const result2 = recordType.isId(someOtherId) // false
withDefaultProperties
Create a new record type with default properties.
const youngLivingAuthor = new RecordType('author', () => ({ age: 28, living: true }))
const oldDeadAuthor = recordType.withDefaultProperties({ age: 93, living: false })
RecordStoreQueries
TODO
Helpers
executeQuery
TODO
DerivationCache
The DerivationCache
class is used to create a cache of derived records.
const derivationCache = new DerivationCache('popular_authors', (record) => {
return record.popularity > 62 ? record : undefined
})
createRecordType
A helper used to create a new RecordType
instance with no default properties.
const recordType = createRecordType('author'))
assertIdType
A helper used to assert that a value is an id for a record of a given type.
const id = recordType.createCustomId('tolkein')
assertIdType(id, recordType)
Types
ID
A type used to represent a record's id.
const id: ID<Author> = Author.createCustomId('tolkein')
BaseRecord
A BaseRecord
is a record that has an id and a type. It is the base type for all records.
type AuthorRecord extends BaseRecord<"author"> {
name: string
age: number
living: boolean
}
AllRecords
A helper to get the type of all records in a record store.
type AllAuthorRecords = AllRecords<RecordStore<Author>>
RecordsDiff
A diff describing the changes to a record.
CollectionDiff
A diff describing the changes to a collection.
License
The source code in this repository (as well as our 2.0+ distributions and releases) are currently licensed under Apache-2.0. These licenses are subject to change in our upcoming 2.0 release. If you are planning to use tldraw in a commercial product, please reach out at hello@tldraw.com.