2023-04-25 11:01:25 +00:00
|
|
|
/* eslint-disable @typescript-eslint/no-unused-vars */
|
2023-06-15 14:36:46 +00:00
|
|
|
import { Box2d, linesIntersect, Vec2d, VecLike } from '@tldraw/primitives'
|
2023-06-16 10:33:47 +00:00
|
|
|
import { StyleProp, TLHandle, TLShape, TLShapePartial, TLUnknownShape } from '@tldraw/tlschema'
|
2023-06-02 15:21:45 +00:00
|
|
|
import type { Editor } from '../Editor'
|
2023-04-25 11:01:25 +00:00
|
|
|
import { TLResizeHandle } from '../types/selection-types'
|
|
|
|
import { TLExportColors } from './shared/TLExportColors'
|
|
|
|
|
|
|
|
/** @public */
|
|
|
|
export interface TLShapeUtilConstructor<
|
|
|
|
T extends TLUnknownShape,
|
2023-06-04 10:38:53 +00:00
|
|
|
U extends ShapeUtil<T> = ShapeUtil<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
> {
|
2023-06-16 10:33:47 +00:00
|
|
|
new (editor: Editor, type: T['type'], styleProps: ReadonlyMap<StyleProp<unknown>, string>): U
|
[refactor] User-facing APIs (#1478)
This PR updates our user-facing APIs for the Tldraw and TldrawEditor
components, as well as the Editor (App). It mainly incorporates surface
changes from #1450 without any changes to validators or migrators,
incorporating feedback / discussion with @SomeHats and @ds300.
Here we:
- remove the TldrawEditorConfig
- bring back a loose version of shape definitions
- make a separation between "core" shapes and "default" shapes
- do not allow custom shapes, migrators or validators to overwrite core
shapes
- but _do_ allow new shapes
## `<Tldraw>` component
In this PR, the `Tldraw` component wraps both the `TldrawEditor`
component and our `TldrawUi` component. It accepts a union of props for
both components. Previously, this component also added local syncing via
a `useLocalSyncClient` hook call, however that has been pushed down to
the `TldrawEditor` component.
## `<TldrawEditor>` component
The `TldrawEditor` component now more neatly wraps up the different ways
that the editor can be configured.
## The store prop (`TldrawEditorProps.store`)
There are three main ways for the `TldrawEditor` component to be run:
1. with an externally defined store
2. with an externally defined syncing store (local or remote)
3. with an internally defined store
4. with an internally defined locally syncing store
The `store` prop allows for these configurations.
If the `store` prop is defined, it may be defined either as a `TLStore`
or as a `SyncedStore`. If the store is a `TLStore`, then the Editor will
assume that the store is ready to go; if it is defined as a SyncedStore,
then the component will display the loading / error screens as needed,
or the final editor once the store's status is "synced".
When the store is left undefined, then the `TldrawEditor` will create
its own internal store using the optional `instanceId`, `initialData`,
or `shapes` props to define the store / store schema.
If the `persistenceKey` prop is left undefined, then the store will not
be synced. If the `persistenceKey` is defined, then the store will be
synced locally. In the future, we may also here accept the API key /
roomId / etc for creating a remotely synced store.
The `SyncedStore` type has been expanded to also include types used for
remote syncing, e.g. with `ConnectionStatus`.
## Tools
By default, the App has two "baked-in" tools: the select tool and the
zoom tool. These cannot (for now) be replaced or removed. The default
tools are used by default, but may be replaced by other tools if
provided.
## Shapes
By default, the App has a set of "core" shapes:
- group
- embed
- bookmark
- image
- video
- text
That cannot by overwritten because they're created by the app at
different moments, such as when double clicking on the canvas or via a
copy and paste event. In follow up PRs, we'll split these out so that
users can replace parts of the code where these shapes are created.
### Change Type
- [x] `major` — Breaking Change
### Test Plan
- [x] Unit Tests
2023-06-01 15:47:34 +00:00
|
|
|
type: T['type']
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/** @public */
|
|
|
|
export type TLShapeUtilFlag<T> = (shape: T) => boolean
|
|
|
|
|
|
|
|
/** @public */
|
2023-06-16 10:33:47 +00:00
|
|
|
export abstract class ShapeUtil<Shape extends TLUnknownShape = TLUnknownShape> {
|
|
|
|
constructor(
|
|
|
|
public editor: Editor,
|
|
|
|
public readonly type: Shape['type'],
|
|
|
|
public readonly styleProps: ReadonlyMap<StyleProp<unknown>, string>
|
|
|
|
) {}
|
|
|
|
|
|
|
|
hasStyle(style: StyleProp<unknown>) {
|
|
|
|
return this.styleProps.has(style)
|
|
|
|
}
|
|
|
|
|
|
|
|
getStyleIfExists<T>(style: StyleProp<T>, shape: Shape | TLShapePartial<Shape>): T | undefined {
|
|
|
|
const styleKey = this.styleProps.get(style)
|
|
|
|
if (!styleKey) return undefined
|
|
|
|
return (shape.props as any)[styleKey]
|
|
|
|
}
|
|
|
|
|
|
|
|
*iterateStyles(shape: Shape | TLShapePartial<Shape>) {
|
|
|
|
for (const [style, styleKey] of this.styleProps) {
|
|
|
|
const value = (shape.props as any)[styleKey]
|
|
|
|
yield [style, value] as [StyleProp<unknown>, unknown]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
setStyleInPartial<T>(
|
|
|
|
style: StyleProp<T>,
|
|
|
|
shape: TLShapePartial<Shape>,
|
|
|
|
value: T
|
|
|
|
): TLShapePartial<Shape> {
|
|
|
|
const styleKey = this.styleProps.get(style)
|
|
|
|
if (!styleKey) return shape
|
|
|
|
return {
|
|
|
|
...shape,
|
|
|
|
props: {
|
|
|
|
...shape.props,
|
|
|
|
[styleKey]: value,
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
2023-06-05 14:49:44 +00:00
|
|
|
* The type of the shape util, which should match the shape's type.
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-05 14:49:44 +00:00
|
|
|
static type: string
|
2023-04-25 11:01:25 +00:00
|
|
|
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
/**
|
|
|
|
* Get the default props for a shape.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
abstract getDefaultProps(): Shape['props']
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a JSX element for the shape (as an HTML element).
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
abstract component(shape: Shape): any
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get JSX describing the shape's indicator (as an SVG element).
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
abstract indicator(shape: Shape): any
|
|
|
|
|
2023-06-15 14:36:46 +00:00
|
|
|
/**
|
|
|
|
* Whether the shape can be snapped to by another shape.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canSnap: TLShapeUtilFlag<Shape> = () => true
|
2023-06-15 14:36:46 +00:00
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/**
|
|
|
|
* Whether the shape can be scrolled while editing.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canScroll: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
2023-06-05 14:49:44 +00:00
|
|
|
* Whether the shape should unmount when not visible in the editor. Consider keeping this to false if the shape's `component` has local state.
|
2023-04-25 11:01:25 +00:00
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canUnmount: TLShapeUtilFlag<Shape> = () => true
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape can be bound to by an arrow.
|
|
|
|
*
|
|
|
|
* @param _otherShape - The other shape attempting to bind to this shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canBind = <K>(_shape: Shape, _otherShape?: K) => true
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape can be double clicked to edit.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canEdit: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape can be resized.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canResize: TLShapeUtilFlag<Shape> = () => true
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape can be cropped.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canCrop: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
* Does this shape provide a background for its children? If this is true,
|
|
|
|
* then any children with a `renderBackground` method will have their
|
|
|
|
* backgrounds rendered _above_ this shape. Otherwise, the children's
|
|
|
|
* backgrounds will be rendered above either the next ancestor that provides
|
|
|
|
* a background, or the canvas background.
|
2023-04-25 11:01:25 +00:00
|
|
|
*
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
* @internal
|
2023-04-25 11:01:25 +00:00
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
providesBackgroundForChildren(shape: Shape): boolean {
|
|
|
|
return false
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape's outline is closed.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
isClosed: TLShapeUtilFlag<Shape> = () => true
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape should hide its resize handles when selected.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hideResizeHandles: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape should hide its resize handles when selected.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hideRotateHandle: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape should hide its selection bounds background when selected.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hideSelectionBoundsBg: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape should hide its selection bounds foreground when selected.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hideSelectionBoundsFg: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether the shape's aspect ratio is locked.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
isAspectRatioLocked: TLShapeUtilFlag<Shape> = () => false
|
2023-04-25 11:01:25 +00:00
|
|
|
|
2023-06-01 15:22:47 +00:00
|
|
|
/**
|
|
|
|
* Get a JSX element for the shape (as an HTML element) to be rendered as part of the canvas background - behind any other shape content.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @internal
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
backgroundComponent?(shape: Shape): any
|
2023-06-01 15:22:47 +00:00
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/**
|
|
|
|
* Get an array of handle models for the shape. This is an optional method.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
*
|
|
|
|
* ```ts
|
|
|
|
* util.getHandles?.(myShape)
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
getHandles?(shape: Shape): TLHandle[]
|
2023-04-25 11:01:25 +00:00
|
|
|
|
2023-06-15 14:36:46 +00:00
|
|
|
/**
|
|
|
|
* Get an array of outline segments for the shape. For most shapes,
|
|
|
|
* this will be a single segment that includes the entire outline.
|
|
|
|
* For shapes with handles, this might be segments of the outline
|
|
|
|
* between each handle.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
*
|
|
|
|
* ```ts
|
|
|
|
* util.getOutlineSegments(myShape)
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
getOutlineSegments(shape: Shape): Vec2d[][] {
|
|
|
|
return [this.editor.getOutline(shape)]
|
2023-06-15 14:36:46 +00:00
|
|
|
}
|
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/**
|
|
|
|
* Get the (not cached) bounds for the shape.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
abstract getBounds(shape: Shape): Box2d
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
* Get the shape's (not cached) outline.
|
2023-04-25 11:01:25 +00:00
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
getOutline(shape: Shape): Vec2d[] {
|
|
|
|
return this.editor.getBounds(shape).corners
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's snap points.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
snapPoints(shape: Shape) {
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
return this.editor.getBounds(shape).snapPoints
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's cached center.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
center(shape: Shape): Vec2d {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.getCenter(shape)
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's (not cached) center.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
getCenter(shape: Shape) {
|
|
|
|
return this.editor.getBounds(shape).center
|
|
|
|
}
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Get whether the shape can receive children of a given type.
|
|
|
|
*
|
|
|
|
* @param type - The shape type.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canReceiveNewChildrenOfType(shape: Shape, type: TLShape['type']) {
|
2023-04-25 11:01:25 +00:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get whether the shape can receive children of a given type.
|
|
|
|
*
|
|
|
|
* @param shape - The shape type.
|
|
|
|
* @param shapes - The shapes that are being dropped.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
canDropShapes(shape: Shape, shapes: TLShape[]) {
|
2023-04-25 11:01:25 +00:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape as an SVG object.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param color - The shape's CSS color (actual).
|
|
|
|
* @param font - The shape's CSS font (actual).
|
|
|
|
* @returns An SVG element.
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
toSvg?(
|
2023-06-16 10:33:47 +00:00
|
|
|
shape: Shape,
|
2023-04-25 11:01:25 +00:00
|
|
|
font: string | undefined,
|
|
|
|
colors: TLExportColors
|
|
|
|
): SVGElement | Promise<SVGElement>
|
|
|
|
|
2023-06-01 15:22:47 +00:00
|
|
|
/**
|
|
|
|
* Get the shape's background layer as an SVG object.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param color - The shape's CSS color (actual).
|
|
|
|
* @param font - The shape's CSS font (actual).
|
|
|
|
* @returns An SVG element.
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
toBackgroundSvg?(
|
2023-06-16 10:33:47 +00:00
|
|
|
shape: Shape,
|
2023-06-01 15:22:47 +00:00
|
|
|
font: string | undefined,
|
|
|
|
colors: TLExportColors
|
|
|
|
): SVGElement | Promise<SVGElement> | null
|
|
|
|
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
/** @internal */
|
|
|
|
expandSelectionOutlinePx(shape: Shape): number {
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/**
|
|
|
|
* Get whether a point intersects the shape.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param point - The point to test.
|
|
|
|
* @returns Whether the point intersects the shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hitTestPoint(shape: Shape, point: VecLike): boolean {
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
return this.editor.getBounds(shape).containsPoint(point)
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get whether a point intersects the shape.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param A - The line segment's first point.
|
|
|
|
* @param B - The line segment's second point.
|
|
|
|
* @returns Whether the line segment intersects the shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
hitTestLineSegment(shape: Shape, A: VecLike, B: VecLike): boolean {
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
const outline = this.editor.getOutline(shape)
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
for (let i = 0; i < outline.length; i++) {
|
|
|
|
const C = outline[i]
|
|
|
|
const D = outline[(i + 1) % outline.length]
|
|
|
|
if (linesIntersect(A, B, C, D)) return true
|
|
|
|
}
|
|
|
|
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
// Events
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called just before a shape is created. This method provides a last chance to modify
|
|
|
|
* the created shape.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
*
|
|
|
|
* ```ts
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
* onBeforeCreate = (next) => {
|
|
|
|
* return { ...next, x: next.x + 1 }
|
2023-04-25 11:01:25 +00:00
|
|
|
* }
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param next - The next shape.
|
|
|
|
* @returns The next shape or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onBeforeCreate?: TLOnBeforeCreateHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called just before a shape is updated. This method provides a last chance to modify
|
|
|
|
* the updated shape.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
*
|
|
|
|
* ```ts
|
|
|
|
* onBeforeUpdate = (prev, next) => {
|
|
|
|
* if (prev.x === next.x) {
|
|
|
|
* return { ...next, x: next.x + 1 }
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param prev - The previous shape.
|
|
|
|
* @param next - The next shape.
|
|
|
|
* @returns The next shape or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onBeforeUpdate?: TLOnBeforeUpdateHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
|
|
|
* A callback called when some other shapes are dragged over this one.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
*
|
|
|
|
* ```ts
|
|
|
|
* onDragShapesOver = (shape, shapes) => {
|
|
|
|
* return { shouldHint: true }
|
|
|
|
* }
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param shapes - The shapes that are being dragged over this one.
|
|
|
|
* @returns An object specifying whether the shape should hint that it can receive the dragged shapes.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDragShapesOver?: TLOnDragHandler<Shape, { shouldHint: boolean }>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when some other shapes are dragged out of this one.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param shapes - The shapes that are being dragged out.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDragShapesOut?: TLOnDragHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when some other shapes are dropped over this one.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param shapes - The shapes that are being dropped over this one.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDropShapesOver?: TLOnDragHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
|
|
|
* A callback called when a shape starts being resized.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onResizeStart?: TLOnResizeStartHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape changes from a resize.
|
|
|
|
*
|
|
|
|
* @param shape - The shape at the start of the resize.
|
|
|
|
* @param info - Info about the resize.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onResize?: TLOnResizeHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape finishes resizing.
|
|
|
|
*
|
|
|
|
* @param initial - The shape at the start of the resize.
|
|
|
|
* @param current - The current shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onResizeEnd?: TLOnResizeEndHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
|
|
|
* A callback called when a shape starts being translated.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onTranslateStart?: TLOnTranslateStartHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape changes from a translation.
|
|
|
|
*
|
|
|
|
* @param initial - The shape at the start of the translation.
|
|
|
|
* @param current - The current shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onTranslate?: TLOnTranslateHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape finishes translating.
|
|
|
|
*
|
|
|
|
* @param initial - The shape at the start of the translation.
|
|
|
|
* @param current - The current shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onTranslateEnd?: TLOnTranslateEndHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
|
|
|
* A callback called when a shape starts being rotated.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onRotateStart?: TLOnRotateStartHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape changes from a rotation.
|
|
|
|
*
|
|
|
|
* @param initial - The shape at the start of the rotation.
|
|
|
|
* @param current - The current shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onRotate?: TLOnRotateHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/**
|
|
|
|
* A callback called when a shape finishes rotating.
|
|
|
|
*
|
|
|
|
* @param initial - The shape at the start of the rotation.
|
|
|
|
* @param current - The current shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onRotateEnd?: TLOnRotateEndHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape's handle changes.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param info - An object containing the handle and whether the handle is 'precise' or not.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onHandleChange?: TLOnHandleChangeHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Not currently used.
|
|
|
|
*
|
|
|
|
* @internal
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onBindingChange?: TLOnBindingChangeHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape's children change.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns An array of shape updates, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onChildrenChange?: TLOnChildrenChangeHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape's handle is double clicked.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @param handle - The handle that is double-clicked.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDoubleClickHandle?: TLOnDoubleClickHandleHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape's edge is double clicked.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDoubleClickEdge?: TLOnDoubleClickHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape is double clicked.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onDoubleClick?: TLOnDoubleClickHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape is clicked.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @returns A change to apply to the shape, or void.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onClick?: TLOnClickHandler<Shape>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A callback called when a shape finishes being editing.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
onEditEnd?: TLOnEditEndHandler<Shape>
|
2023-04-25 11:01:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnBeforeCreateHandler<T extends TLShape> = (next: T) => T | void
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnBeforeUpdateHandler<T extends TLShape> = (prev: T, next: T) => T | void
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnTranslateStartHandler<T extends TLShape> = TLEventStartHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnTranslateHandler<T extends TLShape> = TLEventChangeHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnTranslateEndHandler<T extends TLShape> = TLEventChangeHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnRotateStartHandler<T extends TLShape> = TLEventStartHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnRotateHandler<T extends TLShape> = TLEventChangeHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnRotateEndHandler<T extends TLShape> = TLEventChangeHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
* The type of resize.
|
|
|
|
*
|
|
|
|
* 'scale_shape' - The shape is being scaled, usually as part of a larger selection.
|
|
|
|
*
|
2023-04-25 11:01:25 +00:00
|
|
|
* 'resize_bounds' - The user is directly manipulating an individual shape's bounds using a resize
|
|
|
|
* handle. It is up to shape util implementers to decide how they want to handle the two
|
|
|
|
* situations.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
export type TLResizeMode = 'scale_shape' | 'resize_bounds'
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Info about a resize.
|
|
|
|
* @param newPoint - The new local position of the shape.
|
|
|
|
* @param handle - The handle being dragged.
|
|
|
|
* @param mode - The type of resize.
|
|
|
|
* @param scaleX - The scale in the x-axis.
|
|
|
|
* @param scaleY - The scale in the y-axis.
|
|
|
|
* @param initialBounds - The bounds of the shape at the start of the resize.
|
|
|
|
* @param initialShape - The shape at the start of the resize.
|
|
|
|
* @public
|
|
|
|
*/
|
|
|
|
export type TLResizeInfo<T extends TLShape> = {
|
2023-06-15 14:36:46 +00:00
|
|
|
newPoint: Vec2d
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
handle: TLResizeHandle
|
|
|
|
mode: TLResizeMode
|
|
|
|
scaleX: number
|
|
|
|
scaleY: number
|
|
|
|
initialBounds: Box2d
|
|
|
|
initialShape: T
|
|
|
|
}
|
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnResizeHandler<T extends TLShape> = (
|
2023-04-25 11:01:25 +00:00
|
|
|
shape: T,
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
info: TLResizeInfo<T>
|
`ShapeUtil` refactor, `Editor` cleanup (#1611)
This PR improves the ergonomics of `ShapeUtil` classes.
### Cached methods
First, I've remove the cached methods (such as `bounds`) from the
`ShapeUtil` class and lifted this to the `Editor` class.
Previously, calling `ShapeUtil.getBounds` would return the un-cached
bounds of a shape, while calling `ShapeUtil.bounds` would return the
cached bounds of a shape. We also had `Editor.getBounds`, which would
call `ShapeUtil.bounds`. It was confusing. The cached methods like
`outline` were also marked with "please don't override", which suggested
the architecture was just wrong.
The only weirdness from this is that utils sometimes reach out to the
editor for cached versions of data rather than calling their own cached
methods. It's still an easier story to tell than what we had before.
### More defaults
We now have three and only three `abstract` methods for a `ShapeUtil`:
- `getDefaultProps` (renamed from `defaultProps`)
- `getBounds`,
- `component`
- `indicator`
Previously, we also had `getCenter` as an abstract method, though this
was usually just the middle of the bounds anyway.
### Editing bounds
This PR removes the concept of editingBounds. The viewport will no
longer animate to editing shapes.
### Active area manager
This PR also removes the active area manager, which was not being used
in the way we expected it to be.
### Dpr manager
This PR removes the dpr manager and uses a hook instead to update it
from React. This is one less runtime browser dependency in the app, one
less thing to document.
### Moving things around
This PR also continues to try to organize related methods and properties
in the editor.
### Change Type
- [x] `major` — Breaking change
### Release Notes
- [editor] renames `defaultProps` to `getDefaultProps`
- [editor] removes `outline`, `outlineSegments`, `handles`, `bounds`
- [editor] renames `renderBackground` to `backgroundComponent`
2023-06-19 14:01:18 +00:00
|
|
|
) => Omit<TLShapePartial<T>, 'id' | 'type'> | undefined | void
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnResizeStartHandler<T extends TLShape> = TLEventStartHandler<T>
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnResizeEndHandler<T extends TLShape> = TLEventChangeHandler<T>
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/* -------------------- Dragging -------------------- */
|
|
|
|
|
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnDragHandler<T extends TLShape, R = void> = (shape: T, shapes: TLShape[]) => R
|
2023-04-25 11:01:25 +00:00
|
|
|
|
add docs for TLShapeUtil (#1215)
This PR adds docs for the methods in the TLShapeUtil class.
I think that it's a good page to have docs on, as it shows people what's
possible with the custom shape API.
Currently, our docs are not showing `@param` info for lots of methods,
including the ones added in this PR.
I'll do fix for that in a follow-up PR, so that it's easier to review.
---
Note: Moving forward, we probably want to consider **_where_** these
docs are shown, and how we achieve that.
For example, do we put the docs for these methods in:
* The docs page for the `TLShapeUtil` class?
* The docs pages for the handler types, eg:
[`OnResizeHandler`](http://localhost:3000/gen/editor/OnResizeHandler-type)?
* Both?
Right now, I opted for putting them in the the TLShapeUtil class, as it
keeps them all in one place, and it's what we already do for some
others.
We should consider both - what works best for the docs? and what works
best for code editors?
---
This PR also includes a fix to our pre-commit step that @SomeHats did.
2023-05-05 14:05:25 +00:00
|
|
|
/** @internal */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnBindingChangeHandler<T extends TLShape> = (shape: T) => TLShapePartial<T> | void
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnChildrenChangeHandler<T extends TLShape> = (shape: T) => TLShapePartial[] | void
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnHandleChangeHandler<T extends TLShape> = (
|
2023-04-25 11:01:25 +00:00
|
|
|
shape: T,
|
|
|
|
info: {
|
|
|
|
handle: TLHandle
|
|
|
|
isPrecise: boolean
|
|
|
|
}
|
|
|
|
) => TLShapePartial<T> | void
|
|
|
|
|
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnClickHandler<T extends TLShape> = (shape: T) => TLShapePartial<T> | void
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnEditEndHandler<T extends TLShape> = (shape: T) => void
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnDoubleClickHandler<T extends TLShape> = (shape: T) => TLShapePartial<T> | void
|
2023-04-25 11:01:25 +00:00
|
|
|
/** @public */
|
2023-06-04 10:38:53 +00:00
|
|
|
export type TLOnDoubleClickHandleHandler<T extends TLShape> = (
|
2023-04-25 11:01:25 +00:00
|
|
|
shape: T,
|
|
|
|
handle: TLHandle
|
|
|
|
) => TLShapePartial<T> | void
|
|
|
|
|
2023-06-04 10:38:53 +00:00
|
|
|
type TLEventStartHandler<T extends TLShape> = (shape: T) => TLShapePartial<T> | void
|
|
|
|
type TLEventChangeHandler<T extends TLShape> = (initial: T, current: T) => TLShapePartial<T> | void
|