This PR shrinks the commands API surface and adds a manager
(`CleanupManager`) for side effects.
### Change Type
- [x] `major` — Breaking change
### Test Plan
Use the app! Especially undo and redo. Our tests are passing but I've
found more cases where our coverage fails to catch issues.
### Release Notes
- tbd
This PR adds val town to tldraw's collection of embeddable things.
### Change Type
- [x] `minor` — New feature
### Test Plan
1. Add links to val town, e.g.
https://www.val.town/v/steveruizok.mathFact
### Release Notes
- (feature) val town
This PR fixes the extra outlines on text shapes when not editing those
shapes.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Create two text shapes
2. Edit one of them
3. The outline on the second shape should not be shown
This PR exports the `UiEventsProvider` component (and renames
`useEvents` to `useUiEvents`). It also changes the `useUiEvents` hook to
work outside of the context. When used outside of the context, the hook
will no longer throw an error—though it will also have no effect.
### Change Type
- [x] `minor`
### Release Notes
- [@tldraw/tldraw] export ui events, so that UI hooks can work without
context
These shapes no longer use perfect freehand for their rendering, so we
can drop the effect of `useForceSolid` for them.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Zoom out
2. Draw style draw shapes should not change
### Release Notes
- Remove the force solid switching for geo / line shapes
This PR makes it so that locked shapes do not show an indicator when
hovered.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Hover a locked shape
2. Hover a shape, then lock it
### Release Notes
- locked shapes do not show an indicator when hovered
This PR fixes a bug that was introduced (by me) in #1751, where:
- the `commonBoundsOfAllShapesOnCurrentPage` would mutate the first
bounding box
- the render reactor would fire too often
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Use the minimap
This PR removes `Editor.selectionPageCenter` and moves its
implementation inline where used (in two places).
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [dev] Removes `Editor.selectionPageCenter`
This PR fixes a bug introduced with #1751 where pointing the bounds of
rotated selections would not correctly hit the bounds background.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Create a rotated selection.
2. Point into the bounds background
- [x] Unit Tests
This PR removes the indexes from `parentsToChildrenWithIndexes`. The
indexes weren't needed except for in one place, where a `getShape` was
easier.
### Change Type
- [x] `minor` — New feature
This PR fixes some GREP-introduced errors to the old structure of legacy
v1 documents.
### Change Type
- [x] `patch` — Bug fix
### Test Plan
1. Open a V1 document.
This PR is a significant rewrite of our selection / hit testing logic.
It
- replaces our current geometric helpers (`getBounds`, `getOutline`,
`hitTestPoint`, and `hitTestLineSegment`) with a new geometry API
- moves our hit testing entirely to JS using geometry
- improves selection logic, especially around editing shapes, groups and
frames
- fixes many minor selection bugs (e.g. shapes behind frames)
- removes hit-testing DOM elements from ShapeFill etc.
- adds many new tests around selection
- adds new tests around selection
- makes several superficial changes to surface editor APIs
This PR is hard to evaluate. The `selection-omnibus` test suite is
intended to describe all of the selection behavior, however all existing
tests are also either here preserved and passing or (in a few cases
around editing shapes) are modified to reflect the new behavior.
## Geometry
All `ShapeUtils` implement `getGeometry`, which returns a single
geometry primitive (`Geometry2d`). For example:
```ts
class BoxyShapeUtil {
getGeometry(shape: BoxyShape) {
return new Rectangle2d({
width: shape.props.width,
height: shape.props.height,
isFilled: true,
margin: shape.props.strokeWidth
})
}
}
```
This geometric primitive is used for all bounds calculation, hit
testing, intersection with arrows, etc.
There are several geometric primitives that extend `Geometry2d`:
- `Arc2d`
- `Circle2d`
- `CubicBezier2d`
- `CubicSpline2d`
- `Edge2d`
- `Ellipse2d`
- `Group2d`
- `Polygon2d`
- `Rectangle2d`
- `Stadium2d`
For shapes that have more complicated geometric representations, such as
an arrow with a label, the `Group2d` can accept other primitives as its
children.
## Hit testing
Previously, we did all hit testing via events set on shapes and other
elements. In this PR, I've replaced those hit tests with our own
calculation for hit tests in JavaScript. This removed the need for many
DOM elements, such as hit test area borders and fills which only existed
to trigger pointer events.
## Selection
We now support selecting "hollow" shapes by clicking inside of them.
This involves a lot of new logic but it should work intuitively. See
`Editor.getShapeAtPoint` for the (thoroughly commented) implementation.
every sunset is actually the sun hiding in fear and respect of tldraw's
quality of interactions
This PR also fixes several bugs with scribble selection, in particular
around the shift key modifier.
...as well as issues with labels and editing.
There are **over 100 new tests** for selection covering groups, frames,
brushing, scribbling, hovering, and editing. I'll add a few more before
I feel comfortable merging this PR.
## Arrow binding
Using the same "hollow shape" logic as selection, arrow binding is
significantly improved.
a thousand wise men could not improve on this
## Moving focus between editing shapes
Previously, this was handled in the `editing_shapes` state. This is
moved to `useEditableText`, and should generally be considered an
advanced implementation detail on a shape-by-shape basis. This addresses
a bug that I'd never noticed before, but which can be reproduced by
selecting an shape—but not focusing its input—while editing a different
shape. Previously, the new shape became the editing shape but its input
did not focus.
In this PR, you can select a shape by clicking on its edge or body, or
select its input to transfer editing / focus.
tldraw, glorious tldraw
### Change Type
- [x] `major` — Breaking change
### Test Plan
1. Erase shapes
2. Select shapes
3. Calculate their bounding boxes
- [ ] Unit Tests // todo
- [ ] End to end tests // todo
### Release Notes
- [editor] Remove `ShapeUtil.getBounds`, `ShapeUtil.getOutline`,
`ShapeUtil.hitTestPoint`, `ShapeUtil.hitTestLineSegment`
- [editor] Add `ShapeUtil.getGeometry`
- [editor] Add `Editor.getShapeGeometry`
<img width="1372" alt="image"
src="https://github.com/tldraw/tldraw/assets/7578559/5d5f29fa-a3d7-488b-a4fe-25673d94134e">
This should be tldraw version instead of react version, the typo
happened here:
b7d9c8684c (diff-feb0a5bdada68de6bf60ae3fd8b83915d234dc78f56cae91f33e5c209ad3bf0a).
### 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
### Release Notes
- Fixed asset urls
This PR fixes snapping for arrow shapes. Previously, the middle handle
of an arrow was marked as a vertex, causing the arrow to have to
segments (one of which would be snapped to). In this PR we make the
second handle a "virtual" handle and tweak how we display handles to
preserve the same appearance.
### Change Type
- [x] `minor` — New feature
### Test Plan
1. Drag an arrow while snapping.
### Release Notes
- [fix] arrow snapping
This PR fixes a bug where dark mode would not immediately cause shapes
to update their colors. Previously, we got the current theme during
render but not in a way that hooked into the change. In this update, we
hook into the change. We also pass the change down to shape fills as
props rather than getting the theme from deeper down.
### Change Type
- [x] `patch`
### Test Plan
1. Use dark mode.
2. Switch colors
### Release Notes
- [fix] dark mode colors not updating
This PR is another grab bag:
- renames `readOnly` to `readonly` throughout editor
- fixes a regression related to focus and keyboard shortcuts
- adds a small outline for focused editors
### Change Type
- [x] `major`
### Test Plan
- [x] End to end tests
Fix minor typo error in shapeType declaration
**Change Type**
- [x] `patch`
**Test Plan**
- [x] Unit Tests
- [ ] End to end tests
**Release Notes**
Fix typo
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
This PR fixes a failing end to end test that snuck in.
### Change Type
- [x] `tests` — Changes to any test code only[^2]
### Test Plan
- [x] End to end tests
This PR removes several extraneous computed values from the editor. It
adds some silly instance state onto the instance state record and
unifies a few methods which were inconsistent. This is fit and finish
work 🧽
## Computed Values
In general, where once we had a getter and setter for `isBlahMode`,
which really masked either an `_isBlahMode` atom on the editor or
`instanceState.isBlahMode`, these are merged into `instanceState`; they
can be accessed / updated via `editor.instanceState` /
`editor.updateInstanceState`.
## tldraw select tool specific things
This PR also removes some tldraw specific state checks and creates new
component overrides to allow us to include them in tldraw/tldraw.
### Change Type
- [x] `major` — Breaking change
### Test Plan
- [x] Unit Tests
- [x] End to end tests
### Release Notes
- [tldraw] rename `useReadonly` to `useReadOnly`
- [editor] remove `Editor.isDarkMode`
- [editor] remove `Editor.isChangingStyle`
- [editor] remove `Editor.isCoarsePointer`
- [editor] remove `Editor.isDarkMode`
- [editor] remove `Editor.isFocused`
- [editor] remove `Editor.isGridMode`
- [editor] remove `Editor.isPenMode`
- [editor] remove `Editor.isReadOnly`
- [editor] remove `Editor.isSnapMode`
- [editor] remove `Editor.isToolLocked`
- [editor] remove `Editor.locale`
- [editor] rename `Editor.pageState` to `Editor.currentPageState`
- [editor] add `Editor.pageStates`
- [editor] add `Editor.setErasingIds`
- [editor] add `Editor.setEditingId`
- [editor] add several new component overrides
This PR adds a bunch of brain-dump content onto the Shapes docs page.
There's more to add, but I'm submitting what I've done so far.
The main addition is explaining the concept of 'shapes' outside of the
context of creating a custom shape. I think it's good to do the basics
before getting into the world of custom stuff.
Note: I've also moved the Meta section from the Editor page to the
Shapes page.
### 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: Added more info about shapes.
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Escape the eraser tool on pressing the escape key.
(note that the same bug exists for the laser tool, i'm not sure if the
escape key behaviour should be the same for it too)
Fixes#1731
### 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. Select eraser tool
2. Press [escape], you should be back in the select tool
3. Select eraser tool, and start dragging around and press [escape], the
behaviour should be same as before
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- escape eraser tool on escape
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
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.
