b4c1f606e1
Focus management is really scattered across the codebase. There's sort of a battle between different code paths to make the focus the correct desired state. It seemed to grow like a knot and once I started pulling on one thread to see if it was still needed you could see underneath that it was accounting for another thing underneath that perhaps wasn't needed. The impetus for this PR came but especially during the text label rework, now that it's much more easy to jump around from textfield to textfield. It became apparent that we were playing whack-a-mole trying to preserve the right focus conditions (especially on iOS, ugh). This tries to remove as many hacks as possible, and bring together in place the focus logic (and in the darkness, bind them). ## Places affected - [x] `useEditableText`: was able to remove a bunch of the focus logic here. In addition, it doesn't look like we need to save the selection range anymore. - lingering footgun that needed to be fixed anyway: if there are two labels in the same shape, because we were just checking `editingShapeId === id`, the two text labels would have just fought each other for control - [x] `useFocusEvents`: nixed and refactored — we listen to the store in `FocusManager` and then take care of autoFocus there - [x] `useSafariFocusOutFix`: nixed. not necessary anymore because we're not trying to refocus when blurring in `useEditableText`. original PR for reference: https://github.com/tldraw/brivate/pull/79 - [x] `defaultSideEffects`: moved logic to `FocusManager` - [x] `PointingShape` focus for `startTranslating`, decided to leave this alone actually. - [x] `TldrawUIButton`: it doesn't look like this focus bug fix is needed anymore, original PR for reference: https://github.com/tldraw/tldraw/pull/2630 - [x] `useDocumentEvents`: left alone its manual focus after the Escape key is hit - [x] `FrameHeading`: double focus/select doesn't seem necessary anymore - [x] `useCanvasEvents`: `onPointerDown` focus logic never happened b/c in `Editor.ts` we `clearedMenus` on pointer down - [x] `onTouchStart`: looks like `document.body.click()` is not necessary anymore ## Future Changes - [ ] a11y: work on having an accessebility focus ring - [ ] Page visibility API: (https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) events when tab is back in focus vs. background, different kind of focus - [ ] Reexamine places we manually dispatch `pointer_down` events to see if they're necessary. - [ ] Minor: get rid of `useContainer` maybe? Is it really necessary to have this hook? you can just do `useEditor` → `editor.getContainer()`, feels superfluous. ## Methodology Looked for places where we do: - `body.click()` - places we do `container.focus()` - places we do `container.blur()` - places we do `editor.updateInstanceState({ isFocused })` - places we do `autofocus` - searched for `document.activeElement` ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [ ] `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 - [x] run test-focus.spec.ts - [x] check MultipleExample - [x] check EditorFocusExample - [x] check autoFocus - [x] check style panel usage and focus events in general - [x] check text editing focus, lots of different devices, mobile/desktop ### Release Notes - Focus: rework and untangle existing focus management logic in the SDK |
||
---|---|---|
.. | ||
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-v2
for tldraw free where we mainly store the snapshots datatldraw-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:
- 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 URL
printed out in the step 2. - If you ever need to reset your local supabase instance you can run
supabase db reset
in the root ofapps/app
project. - 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 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.