Tldraw/apps/examples/src/examples/shape-with-migrations/ShapeWithMigrationsExample.tsx

175 wiersze
4.1 KiB
TypeScript
Czysty Zwykły widok Historia

import {
BaseBoxShapeUtil,
HTMLContainer,
T,
TLBaseShape,
TLOnResizeHandler,
New migrations again (#3220) 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>
2024-04-15 12:53:42 +00:00
TLStoreSnapshot,
Tldraw,
resizeBox,
} from 'tldraw'
import 'tldraw/tldraw.css'
import snapshot from './snapshot.json'
// There's a guide at the bottom of this file!
export type IMyShape = TLBaseShape<
'myshape',
{
w: number
h: number
color: string
}
>
export class MigratedShapeUtil extends BaseBoxShapeUtil<IMyShape> {
static override type = 'myshape' as const
static override props = {
w: T.number,
h: T.number,
color: T.string,
}
// [1]
static override migrations = {
firstVersion: 0,
currentVersion: 1,
migrators: {
1: {
up(shape: IMyShape) {
return {
...shape,
props: {
...shape.props,
color: 'lightblue',
},
}
},
down(shape: IMyShape) {
const { color: _, ...propsWithoutColor } = shape.props
return {
...shape,
props: propsWithoutColor,
}
},
},
},
}
getDefaultProps(): IMyShape['props'] {
return {
w: 300,
h: 300,
color: 'lightblue',
}
}
component(shape: IMyShape) {
return (
<HTMLContainer
id={shape.id}
style={{
backgroundColor: shape.props.color,
boxShadow: '0 0 10px rgba(0,0,0,0.5)',
}}
></HTMLContainer>
)
}
indicator(shape: IMyShape) {
return <rect width={shape.props.w} height={shape.props.h} />
}
override onResize: TLOnResizeHandler<IMyShape> = (shape, info) => {
return resizeBox(shape, info)
}
}
const customShapeUtils = [MigratedShapeUtil]
export default function ShapeWithMigrationsExample() {
return (
<div className="tldraw__editor">
<Tldraw
// Pass in the array of custom shape classes
shapeUtils={customShapeUtils}
// Use a snapshot to load an old version of the shape
New migrations again (#3220) 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>
2024-04-15 12:53:42 +00:00
snapshot={snapshot as TLStoreSnapshot}
/>
</div>
)
}
/*
Introduction:
Sometimes you'll want to update the way a shape works in your application without
breaking older versions of the shape that a user may have stored or persisted in
memory.
This example shows how you can use our migrations system to upgrade (or downgrade)
user's data between different versions. Most of the code above is general "custom
shape" codesee our custom shape example for more details.
[1]
To define migrations, we can override the migrations property of our shape util. Each migration
had two parts: an `up` migration and `down` migration. In this case, the `up` migration adds
the `color` prop to the shape, and the `down` migration removes it.
In some cases (mainly in multiplayer sessions) a peer or server may need to take a later
version of a shape and migrate it down to an older versionin this case, it would run the
down migrations in order to get it to the needed version.
How it works:
Each time the editor's store creates a snapshot (`editor.store.createSnapshot`), it
serializes all of the records (the snapshot's `store`) as well as versions of each
record that it contains (the snapshot's `scena`). When the editor loads a snapshot,
it compares its current schema with the snapshot's schema to determine which migrations
to apply to each record.
In this example, we have a snapshot (snapshot.json) that we created in version 0,
however our shape now has a 'color' prop that was added in version 1.
The snapshot looks something like this:
```json{
{
"store": {
"shape:BqG5uIAa9ig2-ukfnxwBX": {
...,
"props": {
"w": 300,
"h": 300
},
},
"schema": {
...,
"recordVersions": {
...,
"shape": {
"version": 3,
"subTypeKey": "type",
"subTypeVersions": {
...,
"myshape": 0
}
}
}
}
}
}
```
Note that the shape in the snapshot doesn't have a 'color' prop.
Note also that the schema's version for this shape is 0.
When the editor loads the snapshot, it will compare the serialzied schema's version with
its current schema's version for the shape, which is 1 as defined in our shape's migrations.
Since the serialized version is older than its current version, it will use our migration
to bring it up to date: it will run the migration's `up` function, which will add the 'color'
prop to the shape.
*/