tldraw/packages/tlschema
David Sheldrick 731da1bc77
derived presence state (#1204)
This PR adds

- A new `TLInstancePresence` record type, to collect info about the
presence state in a particular instance of the editor. This will
eventually be used to sync presence data instead of sending
instance-only state across the wire.
- **Record Scopes**

`RecordType` now has a `scope` property which can be one of three
things:
- `document`: the record belongs to the document and should be synced
and persisted freely. Currently: `TLDocument`, `TLPage`, `TLShape`, and
`TLAsset`
- `instance`: the record belongs to a single instance of the store and
should not be synced at all. It should not be persisted directly in most
cases, but rather compiled into a kind of 'instance configuration' to
store alongside the local document data so that when reopening the
associated document it can remember some of the previous instance state.
Currently: `TLInstance`, `TLInstancePageState`, `TLCamera`, `TLUser`,
`TLUserDocument`, `TLUserPresence`
- `presence`: the record belongs to a single instance of the store and
should not be persisted, but may be synced using the special presence
sync protocol. Currently just `TLInstancePresence`

This sets us up for the following changes, which are gonna be pretty
high-impact in terms of integrating tldraw into existing systems:

- Removing `instanceId` as a config option. Each instance gets a
randomly generated ID.
- We'd replace it with an `instanceConfig` option that has stuff like
selectedIds, camera positions, and so on. Then it's up to library users
to get and reinstate the instance config at persistence boundaries.
- Removing `userId` as config option, and removing the `TLUser` type
altogether.
- We might need to revisit when doing auth-enabled features like locking
shapes, but I suspect that will be separate.
2023-04-27 18:03:19 +00:00
..
scripts transfer-out: transfer out 2023-04-25 12:01:25 +01:00
src derived presence state (#1204) 2023-04-27 18:03:19 +00:00
api-extractor.json transfer-out: transfer out 2023-04-25 12:01:25 +01:00
api-report.md derived presence state (#1204) 2023-04-27 18:03:19 +00:00
CHANGELOG.md transfer-out: transfer out 2023-04-25 12:01:25 +01:00
LICENSE transfer-out: transfer out 2023-04-25 12:01:25 +01:00
package.json [lite] upgrade lazyrepo (#1198) 2023-04-25 14:32:17 +01:00
README.md transfer-out: transfer out 2023-04-25 12:01:25 +01:00
tsconfig.json transfer-out: transfer out 2023-04-25 12:01:25 +01:00

@tldraw/tlschema

This package houses type definitions, schema migrations, and other type metadata for any persisted data in tldraw.

There are three main kinds of types:

  • Record types

    These are root record types added to the Store class. They are defined in the ./src/records directory.

  • Shape types

    These are subtypes of the root TLShape record type. They allow specifying a unique name and custom props for a particular kind of shape.

  • Asset types

    These are subtypes of the root TLAsset record type. They allow specifying a unique name and custom props for a particular kind of asset.

Creating a new record type

To create a new record type called, e.g. TLBanana, run

# Create the new file in ./records/TLBanana.ts
yarn new-record TLBanana
# Rebuild the index files to make sure it is exported
yarn index

You may then customize your new blank TLBanana type!

Creating a new shape type

To create a new shape type called, e.g. TLMapboxShape, run

# Create the new file in ./shapes/TLMapboxShape.ts
yarn new-shape TLMapboxShape
# Rebuild the index files to make sure it is exported
yarn index

You may then customize your new blank TLMapboxShape type!

Creating a new asset type

To create a new shape type called, e.g. TLZipFileAsset, run

# Create the new file in ./assets/TLZipFileAsset.ts
yarn new-asset TLZipFileAsset
# Rebuild the index files to make sure it is exported
yarn index

You may then customize your new blank TLZipFileAsset type!

Adding migrations

If you make any kind of change to any persisted data shape in this package, you must add migrations that are able to convert old versions to new versions, and vice-versa.

If you are making a change that affects the structure of a record, shape, or asset, update the migrations in the same file as the record, shape, or asset is defined.

If you are making a change that affects the structure of the store (e.g. renaming or deleting a type, consolidating two shape types into one, etc), add your changes in the migrations in schema.ts.

After making your changes, add a new version number, using a meaninful name. For example, if you add a new property to the TLShape type called ownerId that points to a user, you might do this:

In TLShape.ts

 const Versions = {
   Initial: 1,
+  AddOwnerId: 2,
 } as const

and then in the TLShape type

   x: number
   y: number
+  ownerId: ID<TLUser> | null
   props: Props
   parentId: ID<TLShape> | ID<TLPage>

and then adding a migration:

 export const shapeTypeMigrations = defineMigrations({
   // STEP 2: Update the current version to point to your latest version
   currentVersion: Versions.Initial,
   firstVersion: Versions.Initial,
   migrators: {
     // STEP 3: Add an up+down migration for the new version here
+    [Versions.AddOwnerId]: {
+      // add ownerId property
+      up: (shape) => ({...shape, ownerId: null}),
+      // remove ownerId property
+      down: ({ownerId, ...shape}) => shape,
+    }
   },

After you've added your migration, make sure to add a test for it in src/migrations.test.ts. It will complain if you do not!