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-03 08:59:04 +00:00
|
|
|
import { ComputedCache } from '@tldraw/store'
|
2023-06-16 10:33:47 +00:00
|
|
|
import { StyleProp, TLHandle, TLShape, TLShapePartial, TLUnknownShape } from '@tldraw/tlschema'
|
2023-04-25 11:01:25 +00:00
|
|
|
import { computed, EMPTY_ARRAY } from 'signia'
|
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
|
|
|
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* Bounds of the shape to edit.
|
|
|
|
*
|
|
|
|
* Note: this could be a text area within a shape for example arrow labels.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
getEditingBounds = (shape: Shape) => {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.bounds(shape)
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the default props for a shape.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
abstract defaultProps(): Shape['props']
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a JSX element for the shape (as an HTML element).
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-18 09:46:53 +00:00
|
|
|
abstract component(shape: Shape): any
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Get JSX describing the shape's indicator (as an SVG element).
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
abstract indicator(shape: Shape): any
|
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
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
renderBackground?(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
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
protected getHandles?(shape: Shape): TLHandle[]
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
@computed
|
|
|
|
private get handlesCache(): ComputedCache<TLHandle[], TLShape> {
|
2023-06-02 15:21:45 +00:00
|
|
|
return this.editor.store.createComputedCache('handles:' + this.type, (shape) => {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.getHandles!(shape as any)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the cached handles (this should not be overridden!)
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
handles(shape: Shape): TLHandle[] {
|
2023-04-25 11:01:25 +00:00
|
|
|
if (!this.getHandles) return EMPTY_ARRAY
|
|
|
|
return this.handlesCache.get(shape.id) ?? EMPTY_ARRAY
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
protected getOutlineSegments(shape: Shape): Vec2d[][] {
|
2023-06-15 14:36:46 +00:00
|
|
|
return [this.outline(shape)]
|
|
|
|
}
|
|
|
|
|
|
|
|
@computed
|
|
|
|
private get outlineSegmentsCache(): ComputedCache<Vec2d[][], TLShape> {
|
|
|
|
return this.editor.store.createComputedCache('outline-segments:' + this.type, (shape) => {
|
|
|
|
return this.getOutlineSegments!(shape as any)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the cached outline segments (this should not be overridden!)
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
outlineSegments(shape: Shape): Vec2d[][] {
|
2023-06-15 14:36:46 +00:00
|
|
|
if (!this.getOutlineSegments) return EMPTY_ARRAY
|
|
|
|
return this.outlineSegmentsCache.get(shape.id) ?? EMPTY_ARRAY
|
|
|
|
}
|
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
/**
|
|
|
|
* Get the (not cached) bounds for the shape.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
protected abstract getBounds(shape: Shape): Box2d
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
@computed
|
|
|
|
private get boundsCache(): ComputedCache<Box2d, TLShape> {
|
2023-06-02 15:21:45 +00:00
|
|
|
return this.editor.store.createComputedCache('bounds:' + this.type, (shape) => {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.getBounds(shape as any)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the cached bounds for the shape.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
bounds(shape: Shape): Box2d {
|
2023-04-25 11:01:25 +00:00
|
|
|
const result = this.boundsCache.get(shape.id) ?? new Box2d()
|
|
|
|
if (result.width === 0 || result.height === 0) {
|
|
|
|
return new Box2d(result.x, result.y, Math.max(result.width, 1), Math.max(result.height, 1))
|
|
|
|
}
|
|
|
|
return result
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's (not cached) outline. Do not override this method!
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
protected abstract getOutline(shape: Shape): Vec2d[]
|
2023-04-25 11:01:25 +00:00
|
|
|
|
|
|
|
@computed
|
2023-06-15 14:36:46 +00:00
|
|
|
private get outlineCache(): ComputedCache<Vec2d[], TLShape> {
|
2023-06-02 15:21:45 +00:00
|
|
|
return this.editor.store.createComputedCache('outline:' + this.type, (shape) => {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.getOutline(shape as any)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's outline. Do not override this method!
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
outline(shape: Shape): Vec2d[] {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.outlineCache.get(shape.id) ?? EMPTY_ARRAY
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the shape's snap points.
|
|
|
|
*
|
|
|
|
* @param shape - The shape.
|
|
|
|
* @public
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
snapPoints(shape: Shape) {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.bounds(shape).snapPoints
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
abstract getCenter(shape: Shape): Vec2d
|
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
|
|
|
|
|
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 {
|
2023-04-25 11:01:25 +00:00
|
|
|
return this.bounds(shape).containsPoint(point)
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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 {
|
2023-04-25 11:01:25 +00:00
|
|
|
const outline = this.outline(shape)
|
|
|
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2023-05-16 08:35:45 +00:00
|
|
|
/** @internal */
|
2023-06-16 10:33:47 +00:00
|
|
|
expandSelectionOutlinePx(shape: Shape): number {
|
2023-05-16 08:35:45 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2023-06-01 15:22:47 +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.
|
|
|
|
*
|
|
|
|
* @internal
|
|
|
|
*/
|
2023-06-16 10:33:47 +00:00
|
|
|
providesBackgroundForChildren(shape: Shape): boolean {
|
2023-06-01 15:22:47 +00:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2023-04-25 11:01:25 +00:00
|
|
|
// 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>
|
2023-04-25 11:01:25 +00:00
|
|
|
) => Partial<TLShapePartial<T>> | 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
|