We rely on type inference for our `defaultX` types, as well as for our
shape prop types. This works well and means we only have to list shape
props once, but has some drawbacks:
- It's unstable, which sometimes produces unintended api-report.md diffs
that need to be worked around
- It's not good for docs
This diff makes those declared explicitly
### Change type
- [x] `api`
### Release notes
- Explicitly declare type types of default shapes etc. and shape props
for better documentation
Adds a custom shape bemo example. Instead of having to create a schema
ahead of time, here i've added bindingUtils/shapeUtils props to our sync
hooks to match the ones we have in the `<Tldraw />` component. Not 100%
about this though, I could easily be convinced to go with just the
schema prop.
### Change type
- [x] `other`
Different bundlers have different support for importing non-JS assets.
We can't reliably import SVGs in our public packages and rely on that to
do the right thing. When I tried installing a canary to work on a new
cloudflare template, vite was erroring out due to those imports. I had
to patch them out to get things running.
This diff replaces the file-based assets with inlined svg-in-js strings.
I haven't been able to test this though because I'm not really sure how.
@mimecuvalo could you take a look?
### Change type
- [x] `bugfix`
This PR accounts (in the UI) for a default case where the `colorScheme`
value is undefined.
### Change type
- [x] `bugfix`
### Test plan
1. Open the editor an incognito tab
2. The Menu > Preferences > Color scheme should have a ticked selection
### Release notes
- Fixed a bug where the user's color scheme was not shown in the menu by
default.
This PR:
- creates `Editor.run` (previously `Editor.batch`)
- deprecates `Editor.batch`
- introduces a `ignoreShapeLock` option top the `Editor.run` method that
allows the editor to update and delete locked shapes
- fixes a bug with `updateShapes` that allowed updating locked shapes
- fixes a bug with `ungroupShapes` that allowed ungrouping locked shapes
- makes `Editor.history` private
- adds `Editor.squashToMark`
- adds `Editor.clearHistory`
- removes `History.ignore`
- removes `History.onBatchComplete`
- makes `_updateCurrentPageState` private
```ts
editor.run(() => {
editor.updateShape({ ...myLockedShape })
editor.deleteShape(myLockedShape)
}, { ignoreShapeLock: true })
```
It also:
## How it works
Normally `updateShape`/`updateShapes` and `deleteShape`/`deleteShapes`
do not effect locked shapes.
```ts
const myLockedShape = editor.getShape(myShapeId)!
// no change from update
editor.updateShape({ ...myLockedShape, x: 100 })
expect(editor.getShape(myShapeId)).toMatchObject(myLockedShape)
// no change from delete
editor.deleteShapes([myLockedShape])
expect(editor.getShape(myShapeId)).toMatchObject(myLockedShape)
```
The new `run` method adds the option to ignore shape lock.
```ts
const myLockedShape = editor.getShape(myShapeId)!
// update works
editor.run(() => { editor.updateShape({ ...myLockedShape, x: 100 }) }, { ignoreShapeLock: true })
expect(editor.getShape(myShapeId)).toMatchObject({ ...myLockedShape, x: 100 })
// delete works
editor.run(() => { editor.deleteShapes([myLockedShape]), { ignoreShapeLock: true })
expect(editor.getShape(myShapeId)).toBeUndefined()
```
## History changes
This is a related but not entirely related change in this PR.
Previously, we had a few ways to run code that ignored the history.
- `editor.history.ignore(() => { ... })`
- `editor.batch(() => { ... }, { history: "ignore" })`
- `editor.history.batch(() => { ... }, { history: "ignore" })`
- `editor.updateCurrentPageState(() => { ... }, { history: "ignore" })`
We now have one way to run code that ignores history:
- `editor.run(() => { ... }, { history: "ignore" })`
## Design notes
We want a user to be able to update or delete locked shapes
programmatically.
### Callback vs. method options?
We could have added a `{ force: boolean }` property to the
`updateShapes` / `deleteShapes` methods, however there are places where
those methods are called from other methods (such as
`distributeShapes`). If we wanted to make these work, we would have also
had to provide a `force` option / bag to those methods.
Using a wrapper callback allows for "regular" tldraw editor code to work
while allowing for updates and deletes.
### Interaction logic?
We don't want this change to effect any of our interaction logic.
A lot of our interaction logic depends on identifying which shapes are
locked and which shapes aren't. For example, clicking on a locked shape
will go to the `pointing_canvas` state rather than the `pointing_shape`.
This PR has no effect on that part of the library.
It only effects the updateShapes and deleteShapes methods. As an example
of this, when `_force` is set to true by default, the only tests that
should fail are in `lockedShapes.test.ts`. The "user land" experience of
locked shapes is identical to what it is now.
### Change type
- [x] `bugfix`
- [ ] `improvement`
- [x] `feature`
- [x] `api`
- [ ] `other`
### Test plan
1. Create a shape
2. Lock it
3. From the console, update it
4. From the console, delete it
- [x] Unit tests
### Release notes
- SDK: Adds `Editor.force()` to permit updating / deleting locked shapes
- Fixed a bug that would allow locked shapes to be updated
programmatically
- Fixed a bug that would allow locked group shapes to be ungrouped
programmatically
---------
Co-authored-by: alex <alex@dytry.ch>
The backend code uses `@tldraw/state`, which is fine, but the package
has a peer dependency on `react`, which is not fine to impose on backend
consumers. So let's split this up again.
### Change type
- [ ] `bugfix`
- [ ] `improvement`
- [ ] `feature`
- [x] `api`
- [x] `other`
### Test plan
1. Create a shape...
2.
- [ ] Unit tests
- [ ] End to end tests
### Release notes
- Fixed a bug with…
closes#4085
Neither of these should be too valuable for tldraw users, but they're
also both totally stable and well documented (now) so it should be fine
to make them public?
### Change type
- [ ] `bugfix`
- [ ] `improvement`
- [ ] `feature`
- [x] `api`
- [ ] `other`
### Test plan
1. Create a shape...
2.
- [ ] Unit tests
- [ ] End to end tests
### Release notes
- Made `EffectScheduler` and `useStateTracking` public
Unify the VS Code extension menus with what we have on dot com. Prevent
an error cycle.
### Change type
- [ ] `bugfix`
- [x] `improvement`
- [ ] `feature`
- [ ] `api`
- [ ] `other`
### Release notes
- Unify the VS Code extension menus (Help and Main menus) with what we
have on tldraw.com
- Prevent an onerror cycle.
two changes in one here because I'm feeling lazy
- fix bug in staging, introduced in whichever bemo PR refactored the
sync client+indexeddb stuff
1. go to `/`
2. file -> new shared project
3. oh_no.jpg
<img width="618" alt="image"
src="https://github.com/tldraw/tldraw/assets/1242537/8bff3498-2cc5-4c71-b407-830d459d3d36">
- fix bug in production
1. make a new room
2. clear localstorage
3. refresh
4. duplicate current tab in same browser context
6. oh_no.jpg (there should only be one person)
<img width="99" alt="image"
src="https://github.com/tldraw/tldraw/assets/1242537/f4e434ba-8455-4913-a698-71661e5074fd">
### Change type
- [x] `bugfix`
- [ ] `improvement`
- [ ] `feature`
- [ ] `api`
- [ ] `other`
### Test plan
1. Create a shape...
8.
- [ ] Unit tests
- [ ] End to end tests
### Release notes
- Fixed a bug with…
For non-commercial usage of tldraw, this adds a watermark in the corner,
both for branding purposes and as an incentive for our enterprise
customers to purchase a license.
For commercial usage of tldraw, you add a license to the `<Tldraw
licenseKey={YOUR_LICENSE_KEY} />` component so that the watermark
doesn't show.
The license is a signed key that has various bits of information in it,
such as:
- license type
- hosts that the license is valid for
- whether it's an internal-only license
- expiry date
We check the license on load and show a watermark (or throw an error if
internal-only) if the license is not valid in a production environment.
This is a @MitjaBezensek, @Taha-Hassan-Git, @mimecuvalo joint
production! 🤜🤛
### 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
- [x] `feature` — New feature
- [ ] `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. We will be dogfooding on staging.tldraw.com and tldraw.com itself
before releasing this.
### Release Notes
- SDK: wires up tldraw to have licensing mechanisms.
---------
Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com>
Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com>
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
Adds a new `multiplayerStatus` store prop. This can either be `null`
(indicating this isn't a multiplayer store) or a signal containing
`online` or `offline` indicating that it is. We move a bunch of
previously dotcom specific UI into `tldraw` and use this new prop to
turn it on or off by default.
closes TLD-2611
### Change type
- [x] `improvement`
Adds a new `onEditorMount` callback to the store, allowing store
creators to do things like registering bookmark handlers. We use this in
the new demo hook.
This also renames `useRemoteSyncClient` to `useMultiplayerSync`, and
`useRemoteSyncDemo` to `useMultiplayerDemo`.
Closes TLD-2601
### Change type
- [x] `api`
Reworks the store to include information about how blob assets
(images/videos) are stored/retrieved. This replaces the old
internal-only `assetOptions` prop, and supplements the existing
`registerExternalAssetHandler` API.
Previously, `registerExternalAssetHandler` had two responsibilities:
1. Extracting asset metadata
2. Uploading the asset and returning its URL
Existing `registerExternalAssetHandler` implementation will still work,
but now uploading is the responsibility of a new `editor.uploadAsset`
method which calls the new store-based upload method. Our default asset
handlers extract metadata, then call that new API. I think this is a
pretty big improvement over what we had before: overriding uploads was a
pretty common ask, but doing so meant having to copy paste our metadata
extraction which felt pretty fragile. Just in this codebase, we had a
bunch of very slightly different metadata extraction code-paths that had
been copy-pasted around then diverged over time. Now, you can change how
uploads work without having to mess with metadata extraction and
vice-versa.
As part of this we also:
1. merge the old separate asset indexeddb store with the main one.
because this warrants some pretty big migration stuff, i refactored our
indexed-db helpers to work around an instance instead of being free
functions
2. move our existing asset stuff over to the new approach
3. add a new hook in `sync-react` to create a demo store with the new
assets
### Change type
- [x] `api`
### Release notes
Introduce a new `assets` option for the store, describing how to save
and retrieve asset blobs like images & videos from e.g. a user-content
CDN. These are accessible through `editor.uploadAsset` and
`editor.resolveAssetUrl`. This supplements the existing
`registerExternalAssetHandler` API: `registerExternalAssetHandler` is
for customising metadata extraction, and should call
`editor.uploadAsset` to save assets. Existing
`registerExternalAssetHandler` calls will still work, but if you're only
using them to configure uploads and don't want to customise metadata
extraction, consider switching to the new `assets` store prop.
Previously, we had a single hard-coded DOM ID for grids. This meant that
if you had multiple editors with grids on a page, they would all point
at the svg `<defs>` from the first instance. Now, each grid generates a
unique ID.
### Change type
- [x] `bugfix`
### Release notes
- Fix a bug causing multiple tldraw instances to share the same grid
background
This PR adds the ability to flip images.
### Change type
- [x] `improvement`
### Test plan
1. Resize an image shape
2. Select an image shape and use the flip X / flip Y options in the
context menu.
- [x] Unit tests
### Release notes
- Adds the ability to flip images.
This PR fixes the paste at point logic.
### Change type
- [x] `bugfix`
### Test plan
1. copy, paste (in original position)
2. hold shift to paste at cursor
3. turn on paste at cursor mode
4. copy, paste (at cursor)
5. hold shift to paste in original position
Add an option to make paste at cursor the default.
Not sure if we also want to expose this on tldraw.com? For now I did,
but happy to remove if we'd want to keep the preferences simple.
We could also add this to the `TldrawOptions`, but it felt like some
apps might actually allow this customization on a per user level.
Solves https://github.com/tldraw/tldraw/issues/4066
### Change type
- [ ] `bugfix`
- [ ] `improvement`
- [x] `feature`
- [ ] `api`
- [ ] `other`
### Test plan
1. Copy / pasting should still work as it works now: `⌘ + v` pastes on
top of the shape, `⌘ + ⇧ + v` pastes at cursor.
2. There's now a new option under Preferences to paste at cursor. This
just swaps the logic between the two shortcuts: `⌘ + v` then pastes at
cursor and `⌘ + ⇧ + v` pastes on top of the shape.
### Release notes
- Allow users and sdk users to make pasting at the cursor a default
instead of only being available with `⌘ + ⇧ + v`.
Currently, the editor gets recreated whenever the camera options (or
several other props that are only relevant at initialisation time) get
changed.
This diff makes it so that:
- init-only props are kept in a ref so they don't invalidate the editor
(but are used when the editor _does_ get recreated)
- camera options are kept up to date in a separate effect
### Change type
- [x] `bugfix`
### Release notes
Fix an issue where changing `cameraOptions` via react would cause the
entire editor to re-render
This PR adds a component for `ShapeIndicators` to the UI component
overrides. It moves the "select tool" state logic up to the new
`TldrawShapeIndicators` component.
### Change type
- [ ] `bugfix`
- [x] `improvement`
- [ ] `feature`
- [x] `api`
- [ ] `other`
### Release notes
- Added new `ShapeIndicators` component to `components` object.
- Added new `TldrawShapeIndicators` component.
this PR puts sync stuff in the bemo worker, and sets up a temporary
dev-only page in dotcom for testing bemo stuff
### Change type
- [ ] `bugfix`
- [ ] `improvement`
- [x] `feature`
- [ ] `api`
- [ ] `other`
### Test plan
1. Create a shape...
2.
- [ ] Unit tests
- [ ] End to end tests
### Release notes
- Fixed a bug with...
This PR:
- simplifies a lot of z-index layers
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `bugfix` — Bug fix
### Release Notes
- Cleans up z-indexes and removes some unused CSS.
This PR:
- fixes the placement of the InFrontOfTheCanvas component
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `bugfix` — Bug fix
### Release Notes
- Fixed placement of the InFrontOfTheCanvas component.
Not the prettiest way to do this, but meh. This is what we talked about
offline @SomeHats
### 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 ❗️ -->
- [x] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `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
Simplify the types used by the props of the `Tldraw` and `TldrawEditor`
components. This doesn't make the docs perfect, but it makes them quite
a bit better than they were.
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `improvement` — Improving existing features
React's strict mode runs effects twice on mount, but once it's done that
it'll go forward with the state from the first effect. For example, this
component:
```tsx
let nextId = 1
function Component() {
const [state, setState] = useState(null)
useEffect(() => {
const id = nextId++
console.log('set up', id)
setState(id)
return () => console.log('tear down', id)
}, [])
if (!state) return
console.log('render', state)
}
```
Would log something like this when mounting for the first time:
- `set up 1`
- `tear down 1`
- `set up 2`
- `render 1`
For us, this is a problem: editor 2 is the version that's still running,
but editor 1 is getting used for render. React talks a bit about this
issue here: https://github.com/reactwg/react-18/discussions/19
The fix seems to be to keep the editor in a `useRef` instead of a
`useState`. We need the state to trigger re-renders though, so we sync
the ref into the state although we don't actually use the state value.
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `bugfix` — Bug fix
### Release Notes
- Fix a bug causing text shape measurement to work incorrectly when
using react strict mode
bad hook deps was causing the wrong presence record to be returned when
switching between following users.
### 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 ❗️ -->
- [x] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `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. 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.
If you zoom in at 110% or more, edge scrolling was not working on the
bottom and right edges. That's because we were setting insets using
exact comparison when the document.body.scrollWidth/Height values were
slightly off integers.
### 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 ❗️ -->
- [x] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `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. 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.
Our reference docs don't currently include members inherited through the
`extends` keyword. These extended items are barely referenced at all -
you have to find them in the signature.
This diff adds a clearer note to the docs saying which type has been
extended, and if possible brings the extended items through onto the
current documentation page (with a note saying where they're from)
### Change Type
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `improvement` — Improving existing features
Allow the users to fully use the same colour scheme as their system.
Allows the users to either: force dark colour scheme, force light colour
scheme, or use the system one.
It's reactive to the system changes.
https://github.com/tldraw/tldraw/assets/2523721/6d4cef03-9ef0-4098-b299-6bf5d7513e98
### 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
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.
---------
Co-authored-by: David Sheldrick <d.j.sheldrick@gmail.com>
This PR:
- moves the edge scrolling logic into a manager
- adds a new Editor option for `edgeScrollDelay`
- adds a new Editor option for `edgeScrollEaseDuration`
When in a state that would trigger an edge scroll, a delay is added
before the scrolling starts. When scrolling does start, it is eased in
by a certain duration.
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `improvement` — Improving existing features
### Test Plan
1. Drag shapes, resize, or drag select to the edge of the screen
2. The screen should move
- [x] Unit Tests
### Release Notes
- Add a delay and easing to edge scrolling.
---------
Co-authored-by: Mitja Bezenšek <mitja.bezensek@gmail.com>
This PR adds a user preference for "dynamic size mode" where the scale
of shapes (text size, stroke width) is relative to the current zoom
level. This means that the stroke width in screen pixels (or text size
in screen pixels) is identical regardless of zoom level.
- [x] Draw shape
- [x] Text shape
- [x] Highlighter shape
- [x] Geo shape
- [x] Arrow shape
- [x] Note shape
- [x] Line shape
Embed shape?
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `feature` — New feature
### Test Plan
1. Use the tools.
2. Change zoom
- [ ] Unit Tests
### Release Notes
- Adds a dynamic size user preferences.
- Removes double click to reset scale on text shapes.
- Removes double click to reset autosize on text shapes.
---------
Co-authored-by: Taha <98838967+Taha-Hassan-Git@users.noreply.github.com>
Co-authored-by: huppy-bot[bot] <128400622+huppy-bot[bot]@users.noreply.github.com>
Looking at the waterfall of fonts/images/etc. we wanted the "Loading
assets..." bit to commence earlier so it's not fighting for bandwidth
with the icons loading all at the same time.
This writes to the index.html file to start preloading the fonts we
need.
### 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
### Release Notes
- Perf: improve font loading timing on dotcom.
---------
Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
I originally didn't want to add these methods to the Editor class, to
avoid muddying the API with multiple ways to do one thing, but I've
found myself reaching for these on a number of occasions so I think
maybe it would be better to have them?
### 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
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 functionality for turning shapes into images.
It adds:
- the `flattenShapesToImages`
- the `useFlatten` hook
- a `flatten-shapes-to-images` action (shift + f)
- adds `flattenImageBoundsExpand` option
- adds `flattenImageBoundsPadding` option
## Flatten shapes to images
The `flattenShapesToImages` helper method will 1) create an image for
the given shape ids, 2) add it to the canvas in the same location / size
as the source shapes, and then 3) delete the original shapes. The new
image will be placed correctly in the z index and in the correct
rotation of the root-most ancestor of the given shape ids.
It has an argument, `flattenImageBoundsExpand`, which if provided will
chunk the given shapes into images based on their overlapping (expanded)
bounding boxes.
By default, the flatten action uses the editor's
`options.flattenImageBoundsExpand`. The `flattenImageBoundsPadding`
option is used as a value for how much larger the image should be than
the source image bounds (to account for large strokes, for example).
### Change Type
- [x] `sdk` — Changes the tldraw SDK
- [x] `feature` — New feature
### Test Plan
1. Select shapes
2. Select context menu > edit > flatten
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Add Flatten, a new menu item to flatten shapes into images
this is take #2 of this PR https://github.com/tldraw/tldraw/pull/3745
As I look at LOD holistically and whether we have multiple sources when
working locally, I learned that our system used base64 encoding of
assets directly. Issue https://github.com/tldraw/tldraw/issues/3728
<img width="1350" alt="assetstore"
src="https://github.com/tldraw/tldraw/assets/469604/e7b41e29-6656-4d9b-b462-72d43b98f3f7">
The motivations and benefits are:
- store size: not having a huge base64 blobs injected in room data
- perf on loading snapshot: this helps with loading the room data more
quickly
- multiple sources: furthermore, if we do decide to have multiple
sources locally (for each asset), then we won't get a multiplicative
effect of even larger JSON blobs that have lots of base64 data in them
- encoding/decoding perf: this also saves the (slow) step of having to
base64 encode/decode our assets, we can just strictly with work with
blobs.
Todo:
- [x] decodes video and images
- [x] make sure it syncs to other tabs
- [x] make sure it syncs to other multiplayer room
- [x] fix tests
### 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
1. Test the shit out of uploading/downloading video/image assets,
locally+multiplayer.
- [ ] Need to fix current tests and write new ones
### Release Notes
- Assets: store as reference to blob in indexedDB instead of storing
directly as base64 in the snapshot.
couple fixes and improvements for the LOD work.
- add `format=auto` for Cloudflare to send back more modern image
formats
- fix the broken asset logic that regressed (should not have looked at
`url`)
- fix stray parenthesis, omg
- rm the `useValueDebounced` function in lieu of just debouncing the
resolver. the problem was that the initial load in a multiplayer room
has a zoom of 1 but then the real zoom comes in (via the url) and so we
would double load all images 😬. this switches the debouncing to the
resolving stage, not making it tied to the zoom specifically.
### 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 ❗️ -->
- [x] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `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
Before:
After:
React components in docs now list their props, and appear under a new
"Component" section instead of randomly under either `Function` or
`Variable`. In order to have our docs generate this, a few criteria need
to be met:
1. They need to be tagged with the `@react` tsdoc tag
2. Their props need to be a simple type alias, typically to an
interface.
Both of these rules are enforced with a new lint rule - any component
tagged as `@public` will have these rules enforced.
### Change Type
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `improvement` — Improving existing features
this is take #2 of this PR https://github.com/tldraw/tldraw/pull/3764
This continues the idea kicked off in
https://github.com/tldraw/tldraw/pull/3684 to explore LOD and takes it
in a different direction.
Several things here to call out:
- our dotcom version would start to use Cloudflare's image transforms
- we don't rewrite non-image assets
- we debounce zooming so that we're not swapping out images while
zooming (it creates jank)
- we load different images based on steps of .25 (maybe we want to make
this more, like 0.33). Feels like 0.5 might be a bit too much but we can
play around with it.
- we take into account network connection speed. if you're on 3g, for
example, we have the size of the image.
- dpr is taken into account - in our case, Cloudflare handles it. But if
it wasn't Cloudflare, we could add it to our width equation.
- we use Cloudflare's `fit=scale-down` setting to never scale _up_ an
image.
- we don't swap the image in until we've finished loading it
programatically (to avoid a blank image while it loads)
TODO
- [x] We need to enable Cloudflare's pricing on image transforms btw
@steveruizok 😉 - this won't work quite yet until we do that.
### 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
- [x] `feature` — New feature
- [ ] `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. Test images on staging, small, medium, large, mega
2. Test videos on staging
- [x] Unit Tests
- [ ] End to end tests
### Release Notes
- Assets: make option to transform urls dynamically to provide different
sized images on demand.
followup to https://github.com/tldraw/tldraw/pull/3881 to enforce this
in the codebase
Describe what your pull request does. If appropriate, add GIFs or images
showing the before and after.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [x] `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
This PR aims to improve the UX around undo/redo and cropping. Before the
PR if you do some cropping, then stop cropping, then hit `undo`, you
will end up back in the cropping state and it will undo each of your
resize/translate cropping operations individually. This is weird 🙅🏼 It
should just undo the whole sequence of changes that happened during
cropping.
To achieve that, this PR introduces a new history method called
`squashToMark`, which strips out all the marks between the current head
of the undo stack and the mark id you pass in.
This PR also makes the default history record mode of
`updateCurrentPageState` to `ignore` like it already was for
`updateInstanceState`. The fact that it was recording changes to the
`croppingShapeId` was the reason that hitting undo would put you back
into the cropping state.
### 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
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.
wip
### 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
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [x] `tests` — Changes to any test code
- [ ] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### 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.
Previously, we had the `ae-forgotten-export` rule from api-extractor
disabled. This rule makes sure that everything that's referred to in the
public API is actually exported. There are more details on the rule
[here](https://api-extractor.com/pages/messages/ae-forgotten-export/),
but not exporting public API entires is bad because they're hard to
document and can't be typed/called from consumer code. For us, the big
effect is that they don't appear in our docs at all.
This diff re-enables that rule. Now, if you introduce something new to
the public API but don't export it, your build will fail.
### Change Type
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `improvement` — Improving existing features
