tldraw/packages/utils/api-report.md

344 lines
9.5 KiB
Markdown
Raw Normal View History

2023-04-25 11:01:25 +00:00
## API Report File for "@tldraw/utils"
> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
```ts
// @internal
export function annotateError(error: unknown, annotations: Partial<ErrorAnnotations>): void;
// @internal (undocumented)
export function areArraysShallowEqual<T>(arr1: readonly T[], arr2: readonly T[]): boolean;
// @internal (undocumented)
export function areObjectsShallowEqual<T extends Record<string, unknown>>(obj1: T, obj2: T): boolean;
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export const assert: (value: unknown, message?: string) => asserts value;
// @internal (undocumented)
export const assertExists: <T>(value: T, message?: string | undefined) => NonNullable<T>;
// @internal
export function clearLocalStorage(): void;
// @internal
export function clearSessionStorage(): void;
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function compact<T>(arr: T[]): NonNullable<T>[];
// @public
export function debounce<T extends unknown[], U>(callback: (...args: T) => PromiseLike<U> | U, wait: number): {
(...args: T): Promise<U>;
cancel(): void;
};
// @public
export function dedupe<T>(input: T[], equals?: (a: any, b: any) => boolean): T[];
// @internal
export function deleteFromLocalStorage(key: string): void;
// @internal
export function deleteFromSessionStorage(key: string): void;
2023-04-25 11:01:25 +00:00
// @public (undocumented)
export type ErrorResult<E> = {
readonly error: E;
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
readonly ok: false;
2023-04-25 11:01:25 +00:00
};
// @internal (undocumented)
export function exhaustiveSwitchError(value: never, property?: string): never;
// @public (undocumented)
export type Expand<T> = T extends infer O ? {
[K in keyof O]: O[K];
} : never;
// @public
export class FileHelpers {
static blobToDataUrl(file: Blob): Promise<string>;
static blobToText(file: Blob): Promise<string>;
// (undocumented)
static dataUrlToArrayBuffer(dataURL: string): Promise<ArrayBuffer>;
}
derived presence state (#1204) This PR adds - A new `TLInstancePresence` record type, to collect info about the presence state in a particular instance of the editor. This will eventually be used to sync presence data instead of sending instance-only state across the wire. - **Record Scopes** `RecordType` now has a `scope` property which can be one of three things: - `document`: the record belongs to the document and should be synced and persisted freely. Currently: `TLDocument`, `TLPage`, `TLShape`, and `TLAsset` - `instance`: the record belongs to a single instance of the store and should not be synced at all. It should not be persisted directly in most cases, but rather compiled into a kind of 'instance configuration' to store alongside the local document data so that when reopening the associated document it can remember some of the previous instance state. Currently: `TLInstance`, `TLInstancePageState`, `TLCamera`, `TLUser`, `TLUserDocument`, `TLUserPresence` - `presence`: the record belongs to a single instance of the store and should not be persisted, but may be synced using the special presence sync protocol. Currently just `TLInstancePresence` This sets us up for the following changes, which are gonna be pretty high-impact in terms of integrating tldraw into existing systems: - Removing `instanceId` as a config option. Each instance gets a randomly generated ID. - We'd replace it with an `instanceConfig` option that has stuff like selectedIds, camera positions, and so on. Then it's up to library users to get and reinstate the instance config at persistence boundaries. - Removing `userId` as config option, and removing the `TLUser` type altogether. - We might need to revisit when doing auth-enabled features like locking shapes, but I suspect that will be separate.
2023-04-27 18:03:19 +00:00
// @internal
export function filterEntries<Key extends string, Value>(object: {
[K in Key]: Value;
}, predicate: (key: Key, value: Value) => boolean): {
[K in Key]: Value;
};
Performance improvements (#2977) This PR does a few things to help with performance: 1. Instead of doing changes on raf we now do them 60 times per second. This limits the number of updates on high refresh rate screens like the iPad. With the current code this only applied to the history updates (so when you subscribed to the updates), but the next point takes this a bit futher. 2. We now trigger react updates 60 times per second. This is a change in `useValue` and `useStateTracking` hooks. 3. We now throttle the inputs (like the `pointerMove`) in state nodes. This means we batch multiple inputs and only apply them at most 60 times per second. We had to adjust our own tests to pass after this change so I marked this as major as it might require the users of the library to do the same. Few observations: - The browser calls the raf callbacks when it can. If it gets overwhelmed it will call them further and further apart. As things call down it will start calling them more frequently again. You can clearly see this in the drawing example. When fps gets to a certain level we start to get fewer updates, then fps can recover a bit. This makes the experience quite janky. The updates can be kinda ok one second (dropping frames, but consistently) and then they can completely stop and you have to let go of the mouse to make them happen again. With the new logic it seems everything is a lot more consistent. - We might look into variable refresh rates to prevent this overtaxing of the browser. Like when we see that the times between our updates are getting higher we could make the updates less frequent. If we then see that they are happening more often we could ramp them back up. I had an [experiment for this here](https://github.com/tldraw/tldraw/pull/2977/commits/48348639669e556798296eee82fc53ca8ef444f2#diff-318e71563d7c47173f89ec084ca44417cf70fc72faac85b96f48b856a8aec466L30-L35). Few tests below. Used 6x slowdown for these. # Resizing ### Before https://github.com/tldraw/tldraw/assets/2523721/798a033f-5dfa-419e-9a2d-fd8908272ba0 ### After https://github.com/tldraw/tldraw/assets/2523721/45870a0c-c310-4be0-b63c-6c92c20ca037 # Drawing Comparison is not 100% fair, we don't store the intermediate inputs right now. That said, tick should still only produce once update so I do think we can get a sense of the differences. ### Before https://github.com/tldraw/tldraw/assets/2523721/2e8ac8c5-bbdf-484b-bb0c-70c967f4541c ### After https://github.com/tldraw/tldraw/assets/2523721/8f54b7a8-9a0e-4a39-b168-482caceb0149 ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [x] `major` — Breaking change - [ ] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [ ] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Release Notes - Improves the performance of rendering. --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-03-11 13:17:31 +00:00
// @internal
export function fpsThrottle(fn: () => void): () => void;
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function getErrorAnnotations(error: Error): ErrorAnnotations;
// @public
export function getFirstFromIterable<T = unknown>(set: Map<any, T> | Set<T>): T;
// @internal
export function getFromLocalStorage(key: string): null | string;
// @internal
export function getFromSessionStorage(key: string): null | string;
faster image processing in default asset handler (#2441) ![Kapture 2024-01-10 at 13 42 06](https://github.com/tldraw/tldraw/assets/1489520/616bcda7-c05b-46f1-b985-3a36bb5c9476) (gif is with 6x CPU throttling to make the effect more visible) This is the first of a few diffs I'm working on to make dropping images onto the canvas feel a lot faster. There are three main changes here: 1. We operate on `Blob`s and `File`s rather than data urls. This saves a fair bit on converting to/from base64 all the time. I've updated our `MediaHelper` APIs to encourage the same in consumers. 2. We only check the max canvas size (slow) if images are above a certain dimension that we consider "safe" (8k x 8k) 3. Switching from the `downscale` npm library to canvas native downscaling. that library claims to give better results than the browser, but hasn't been updated in ~7 years. in modern browsers, we can opt-in to native high-quality image smoothing to achieve similar results much faster than with an algorithm implemented in pure JS. I want to follow this up with a system to show image placeholders whilst we're waiting for long-running operations like resizing etc but i'm going to split that out into its own diff as it'll involve some fairly complex changes to the history management API. ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Tested manually, unit tests & end-to-end tests pass
2024-01-10 14:41:18 +00:00
// @public
export function getHashForBuffer(buffer: ArrayBuffer): string;
2023-04-25 11:01:25 +00:00
// @public
export function getHashForObject(obj: any): string;
// @public
export function getHashForString(string: string): string;
// @public
export function getIndexAbove(below: IndexKey): IndexKey;
// @public
export function getIndexBelow(above: IndexKey): IndexKey;
// @public
export function getIndexBetween(below: IndexKey, above?: IndexKey): IndexKey;
// @public
export function getIndices(n: number, start?: IndexKey): IndexKey[];
// @public
export function getIndicesAbove(below: IndexKey, n: number): IndexKey[];
// @public
export function getIndicesBelow(above: IndexKey, n: number): IndexKey[];
// @public
export function getIndicesBetween(below: IndexKey | undefined, above: IndexKey | undefined, n: number): IndexKey[];
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function getOwnProperty<K extends string, V>(obj: Partial<Record<K, V>>, key: K): undefined | V;
// @internal (undocumented)
export function getOwnProperty(obj: object, key: string): unknown;
// @internal (undocumented)
export function hasOwnProperty(obj: object, key: string): boolean;
// @public
export type IndexKey = string & {
__orderKey: true;
};
// @public
export function invLerp(a: number, b: number, t: number): number;
2023-04-25 11:01:25 +00:00
// @public
export function isDefined<T>(value: T): value is typeof value extends undefined ? never : T;
use native structuredClone on node, cloudflare workers, and in tests (#3166) Currently, we only use native `structuredClone` in the browser, falling back to `JSON.parse(JSON.stringify(...))` elsewhere, despite Node supporting `structuredClone` [since v17](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone) and Cloudflare Workers supporting it [since 2022](https://blog.cloudflare.com/standards-compliant-workers-api/). This PR adjusts our shim to use the native `structuredClone` on all platforms, if available. Additionally, `jsdom` doesn't implement `structuredClone`, a bug [open since 2022](https://github.com/jsdom/jsdom/issues/3363). This PR patches `jsdom` environment in all packages/apps that use it for tests. Also includes a driveby removal of `deepCopy`, a function that is strictly inferior to `structuredClone`. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [x] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. A smoke test would be enough - [ ] Unit Tests - [x] End to end tests
2024-03-18 17:16:09 +00:00
// @internal (undocumented)
export const isNativeStructuredClone: boolean;
2023-04-25 11:01:25 +00:00
// @public
export function isNonNull<T>(value: T): value is typeof value extends null ? never : T;
// @public
export function isNonNullish<T>(value: T): value is typeof value extends undefined ? never : typeof value extends null ? never : T;
// @public (undocumented)
export type JsonArray = JsonValue[];
// @public (undocumented)
export type JsonObject = {
[key: string]: JsonValue | undefined;
};
// @public (undocumented)
export type JsonPrimitive = boolean | null | number | string;
// @public (undocumented)
export type JsonValue = JsonArray | JsonObject | JsonPrimitive;
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function last<T>(arr: readonly T[]): T | undefined;
// @public
export function lerp(a: number, b: number, t: number): number;
// @public (undocumented)
export function lns(str: string): string;
// @internal
export function mapObjectMapValues<Key extends string, ValueBefore, ValueAfter>(object: {
readonly [K in Key]: ValueBefore;
}, mapper: (key: Key, value: ValueBefore) => ValueAfter): {
[K in Key]: ValueAfter;
};
// @internal (undocumented)
export function measureAverageDuration(_target: any, propertyKey: string, descriptor: PropertyDescriptor): PropertyDescriptor;
// @internal (undocumented)
export function measureCbDuration(name: string, cb: () => any): any;
// @internal (undocumented)
export function measureDuration(_target: any, propertyKey: string, descriptor: PropertyDescriptor): PropertyDescriptor;
// @public
export class MediaHelpers {
faster image processing in default asset handler (#2441) ![Kapture 2024-01-10 at 13 42 06](https://github.com/tldraw/tldraw/assets/1489520/616bcda7-c05b-46f1-b985-3a36bb5c9476) (gif is with 6x CPU throttling to make the effect more visible) This is the first of a few diffs I'm working on to make dropping images onto the canvas feel a lot faster. There are three main changes here: 1. We operate on `Blob`s and `File`s rather than data urls. This saves a fair bit on converting to/from base64 all the time. I've updated our `MediaHelper` APIs to encourage the same in consumers. 2. We only check the max canvas size (slow) if images are above a certain dimension that we consider "safe" (8k x 8k) 3. Switching from the `downscale` npm library to canvas native downscaling. that library claims to give better results than the browser, but hasn't been updated in ~7 years. in modern browsers, we can opt-in to native high-quality image smoothing to achieve similar results much faster than with an algorithm implemented in pure JS. I want to follow this up with a system to show image placeholders whilst we're waiting for long-running operations like resizing etc but i'm going to split that out into its own diff as it'll involve some fairly complex changes to the history management API. ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Tested manually, unit tests & end-to-end tests pass
2024-01-10 14:41:18 +00:00
static getImageSize(blob: Blob): Promise<{
h: number;
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
w: number;
}>;
faster image processing in default asset handler (#2441) ![Kapture 2024-01-10 at 13 42 06](https://github.com/tldraw/tldraw/assets/1489520/616bcda7-c05b-46f1-b985-3a36bb5c9476) (gif is with 6x CPU throttling to make the effect more visible) This is the first of a few diffs I'm working on to make dropping images onto the canvas feel a lot faster. There are three main changes here: 1. We operate on `Blob`s and `File`s rather than data urls. This saves a fair bit on converting to/from base64 all the time. I've updated our `MediaHelper` APIs to encourage the same in consumers. 2. We only check the max canvas size (slow) if images are above a certain dimension that we consider "safe" (8k x 8k) 3. Switching from the `downscale` npm library to canvas native downscaling. that library claims to give better results than the browser, but hasn't been updated in ~7 years. in modern browsers, we can opt-in to native high-quality image smoothing to achieve similar results much faster than with an algorithm implemented in pure JS. I want to follow this up with a system to show image placeholders whilst we're waiting for long-running operations like resizing etc but i'm going to split that out into its own diff as it'll involve some fairly complex changes to the history management API. ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Tested manually, unit tests & end-to-end tests pass
2024-01-10 14:41:18 +00:00
static getVideoSize(blob: Blob): Promise<{
h: number;
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
w: number;
}>;
faster image processing in default asset handler (#2441) ![Kapture 2024-01-10 at 13 42 06](https://github.com/tldraw/tldraw/assets/1489520/616bcda7-c05b-46f1-b985-3a36bb5c9476) (gif is with 6x CPU throttling to make the effect more visible) This is the first of a few diffs I'm working on to make dropping images onto the canvas feel a lot faster. There are three main changes here: 1. We operate on `Blob`s and `File`s rather than data urls. This saves a fair bit on converting to/from base64 all the time. I've updated our `MediaHelper` APIs to encourage the same in consumers. 2. We only check the max canvas size (slow) if images are above a certain dimension that we consider "safe" (8k x 8k) 3. Switching from the `downscale` npm library to canvas native downscaling. that library claims to give better results than the browser, but hasn't been updated in ~7 years. in modern browsers, we can opt-in to native high-quality image smoothing to achieve similar results much faster than with an algorithm implemented in pure JS. I want to follow this up with a system to show image placeholders whilst we're waiting for long-running operations like resizing etc but i'm going to split that out into its own diff as it'll involve some fairly complex changes to the history management API. ### Change Type - [x] `major` — Breaking change [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version ### Test Plan 1. Tested manually, unit tests & end-to-end tests pass
2024-01-10 14:41:18 +00:00
static loadImage(src: string): Promise<HTMLImageElement>;
static loadVideo(src: string): Promise<HTMLVideoElement>;
// (undocumented)
static usingObjectURL<T>(blob: Blob, fn: (url: string) => Promise<T>): Promise<T>;
}
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function minBy<T>(arr: readonly T[], fn: (item: T) => number): T | undefined;
// @public
export function modulate(value: number, rangeA: number[], rangeB: number[], clamp?: boolean): number;
// @internal
export function noop(): void;
2023-04-25 11:01:25 +00:00
// @internal
export function objectMapEntries<Key extends string, Value>(object: {
[K in Key]: Value;
}): Array<[Key, Value]>;
// @internal
export function objectMapFromEntries<Key extends string, Value>(entries: ReadonlyArray<readonly [Key, Value]>): {
[K in Key]: Value;
};
2023-04-25 11:01:25 +00:00
// @internal
export function objectMapKeys<Key extends string>(object: {
readonly [K in Key]: unknown;
}): Array<Key>;
// @internal
export function objectMapValues<Key extends string, Value>(object: {
[K in Key]: Value;
}): Array<Value>;
// @public (undocumented)
export type OkResult<T> = {
readonly ok: true;
readonly value: T;
};
// @internal
export function omitFromStackTrace<Args extends Array<unknown>, Return>(fn: (...args: Args) => Return): (...args: Args) => Return;
// @internal
export function partition<T>(arr: T[], predicate: (item: T) => boolean): [T[], T[]];
// @public (undocumented)
export class PngHelpers {
// (undocumented)
static findChunk(view: DataView, type: string): {
dataOffset: number;
size: number;
start: number;
};
// (undocumented)
static getChunkType(view: DataView, offset: number): string;
// (undocumented)
static isPng(view: DataView, offset: number): boolean;
// (undocumented)
static parsePhys(view: DataView, offset: number): {
ppux: number;
ppuy: number;
unit: number;
};
// (undocumented)
static readChunks(view: DataView, offset?: number): Record<string, {
dataOffset: number;
size: number;
start: number;
}>;
// (undocumented)
static setPhysChunk(view: DataView, dpr?: number, options?: BlobPropertyBag): Blob;
}
2023-04-25 11:01:25 +00:00
// @internal (undocumented)
export function promiseWithResolve<T>(): Promise<T> & {
reject: (reason?: any) => void;
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
resolve: (value: T) => void;
2023-04-25 11:01:25 +00:00
};
// @public (undocumented)
export type RecursivePartial<T> = {
[P in keyof T]?: RecursivePartial<T[P]>;
};
// @internal (undocumented)
type Required_2<T, K extends keyof T> = Expand<Omit<T, K> & _Required<Pick<T, K>>>;
export { Required_2 as Required }
2023-04-25 11:01:25 +00:00
// @public (undocumented)
export type Result<T, E> = ErrorResult<E> | OkResult<T>;
// @public (undocumented)
export const Result: {
err<E>(error: E): ErrorResult<E>;
New migrations again (#3220) Describe what your pull request does. If appropriate, add GIFs or images showing the before and after. ### Change Type - [x] `sdk` — Changes the tldraw SDK - [x] `galaxy brain` — Architectural changes ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes #### BREAKING CHANGES - The `Migrations` type is now called `LegacyMigrations`. - The serialized schema format (e.g. returned by `StoreSchema.serialize()` and `Store.getSnapshot()`) has changed. You don't need to do anything about it unless you were reading data directly from the schema for some reason. In which case it'd be best to avoid that in the future! We have no plans to change the schema format again (this time was traumatic enough) but you never know. - `compareRecordVersions` and the `RecordVersion` type have both disappeared. There is no replacement. These were public by mistake anyway, so hopefully nobody had been using it. - `compareSchemas` is a bit less useful now. Our migrations system has become a little fuzzy to allow for simpler UX when adding/removing custom extensions and 3rd party dependencies, and as a result we can no longer compare serialized schemas in any rigorous manner. You can rely on this function to return `0` if the schemas are the same. Otherwise it will return `-1` if the schema on the right _seems_ to be newer than the schema on the left, but it cannot guarantee that in situations where migration sequences have been removed over time (e.g. if you remove one of the builtin tldraw shapes). Generally speaking, the best way to check schema compatibility now is to call `store.schema.getMigrationsSince(persistedSchema)`. This will throw an error if there is no upgrade path from the `persistedSchema` to the current version. - `defineMigrations` has been deprecated and will be removed in a future release. For upgrade instructions see https://tldraw.dev/docs/persistence#Updating-legacy-shape-migrations-defineMigrations - `migrate` has been removed. Nobody should have been using this but if you were you'll need to find an alternative. For migrating tldraw data, you should stick to using `schema.migrateStoreSnapshot` and, if you are building a nuanced sync engine that supports some amount of backwards compatibility, also feel free to use `schema.migratePersistedRecord`. - the `Migration` type has changed. If you need the old one for some reason it has been renamed to `LegacyMigration`. It will be removed in a future release. - the `Migrations` type has been renamed to `LegacyMigrations` and will be removed in a future release. - the `SerializedSchema` type has been augmented. If you need the old version specifically you can use `SerializedSchemaV1` --------- Co-authored-by: Steve Ruiz <steveruizok@gmail.com>
2024-04-15 12:53:42 +00:00
ok<T>(value: T): OkResult<T>;
2023-04-25 11:01:25 +00:00
};
// @public
export function rng(seed?: string): () => number;
// @public
export function rotateArray<T>(arr: T[], offset: number): T[];
// @internal
export function setInLocalStorage(key: string, value: string): void;
// @internal
export function setInSessionStorage(key: string, value: string): void;
// @public (undocumented)
export function sortById<T extends {
id: any;
}>(a: T, b: T): -1 | 1;
// @public
export function sortByIndex<T extends {
index: IndexKey;
}>(a: T, b: T): -1 | 0 | 1;
use native structuredClone on node, cloudflare workers, and in tests (#3166) Currently, we only use native `structuredClone` in the browser, falling back to `JSON.parse(JSON.stringify(...))` elsewhere, despite Node supporting `structuredClone` [since v17](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone) and Cloudflare Workers supporting it [since 2022](https://blog.cloudflare.com/standards-compliant-workers-api/). This PR adjusts our shim to use the native `structuredClone` on all platforms, if available. Additionally, `jsdom` doesn't implement `structuredClone`, a bug [open since 2022](https://github.com/jsdom/jsdom/issues/3363). This PR patches `jsdom` environment in all packages/apps that use it for tests. Also includes a driveby removal of `deepCopy`, a function that is strictly inferior to `structuredClone`. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [x] `sdk` — Changes the tldraw SDK - [x] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [ ] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [x] `improvement` — Improving existing features - [x] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [ ] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Test Plan 1. A smoke test would be enough - [ ] Unit Tests - [x] End to end tests
2024-03-18 17:16:09 +00:00
// @internal
export const STRUCTURED_CLONE_OBJECT_PROTOTYPE: any;
// @public
2023-04-25 11:01:25 +00:00
const structuredClone_2: <T>(i: T) => T;
export { structuredClone_2 as structuredClone }
// @public
export function throttle<T extends (...args: any) => any>(func: T, limit: number): (...args: Parameters<T>) => ReturnType<T>;
// @internal
export function throttleToNextFrame(fn: () => void): () => void;
// @internal (undocumented)
export function validateIndexKey(key: string): asserts key is IndexKey;
// @internal (undocumented)
export function warnDeprecatedGetter(name: string): void;
// @public
export const ZERO_INDEX_KEY: IndexKey;
2023-04-25 11:01:25 +00:00
// (No @packageDocumentation comment for this package)
```