4f70a4f4e8
Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com> |
||
|---|---|---|
| .. | ||
| api | ||
| src | ||
| CHANGELOG.md | ||
| LICENSE.md | ||
| README.md | ||
| api-extractor.json | ||
| api-report.md | ||
| package.json | ||
| tsconfig.json | ||
README.md
@tldraw/tlschema
This package houses type definitions, schema migrations, and other type metadata for the tldraw editor's default persisted data.
There are three main kinds of types:
-
Record types
These are root record types added to the
Storeclass. They are defined in the./src/recordsdirectory. -
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.
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 = {
RemoveSomeProp: 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({
currentVersion: Versions.Initial,
firstVersion: Versions.Initial,
migrators: {
+ [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!
Community
Have questions, comments or feedback? Join our discord or start a discussion.
Distributions
You can find tldraw on npm here.
Contribution
Please see our contributing guide. Found a bug? Please submit an issue.
License
The tldraw source code and its distributions are provided under the tldraw license. This license does not permit commercial use.
If you wish to use this project in commercial product, you need to purchase a commercial license. Please contact us at hello@tldraw.com for more inforion about obtaining a commercial license.
Trademarks
Copyright (c) 2023-present tldraw Inc. The tldraw name and logo are trademarks of tldraw. Please see our trademark guidelines for info on acceptable usage.
Contact
Find us on Twitter at @tldraw or email hello@tldraw.com. You can also join our discord for quick help and support.