tldraw/apps/dotcom
Mitja Bezenšek 15dd56a75e
Readonly / room creation omnibus (#3192)
Reworks how the readonly urls work. Till now we just used a simple
function that would scramble the slugs. Now we use a proper key value
mapping between regular and readonly slugs:

- We use two KV stores. One is for going from a slug to a readonly slug
and the other one for going the other way around. They are populated at
the same time.
- We separate preview KV stores (dev, preview, staging) from production
one. I've already created these on Cloudflare. [My understanding is
](https://developers.cloudflare.com/kv/reference/data-security/#encryption-at-rest)that
ids [can be
public](https://community.cloudflare.com/t/is-it-safe-to-keep-kv-ids-in-a-public-git-repo/517387/4)
since we can only access KV from our worker. Happy to move them to env
variables though.

- [x] Disable creating new rooms when tldraw is embedded inside iframes
on other websites (we check the referrer and if it's not the same as the
iframe's origin we don't allow it)
- [x] Fork a project when inside an iframe now opens the forked project
on tldraw.com and not inside iframe.
- [x] We allow embeding of iframes, but we now track the where they are
used via the referrer. We send this to Vercel analytics.
- [x] Improved UX of the share menu to make it less confusing. Toggle is
gone.
- [x]  `/new` and `/r` routes not redirect to `/`.
- [x] This introduces a new `/ro` route for readonly rooms. Legacy rooms
still live on `/v`.
- [x] Brought back `dotcom-shared` project to share code between BE and
FE. Mostly types.
- [x] Prevent creating of rooms by entering `/r/non-existing-slug`. 
- [x] Handle getting a readonly slug for old rooms. Added a comment
about it
[here](https://github.com/tldraw/tldraw/pull/3192/files#diff-c0954b3dc71bb7097c39656441175f3238ed60cf5cee64077c06e21da82182cbR17-R18).
- [x] We no longer expose editor on the window object for readonly
rooms. Prevents the users disabling readonly rooms manually.

### Change Type

<!--  Please select a 'Scope' label ️ -->

- [ ] `sdk` — Changes the tldraw SDK
- [x] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [ ] `internal` — Does not affect user-facing stuff

<!--  Please select a 'Type' label ️ -->

- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [x] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know


### Test Plan
1. Make sure old readonly rooms still work.
2. Creating a readonly link from an existing room should still use `/v`
path.
3. Newly created rooms should use `/ro` path for readonly rooms. Make
sure these work as well.
4. `/r` room was disabled and redirects to `/`
5. `/new` should still work when not inside iframes.

- [x] Unit Tests
- [ ] End to end tests

### Release Notes


1. This adds new functionality for readonly rooms:
- We have a new route `/ro` for newly created readonly rooms. These
rooms no longer use the scrambling logic to create readonly slugs.
Instead we now use KV storage from cloudflare to track the mapping for
slugs -> readonly slug and readonly slug -> slug.
- The old route `/v` is preserved, so that the old room still work as
they did before.
- For old rooms we will keep on generating the old readonly slugs, but
for new rooms we'll start using the new logic.
2. We no longer prevent embedding of tldraw inside iframes. 
3. We do prevent generating new rooms from inside the iframes though.
`/r`, `/new`, `/r/non-existing-id` should not allow creation of new
rooms inside iframes. Only `/new` still works when not inside iframes.
4. Forking a project from inside an iframe now opens it on tldraw.com
5. Slight copy change on the sharing menu. We no longer have a toggle
between readonly and non-readonly links.
6. `editor` and `app` are no longer exposed on the window object for
readonly rooms. Prevents users from using the `updateInstanceState` to
escape readonly rooms.

---------

Co-authored-by: Mime Čuvalo <mimecuvalo@gmail.com>
2024-04-25 14:10:40 +00:00
..
public seo: take 2 (#2817) 2024-02-15 11:28:43 +00:00
scripts Readonly / room creation omnibus (#3192) 2024-04-25 14:10:40 +00:00
src Readonly / room creation omnibus (#3192) 2024-04-25 14:10:40 +00:00
styles Readonly / room creation omnibus (#3192) 2024-04-25 14:10:40 +00:00
.eslintignore Better websocket reconnection handling (#2960) 2024-03-04 16:48:14 +00:00
.gitignore [dotcom] Delete service worker, cache tldraw assets (#2552) 2024-01-19 15:31:01 +00:00
CHANGELOG.md unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
decs.d.ts unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
index.html [dx] Allow vscode to search inside md files by default (#3105) 2024-03-11 14:08:04 +00:00
jestResolver.js Better websocket reconnection handling (#2960) 2024-03-04 16:48:14 +00:00
package.json Readonly / room creation omnibus (#3192) 2024-04-25 14:10:40 +00:00
README.md [dx] Allow vscode to search inside md files by default (#3105) 2024-03-11 14:08:04 +00:00
sentry-release-name.ts unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
sentry.client.config.ts tldraw_final_v6_final(old version).docx.pdf (#2998) 2024-02-29 16:06:19 +00:00
sentry.properties unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
setupTests.js React-powered SVG exports (#3117) 2024-03-25 14:16:55 +00:00
tsconfig.json Readonly / room creation omnibus (#3192) 2024-04-25 14:10:40 +00:00
version.ts Update CHANGELOG.md [skip ci] 2024-04-23 11:47:53 +00:00
vite.config.ts [dotcom] Delete service worker, cache tldraw assets (#2552) 2024-01-19 15:31:01 +00:00

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-v2 for tldraw free where we mainly store the snapshots data
  • tldraw-pro for 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:

  1. Start a local instance of supabase
  2. Run any database migrations
  3. Update your .env.local file with credentials for your local supabase instance
  4. 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

  1. You can see your db schema at the Studio URL printed out in the step 2.
  2. If you ever need to reset your local supabase instance you can run supabase db reset in the root of apps/app project.
  3. 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 URL printed 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 production
  • snapshots_staging - for staging
  • snapshots_dev - for development

For local development you need to add the following env variables to .env.local:

  • SUPABASE_URL - use the production supabase url
  • SUPABASE_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.