PrivateCoffee/tldraw
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
tldraw/apps/dotcom
History
Steve Ruiz ac0259a6af
Composable custom UI (#2796) 
This PR refactors our menu systems and provides an interface to hide or
replace individual user interface elements.

# Background

Previously, we've had two types of overrides:
- "schema" overrides that would allow insertion or replacement of items
in the different menus
- "component" overrides that would replace components in the editor's
user interface

This PR is an attempt to unify the two and to provide for additional
cases where the "schema-based" user interface had begun to break down.

# Approach

This PR makes no attempt to change the `actions` or `tools`
overrides—the current system seems to be correct for those because they
are not reactive. The challenge with the other ui schemas is that they
_are_ reactive, and thus the overrides both need to a) be fed in from
outside of the editor as props, and b) react to changes from the editor,
which is an impossible situation.

The new approach is to use React to declare menu items. (Surprise!) 

```tsx
function CustomHelpMenuContent() {
	return (
		<>
			<DefaultHelpMenuContent />
			<TldrawUiMenuGroup id="custom stuff">
				<TldrawUiMenuItem
					id="about"
					label="Like my posts"
					icon="external-link"
					readonlyOk
					onSelect={() => {
						window.open('https://x.com/tldraw', '_blank')
					}}
				/>
			</TldrawUiMenuGroup>
		</>
	)
}

const components: TLComponents = {
	HelpMenuContent: CustomHelpMenuContent,
}

export default function CustomHelpMenuContentExample() {
	return (
		<div className="tldraw__editor">
			<Tldraw components={components} />
		</div>
	)
}
```

We use a `components` prop with the combined editor and ui components.

- [ ] Create a "layout" component?
- [ ] Make UI components more isolated? If possible, they shouldn't
depend on styles outside of themselves, so that they can be used in
other layouts. Maybe we wait on this because I'm feeling a slippery
slope toward presumptions about configurability.
- [ ] OTOH maybe we go hard and consider these things as separate
components, even packages, with their own interfaces for customizability
/ configurability, just go all the way with it, and see what that looks
like.

# Pros

Top line: you can customize tldraw's user interface in a MUCH more
granular / powerful way than before.

It solves a case where menu items could not be made stateful from
outside of the editor context, and provides the option to do things in
the menus that we couldn't allow previously with the "schema-based"
approach.

It also may (who knows) be more performant because we can locate the
state inside of the components for individual buttons and groups,
instead of all at the top level above the "schema". Because items /
groups decide their own state, we don't have to have big checks on how
many items are selected, or whether we have a flippable state. Items and
groups themselves are allowed to re-build as part of the regular React
lifecycle. Menus aren't constantly being rebuilt, if that were ever an
issue.

Menu items can be shared between different menu types. We'll are
sometimes able to re-use items between, for example, the menu and the
context menu and the actions menu.

Our overrides no longer mutate anything, so there's less weird searching
and finding.

# Cons

This approach can make customization menu contents significantly more
complex, as an end user would need to re-declare most of a menu in order
to make any change to it. Luckily a user can add things to the top or
bottom of the context menu fairly easily. (And who knows, folks may
actually want to do deep customization, and this allows for it.)

It's more code. We are shipping more react components, basically one for
each menu item / group.

Currently this PR does not export the subcomponents, i.e. menu items. If
we do want to export these, then heaven help us, it's going to be a
_lot_ of exports.

# Progress 

- [x] Context menu
- [x] Main menu
- [x] Zoom menu
- [x] Help menu
- [x] Actions menu
- [x] Keyboard shortcuts menu
- [x] Quick actions in main menu? (new)
- [x] Helper buttons? (new)
- [x] Debug Menu

And potentially
- [x] Toolbar
- [x] Style menu
- [ ] Share zone
- [x] Navigation zone
- [ ] Other zones

### Change Type

- [x] `major` — Breaking change

### Test Plan

1. use the context menu
2. use the custom context menu example
3. use cursor chat in the context menu

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

### Release Notes

- Add a brief release note for your PR here.
2024-02-15 12:10:09 +00:00
..
public seo: take 2 (#2817) 2024-02-15 11:28:43 +00:00
scripts fix(infra): Fix routing config (#2741) 2024-02-06 13:31:02 +00:00
src Composable custom UI (#2796) 2024-02-15 12:10:09 +00:00
styles [Improvement] Share zone styling (#2628) 2024-01-25 20:29:25 +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 seo: take 2 (#2817) 2024-02-15 11:28:43 +00:00
package.json dev: swap yarn test and test-dev for better dx (#2773) 2024-02-14 16:05:59 +00:00
README.md unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
sentry-release-name.ts unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
sentry.client.config.ts unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
sentry.properties unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
setupTests.js unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
tsconfig.json unbrivate, dot com in (#2475) 2024-01-16 14:38:05 +00:00
vite.config.ts [dotcom] Delete service worker, cache tldraw assets (#2552) 2024-01-19 15:31:01 +00:00

README.md

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.