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> |
||
|---|---|---|
| .. | ||
| public | ||
| scripts | ||
| src | ||
| styles | ||
| .eslintignore | ||
| .gitignore | ||
| CHANGELOG.md | ||
| decs.d.ts | ||
| index.html | ||
| jestResolver.js | ||
| package.json | ||
| README.md | ||
| sentry-release-name.ts | ||
| sentry.client.config.ts | ||
| sentry.properties | ||
| setupTests.js | ||
| tsconfig.json | ||
| version.ts | ||
| vite.config.ts | ||
Project overview
This project is a Next.js application which contains the tldraw free as well as the tldraw pro applications. We are currently using the Next.js 13 option of having both pages (tldraw free) and app (tldraw pro) directory inside the same app. We did this since the free offering is the continuation of a Next.js version 12 app and it allowed us to combine it with the new App router option from Next.js 13 for tldraw pro without having to do a full migration to App router.
We also split the supabase into two projects:
tldraw-v2for tldraw free where we mainly store the snapshots datatldraw-profor tldraw pro which holds all the relational data that the pro version requires
On top of that we also use R2 for storing the documents data.
How to run the project
Tldraw pro
The development of tldraw pro happens against a local supabase instance. To set that up, you'll first need to install & start docker.
Once docker is started & you've run yarn to install tldraw's dependencies, the rest should be
handled automatically. Running yarn dev-app will:
- Start a local instance of supabase
- Run any database migrations
- Update your .env.local file with credentials for your local supabase instance
- Start tldraw
The supabase local development docs are a
good reference. When working on tldraw, the supabase command is available by running yarn supabase in the apps/app directory e.g. yarn supabase status.
When you're finished, we don't stop supabase because it takes a while each time we start and stop
it. Run yarn supabase stop to stop it manually.
If you write any new database migrations, you can apply those with yarn supabase migration up.
Some helpers
- You can see your db schema at the
Studio URLprinted out in the step 2. - If you ever need to reset your local supabase instance you can run
supabase db resetin the root ofapps/appproject. - The production version of Supabase sends out emails for certain events (email confirmation link, password reset link, etc). In local development you can find these emails at the
Inbucket URLprinted out in the step 2.
Tldraw free
The development of tldraw free happens against the production supabase instance. We only store snapshots data to one of the three tables, depending on the environment. The tables are:
snapshots- for productionsnapshots_staging- for stagingsnapshots_dev- for development
For local development you need to add the following env variables to .env.local:
SUPABASE_URL- use the production supabase urlSUPABASE_KEY- use the production supabase anon key
Once you have the environment variables set up you can run yarn dev-app from the root folder of our repo to start developing.
Running database tests
You need to have a psql client installed. You can then run yarn test-supabase to run db tests.
Sending emails
We are using Resend for sending emails. It allows us to write emails as React components. Emails live in a separate app apps/tl-emails.
Right now we are only using Resend via Supabase, but in the future we will probably also include Resend in our application and send emails directly.
The development workflow is as follows:
1. Creating / updating an email template
To start the development server for email run yarn dev-email from the root folder of our repo. You can then open http://localhost:3333 to see the result. This allows for quick local development of email templates.
Any images you want to use in the email should be uploaded to supabase to the email bucket.
Supabase provides some custom params (like the magic link url) that we can insert into our email, check their website for more info.
2. Generating the html version of the email
Once you are happy with the email template you can run yarn build-email from the root folder of our repo. This will generate the html version of the email and place it in apps/tl-emails/out folder.
3. Updating the template in Supabase
Once you have the html version of the email you can copy it into the Supabase template editor. You can find the templates here.