This PR fixes the issue where the arrow label was black in dark mode
instead of white.
light mode (normal):
<img width="600" alt="Screenshot 2023-07-12 at 00 21 35"
src="https://github.com/tldraw/tldraw/assets/5616556/2ac5e951-7777-4e96-9dde-a410a754aa01">
dark mode (before):
<img width="600" alt="Screenshot 2023-07-12 at 00 21 52"
src="https://github.com/tldraw/tldraw/assets/5616556/c67c3309-2847-4499-b4ef-6ba686e1382e">
dark mode (after):
<img width="600" alt="Screenshot 2023-07-12 at 00 21 44"
src="https://github.com/tldraw/tldraw/assets/5616556/244987c0-4570-410b-8975-43db47b786fa">
Fixes#1716
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Add an arrow with label
2. Switch between dark and light mode and notice that the label color
adapts correctly
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- fixed arrow label dark mode color
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR moves code between our packages so that:
- @tldraw/editor is a “core” library with the engine and canvas but no
shapes, tools, or other things
- @tldraw/tldraw contains everything particular to the experience we’ve
built for tldraw
At first look, this might seem like a step away from customization and
configuration, however I believe it greatly increases the configuration
potential of the @tldraw/editor while also providing a more accurate
reflection of what configuration options actually exist for
@tldraw/tldraw.
## Library changes
@tldraw/editor re-exports its dependencies and @tldraw/tldraw re-exports
@tldraw/editor.
- users of @tldraw/editor WITHOUT @tldraw/tldraw should almost always
only import things from @tldraw/editor.
- users of @tldraw/tldraw should almost always only import things from
@tldraw/tldraw.
- @tldraw/polyfills is merged into @tldraw/editor
- @tldraw/indices is merged into @tldraw/editor
- @tldraw/primitives is merged mostly into @tldraw/editor, partially
into @tldraw/tldraw
- @tldraw/file-format is merged into @tldraw/tldraw
- @tldraw/ui is merged into @tldraw/tldraw
Many (many) utils and other code is moved from the editor to tldraw. For
example, embeds now are entirely an feature of @tldraw/tldraw. The only
big chunk of code left in core is related to arrow handling.
## API Changes
The editor can now be used without tldraw's assets. We load them in
@tldraw/tldraw instead, so feel free to use whatever fonts or images or
whatever that you like with the editor.
All tools and shapes (except for the `Group` shape) are moved to
@tldraw/tldraw. This includes the `select` tool.
You should use the editor with at least one tool, however, so you now
also need to send in an `initialState` prop to the Editor /
<TldrawEditor> component indicating which state the editor should begin
in.
The `components` prop now also accepts `SelectionForeground`.
The complex selection component that we use for tldraw is moved to
@tldraw/tldraw. The default component is quite basic but can easily be
replaced via the `components` prop. We pass down our tldraw-flavored
SelectionFg via `components`.
Likewise with the `Scribble` component: the `DefaultScribble` no longer
uses our freehand tech and is a simple path instead. We pass down the
tldraw-flavored scribble via `components`.
The `ExternalContentManager` (`Editor.externalContentManager`) is
removed and replaced with a mapping of types to handlers.
- Register new content handlers with
`Editor.registerExternalContentHandler`.
- Register new asset creation handlers (for files and URLs) with
`Editor.registerExternalAssetHandler`
### Change Type
- [x] `major` — Breaking change
### Test Plan
- [x] Unit Tests
- [x] End to end tests
### Release Notes
- [@tldraw/editor] lots, wip
- [@tldraw/ui] gone, merged to tldraw/tldraw
- [@tldraw/polyfills] gone, merged to tldraw/editor
- [@tldraw/primitives] gone, merged to tldraw/editor / tldraw/tldraw
- [@tldraw/indices] gone, merged to tldraw/editor
- [@tldraw/file-format] gone, merged to tldraw/tldraw
---------
Co-authored-by: alex <alex@dytry.ch>
This PR adds support for custom shapes (`shapes`) to the y.js example. A
user should pass the same data to the `useYjsStore` hook as they pass to
the `<Tldraw>` component.
### Change Type
- [x] `internal`
Bumps the VS Code version.
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
Fix cloud tool tooltip
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### 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
- Add a brief release note for your PR here.
This PR adds some tools docs. There's more to come (eventually), but
this is what's finished so far.
This PR relies on this brivate one landing first:
https://github.com/tldraw/brivate/pull/2223
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Release Notes
- Tools docs.
This makes the bumps on the curvy parts more bumpy, and improves the way
inky clouds are drawn to make it less likely to produce double lines
that do not fully overlap.
<img width="1066" alt="image"
src="https://github.com/tldraw/tldraw/assets/1242537/6119c6e8-ceee-4cf6-b393-70efbbdd6373">
### Change Type
- [x] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [ ] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### 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
- Add a brief release note for your PR here.
### Change Type
- [x] `minor` — New feature
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Make some cloud shapes, try different sizes, colors, fills.
2. Export cloud shapes to images.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Adds a cloud shape.
We'd like to make the @tldraw/editor layer more independent of specific
shapes. Unfortunately there are many places where shape types and
certain shape behavior is deeply embedded in the Editor. This PR begins
to refactor out dependencies between the editor library and shape utils.
It does this in two ways:
- removing shape utils from the arguments of `isShapeOfType`, replacing
with a generic
- removing shape utils from the arguments of `getShapeUtil`, replacing
with a generic
- moving custom arrow info cache out of the util and into the editor
class
- changing the a tool's `shapeType` to be a string instead of a shape
util
We're here trading type safety based on inferred types—"hey editor, give
me your instance of this shape util class"—for knowledge at the point of
call—"hey editor, give me a shape util class of this type; and trust me
it'll be an instance this shape util class". Likewise for shapes.
### A note on style
We haven't really established our conventions or style when it comes to
types, but I'm increasingly of the opinion that we should defer to the
point of call to narrow a type based on generics (keeping the types in
typescript land) rather than using arguments, which blur into JavaScript
land.
### Change Type
- [x] `major` — Breaking change
### Test Plan
- [x] Unit Tests
### Release Notes
- removes shape utils from the arguments of `isShapeOfType`, replacing
with a generic
- removes shape utils from the arguments of `getShapeUtil`, replacing
with a generic
- moves custom arrow info cache out of the util and into the editor
class
- changes the a tool's `shapeType` to be a string instead of a shape
util
🚨 Note 🚨
This PR has changed! See my [newer
comment](https://github.com/tldraw/tldraw/pull/1706#issuecomment-1623451709)
for what the PR does now.
This description is kept here to show the original intention of the PR.
---
This PR fixes the tsdocs formatting of `TldrawEditorProps`, so that they
appears on the docs site.
We have docs already written, but they weren't appearing. There are
probably others like this too.
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Navigate to `/gen/editor/TldrawEditorProps`
2. Make sure that that the parameters are listed out with descriptions.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Docs: Fixed some missing docs for the TldrawEditor component.
This PR removes the `tool` parameter from the `defineShape` function.
It's an opinionated change that I think we should at the very least
consider.
## What's the context?
Currently, you can add **tools** (aka state nodes) to your state chart
in two different ways:
1. Passing them to the `<Tldraw>` component with the `tools` attribute.
2. As part of a shape definition's `tool` property, which you then pass
to the `<Tldraw>` component with the `shapes` attribute.
This is what (1) looks like:
```jsx
import { MyTool } from "./MyTool"
function Example() {
return <Tldraw tools={[MyTool]} />
}
```
This is what (2) looks like:
```jsx
import { MyTool } from "./MyTool"
import { MyShapeUtil, myShapeProps } from "./MyShape"
const MyShapeDefinition = defineShape("my-shape", {
util: MyShapeUtil,
props: myShapeProps,
tool: MyTool,
})
function Example() {
return <Tldraw shapes={[MyShapeDefinition]} />
}
```
Clearly, (1) is better for when you want to add *just a tool*, that
doesn't have an associated shape.
And (2) is better for when you want to add *both* a tool and an
associated shape.
## Why change it?
I think we should remove method (2). Because I think that it adds a few
complications.
#### Does it help?
I don't think that it helps to streamline the process of coupling shapes
and tools. You still need to remember to add your tool.
Seeing as `tool` is optional on the shape definition (rightly so), it
doesn't prompt you to do it.
#### What's easier to explain?
I think it's easier to just have to explain _one method_. It would take
longer to explain two methods, and it complicates the concepts involved.
Seeing as there's not a big benefit to one method over the other, the
added explanation wouldn't be a good trade-off.
#### What happens if I use both?
It's unclear to the user what would happen if they use both methods. Do
we know what the intended behaviour of this would be? I think this will
happen often.
```jsx
import { MyTool } from "./MyTool"
import { MyShapeUtil, myShapeProps } from "./MyShape"
const MyShapeDefinition = defineShape("my-shape", {
util: MyShapeUtil,
props: myShapeProps,
tool: MyTool,
})
function Example() {
return <Tldraw tools={[MyTool]} shapes={[MyShapeDefinition]} />
}
```
#### Does it fit my shape/tool?
Many shapes are coupled closely with one tool. But some shapes would
involve multiple tools. And some tools would involve multiple shapes.
For example, you might first add a tool and a shape that go nicely
together, so you use method (2). But two months later, you decide that
you want another tool to be able to make this shape too. Now you've
inserted your related tools in two different places, unless you
refactor.
Alternatively, you might want to add some more functionality to your
tool, so that it can make multiple types of shapes. Instead of
refactoring the existing shape, you want to create an entirely new
shape, to keep your new code separate. Should you add the `tool`
property to the new shape as well? What would happen if you did/didn't?
What happens if you later disable the original shape? Would you need to
move the `tool` property from there to the newer shape?
It would be a lot simpler to just have the tool in your list of tools,
instead of having them tangled up with shapes.
#### Plugins?
We've been considering moving towards some sort of 'plugins' system in
the future, that could collect together shapes, tools, and other stuff.
I think that a more complete concept of a 'plugin' would be the best
place to collect together shapes, and tools — not on the shape itself.
### Change Type
- [x] `major` — Breaking change
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Try using all of the app's tools, making sure they still work.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- [dev] Removed the `tool` property from `defineShape`
This PR:
- adds tests for shape reordering
- removes `Editor.getParentsMappedToChildren`
- removes `Editor.reorderShapes`
- moves reordering shapes code into its own file, outside of the editor
### Change Type
- [x] `major` — Breaking change (if you were using those APIs)
### Release Notes
- [api] removes `Editor.getParentsMappedToChildren`
- [api] removes `Editor.reorderShapes`
- [api] moves reordering shapes code into its own file, outside of the
editor
This PR removes the strict state checks for the brush and zoom brush. We
should consider making the canvas more controlled by what exists (e.g.
whether a `brush` exists) rather than depending on particular statechart
states.
### Change Type
- [x] `minor`
### Test Plan
1. Create a brush manually in the API.
2. The brush should be visible on the canvas.
### Release Notes
- [editor] remove `editor.isIn` state checks for displaying brush and
zoom brush.
This PR adds links to the API reference from within the docs pages.
I think we should continue with this as we move forwards with more
content.
We could tweak the threshold of what we link or don't link. I tried to
strike a good balance (maybe linked too much though). We'd want lots of
stuff to be clickable, so that users can dive into the API. But we don't
want the screen to be a splattering of blue, distracting away from more
important stuff.
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Try out some of the newly added links on the docs site.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Documentation: Added links to API reference in guides.
Once we are done resizing (when inserting text) we now show the default
cursor.
Fixes#1699
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Select text tool
2. Insert a text shape by dragging to select it's size.
3. After you are done dragging the cursor should go back to the default
cursor.
### Release Notes
- Switch back to the default cursor after you are done inserting a new
text shape.
I accidentally checked in a bunch of stuff i shouldn't. oops.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
This PR fixes the editor sometimes incorrectly assuming that you're
using a coarse pointer in firefox. It's not a complete fix — it just
avoids some of the bigger issues with it. ie: It disables cursor chat.
To avoid the issue, we just assume that you have a fine pointer if
you're using firefox on desktop.
Eventually, we should do a more complete fix for this.
I QA'd this change on:
* Mac Firefox (no touch screen)
* Windows Firefox (touch screen)
* Android Firefox
### Change Type
- [x] `patch` — Bug fix
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Use firefox on desktop with a touch screen.
2. Check that you can still use cursor chat (when in a shared project).
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Fixed firefox not being able to use cursor chat when using a touch
screen on desktop.
This PR fixes the tsdocs formatting on the TldrawUi component so that
they appear on the docs site. Very similar to
https://github.com/tldraw/tldraw/pull/1706
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Go to `/gen/ui/TldrawUiProps`
2. Make sure that there are descriptions for all parameters.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Docs: Show some docs missing from TldrawUi component.
Disable the style panel button on mobile layouts when using the laser
tool.
Fixes#1702
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Use a mobile layout.
2. Select laser tool
3. Make sure you cannot click the style panel button - it should be
disabled.
### Release Notes
- Disable the styles panel button for laser tool on mobile.
Highlighter is autolocked, so we shouldn't show the lock icon
### Change Type
- [x] `patch` — Bug fix
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### 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
- We no longer show the tool lock option for highlighter - it didn't do
anything anyway
This PR fixes pen mode.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. On iPad, use the pencil to enter pen mode
2. Select the draw tool
3. touch the screen
- [x] Unit Tests (sort of)
### Release Notes
- [fix] pen mode
This PR updates the repo's readme. Some things were out-of-date. For
example, the 'hello world' example didn't work.
See code comments for more detail!
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Release Notes
- Documentation: Updated readme to reflect recent library changes.
This PR sets up our publish-new script to use Huppy's GH token. At the
same time I added huppy to a list of actors who are allowed to override
the branch protection rules for `main` so hopefully next time we run the
release script the push will succeed and the release will therefore also
succeed. I will create a test repo to see if that works and if it does
I'll merge this.
### Change Type
- [ ] `patch` — Bug fix
- [ ] `minor` — New feature
- [ ] `major` — Breaking change
- [ ] `dependencies` — Changes to package dependencies[^1]
- [ ] `documentation` — Changes to the documentation only[^2]
- [ ] `tests` — Changes to any test code only[^2]
- [x] `internal` — Any other changes that don't affect the published
package[^2]
- [ ] I don't know
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
This PR fixes some incorrect types in the example on the Shapes page of
the docs.
### Change Type
- [x] `documentation` — Changes to the documentation only[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Release Notes
- Documentation: Fix some incorrect types on the Shapes page.
This PR adds some more nuance to collaborator cursors.
Rather than being timed out or not timed out, a collaborator can now be
`active`, `idle` or `inactive`.
We calculate this based on the difference between the time that has
elapsed since the user's last activity timestamp.
After 3 seconds of inactivity, they go `idle`.
After sixty seconds of inactivity, they are `inactive`.
After any activity, they become `active` again.
When a user is `active`, we always show their cursor.
When a user is `idle`, we hide their cursor if they're following us,
unless they're highlighted
When a user is `inactive`, we hide their cursor unless they're
highlighted.
### Change Type
- [x] `minor`
### Test Plan
1. Find a friend and experiment with inactive times
2. Join a room that includes an inactive cursors; they should be hidden
on load
3. Have people follow you; do their timeouts feel natural?
### Release Notes
- Improve cursor timeouts and hiding logic.
This PR should fix commits failing with the VS Code / Github Desktop ui
~~and help steve to stop using "ok" as a commit message~~
### Change Type
- [x] `internal` — Any other changes that don't affect the published
package[^2]
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Release Notes
- [internal] fixed commits failing from bublic when using UI
This PR fixes the shortcut for lock shapes, which may be blocked by
browser defaults. We now use Shift+L instead of Cmd+Shift+L. Closes
https://github.com/tldraw/tldraw/issues/1676.
### Change Type
- [x] `patch`
### Test Plan
1. Try the lock tool shortcuts.
- [x] End to end tests
### Release Notes
- [@tldraw/editor] Fix lock tool shortcut
This PR fixes some issues in our `useDocumentEvents`. It closes
https://github.com/tldraw/tldraw/issues/1667 (I think).
### Change Type
- [x] `patch`
### Release Notes
- [@tldraw/editor] Bug fixes on document events.
This PR adds `box-sizing: border-box` to the editor and its children.
### Change Type
- [x] `patch`
### Release Notes
- [@tldraw/editor] Add `box-sizing: border-box` to `tl-container`
This PR incorporates a crc method from
https://github.com/alexgorbatchev/crc into the library, removing a peer
dependency on `buffer`. This was causing build errors in apps that did
not include the buffer library. (Our codebase included buffer because of
vsce.)
### Change Type
- [x] `patch`
### Release Notes
- [@tldraw/editor] Remove peer dependency on buffer.
This PR adds the `ScribbleManager` to the exports from `@tldraw/editor`.
### Change Type
- [x] `minor` — New feature
### Release Notes
- [@tldraw/tldraw] Export `ScribbleManager`
We saw an issue on stackblitz where the `global` constant was causing a
conflict (possibly because that environment was injecting its own
`global`). Either way, perhaps `global` is a bit of a risky name—this PR
renames `global` to `tldrawStateGlobal`.
### Change Type
- [x] `patch`
This PR fixes shape rendering logic. Remember! memo's 2nd argument
returns "when should we NOT render" not "when should we render"
### Change Type
- [x] `patch`
### Test Plan
1. Use the draw tool
This PR adds a `meta` property to shapes and other records.
It adds it to:
- asset
- camera
- document
- instance
- instancePageState
- instancePresence
- page
- pointer
- rootShape
## Setting meta
This data can generally be added wherever you would normally update the
corresponding record.
An exception exists for shapes, which can be updated using a partial of
the `meta` in the same way that we update shapes with a partial of
`props`.
```ts
this.updateShapes([{
id: myShape.id,
type: "geo",
meta: {
nemesis: "steve",
special: true
}
])
```
## `Editor.getInitialMetaForShape`
The `Editor.getInitialMetaForShape` method is kind of a hack to set the
initial meta property for newly created shapes. You can set it
externally. Escape hatch!
### Change Type
- [x] `minor` — New feature
### Test Plan
todo
- [ ] Unit Tests (todo)
### Release Notes
- todo
This PR fixes an issue that I introduced where the `snapshot` argument
would be mutated by the `Store.migrateStoreSnapshot` method.
### Change Type
- [x] `patch`
### Release Notes
- [@tldraw/store] Fixed a bug that would cause
`Store.migrateStoreSnapshot` to mutate its `snapshot` argument.
This PR fixes a crash when rotating a deleted shapes, and adds a unit
test for it.
It also updates the docs of an editor method to communicate a current
limitation that we left a 'todo' for. See code comments for more info.
### Change Type
- [x] `patch` — Bug fix
[^1]: publishes a `patch` release, for devDependencies use `internal`
[^2]: will not publish a new version
### Test Plan
1. Get two devices out for this! (or write a little console script to do
it for you)
2. Rotate a shape on one device.
3. While rotating it, delete it on the other device.
4. Make sure the page doesn't crash!
- [x] Unit Tests
- [ ] End to end tests
### Release Notes
- Fixed a crash when trying to rotate a deleted shape.
