tldraw/packages/validate/api-report.md

237 lines
6.6 KiB
Markdown
Raw Normal View History

## API Report File for "@tldraw/validate"
2023-04-25 11:01:25 +00:00
> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
```ts
import { IndexKey } from '@tldraw/utils';
import { JsonValue } from '@tldraw/utils';
2023-04-25 11:01:25 +00:00
// @public
const any: Validator<any>;
// @public
const array: Validator<unknown[]>;
// @public
function arrayOf<T>(itemValidator: Validatable<T>): ArrayOfValidator<T>;
2023-04-25 11:01:25 +00:00
// @public (undocumented)
export class ArrayOfValidator<T> extends Validator<T[]> {
constructor(itemValidator: Validatable<T>);
2023-04-25 11:01:25 +00:00
// (undocumented)
readonly itemValidator: Validatable<T>;
2023-04-25 11:01:25 +00:00
// (undocumented)
lengthGreaterThan1(): Validator<T[]>;
// (undocumented)
nonEmpty(): Validator<T[]>;
}
// @public
const bigint: Validator<bigint>;
// @public
const boolean: Validator<boolean>;
// @public
function dict<Key extends string, Value>(keyValidator: Validatable<Key>, valueValidator: Validatable<Value>): DictValidator<Key, Value>;
2023-04-25 11:01:25 +00:00
// @public (undocumented)
export class DictValidator<Key extends string, Value> extends Validator<Record<Key, Value>> {
constructor(keyValidator: Validatable<Key>, valueValidator: Validatable<Value>);
2023-04-25 11:01:25 +00:00
// (undocumented)
readonly keyValidator: Validatable<Key>;
2023-04-25 11:01:25 +00:00
// (undocumented)
readonly valueValidator: Validatable<Value>;
2023-04-25 11:01:25 +00:00
}
// @public
const indexKey: Validator<IndexKey>;
2023-04-25 11:01:25 +00:00
// @public
const integer: Validator<number>;
// @public
function jsonDict(): DictValidator<string, JsonValue>;
// @public
const jsonValue: Validator<JsonValue>;
// @public
const linkUrl: Validator<string>;
2023-04-25 11:01:25 +00:00
// @public
function literal<T extends boolean | number | string>(expectedValue: T): Validator<T>;
// @public (undocumented)
function literalEnum<const Values extends readonly unknown[]>(...values: Values): Validator<Values[number]>;
2023-04-25 11:01:25 +00:00
// @public
function model<T extends {
readonly id: string;
}>(name: string, validator: Validatable<T>): Validator<T>;
2023-04-25 11:01:25 +00:00
// @public
const nonZeroInteger: Validator<number>;
// @public
const nonZeroNumber: Validator<number>;
// @public (undocumented)
function nullable<T>(validator: Validatable<T>): Validator<null | T>;
2023-04-25 11:01:25 +00:00
// @public
const number: Validator<number>;
// @public
function object<Shape extends object>(config: {
readonly [K in keyof Shape]: Validatable<Shape[K]>;
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
}): ObjectValidator<{
[P in ExtractRequiredKeys<Shape>]: Shape[P];
} & {
[P in ExtractOptionalKeys<Shape>]?: Shape[P];
}>;
2023-04-25 11:01:25 +00:00
// @public (undocumented)
export class ObjectValidator<Shape extends object> extends Validator<Shape> {
2023-04-25 11:01:25 +00:00
constructor(config: {
readonly [K in keyof Shape]: Validatable<Shape[K]>;
2023-04-25 11:01:25 +00:00
}, shouldAllowUnknownProperties?: boolean);
// (undocumented)
allowUnknownProperties(): ObjectValidator<Shape>;
// (undocumented)
readonly config: {
readonly [K in keyof Shape]: Validatable<Shape[K]>;
2023-04-25 11:01:25 +00:00
};
extend<Extension extends Record<string, unknown>>(extension: {
readonly [K in keyof Extension]: Validatable<Extension[K]>;
2023-04-25 11:01:25 +00:00
}): ObjectValidator<Shape & Extension>;
}
// @public (undocumented)
function optional<T>(validator: Validatable<T>): Validator<T | undefined>;
2023-04-25 11:01:25 +00:00
// @public
const positiveInteger: Validator<number>;
// @public
const positiveNumber: Validator<number>;
// @public (undocumented)
function setEnum<T>(values: ReadonlySet<T>): Validator<T>;
// @public
const srcUrl: Validator<string>;
2023-04-25 11:01:25 +00:00
// @public
const string: Validator<string>;
declare namespace T {
export {
literal,
arrayOf,
object,
jsonDict,
2023-04-25 11:01:25 +00:00
dict,
union,
model,
setEnum,
optional,
nullable,
literalEnum,
2023-04-25 11:01:25 +00:00
ValidatorFn,
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
ValidatorUsingKnownGoodVersionFn,
Validatable,
2023-04-25 11:01:25 +00:00
ValidationError,
TypeOf,
Validator,
ArrayOfValidator,
ObjectValidator,
UnionValidator,
DictValidator,
unknown,
any,
string,
number,
positiveNumber,
nonZeroNumber,
integer,
positiveInteger,
nonZeroInteger,
boolean,
bigint,
array,
unknownObject,
jsonValue,
linkUrl,
srcUrl,
indexKey
2023-04-25 11:01:25 +00:00
}
}
export { T }
// @public (undocumented)
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
type TypeOf<V extends Validatable<any>> = V extends Validatable<infer T> ? T : never;
2023-04-25 11:01:25 +00:00
// @public
function union<Key extends string, Config extends UnionValidatorConfig<Key, Config>>(key: Key, config: Config): UnionValidator<Key, Config>;
// @public (undocumented)
export class UnionValidator<Key extends string, Config extends UnionValidatorConfig<Key, Config>, UnknownValue = never> extends Validator<TypeOf<Config[keyof Config]> | UnknownValue> {
2023-04-25 11:01:25 +00:00
constructor(key: Key, config: Config, unknownValueValidation: (value: object, variant: string) => UnknownValue);
// (undocumented)
validateUnknownVariants<Unknown>(unknownValueValidation: (value: object, variant: string) => Unknown): UnionValidator<Key, Config, Unknown>;
}
// @public
const unknown: Validator<unknown>;
// @public (undocumented)
const unknownObject: Validator<Record<string, unknown>>;
// @public (undocumented)
type Validatable<T> = {
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
validateUsingKnownGoodVersion?: (knownGoodValue: T, newValue: unknown) => T;
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
validate: (value: unknown) => T;
};
2023-04-25 11:01:25 +00:00
// @public (undocumented)
class ValidationError extends Error {
constructor(rawMessage: string, path?: ReadonlyArray<number | string>);
// (undocumented)
name: string;
// (undocumented)
readonly path: ReadonlyArray<number | string>;
// (undocumented)
readonly rawMessage: string;
}
// @public (undocumented)
tldraw zero - package shuffle (#1710) This PR moves code between our packages so that: - @tldraw/editor is a “core” library with the engine and canvas but no shapes, tools, or other things - @tldraw/tldraw contains everything particular to the experience we’ve built for tldraw At first look, this might seem like a step away from customization and configuration, however I believe it greatly increases the configuration potential of the @tldraw/editor while also providing a more accurate reflection of what configuration options actually exist for @tldraw/tldraw. ## Library changes @tldraw/editor re-exports its dependencies and @tldraw/tldraw re-exports @tldraw/editor. - users of @tldraw/editor WITHOUT @tldraw/tldraw should almost always only import things from @tldraw/editor. - users of @tldraw/tldraw should almost always only import things from @tldraw/tldraw. - @tldraw/polyfills is merged into @tldraw/editor - @tldraw/indices is merged into @tldraw/editor - @tldraw/primitives is merged mostly into @tldraw/editor, partially into @tldraw/tldraw - @tldraw/file-format is merged into @tldraw/tldraw - @tldraw/ui is merged into @tldraw/tldraw Many (many) utils and other code is moved from the editor to tldraw. For example, embeds now are entirely an feature of @tldraw/tldraw. The only big chunk of code left in core is related to arrow handling. ## API Changes The editor can now be used without tldraw's assets. We load them in @tldraw/tldraw instead, so feel free to use whatever fonts or images or whatever that you like with the editor. All tools and shapes (except for the `Group` shape) are moved to @tldraw/tldraw. This includes the `select` tool. You should use the editor with at least one tool, however, so you now also need to send in an `initialState` prop to the Editor / <TldrawEditor> component indicating which state the editor should begin in. The `components` prop now also accepts `SelectionForeground`. The complex selection component that we use for tldraw is moved to @tldraw/tldraw. The default component is quite basic but can easily be replaced via the `components` prop. We pass down our tldraw-flavored SelectionFg via `components`. Likewise with the `Scribble` component: the `DefaultScribble` no longer uses our freehand tech and is a simple path instead. We pass down the tldraw-flavored scribble via `components`. The `ExternalContentManager` (`Editor.externalContentManager`) is removed and replaced with a mapping of types to handlers. - Register new content handlers with `Editor.registerExternalContentHandler`. - Register new asset creation handlers (for files and URLs) with `Editor.registerExternalAssetHandler` ### Change Type - [x] `major` — Breaking change ### Test Plan - [x] Unit Tests - [x] End to end tests ### Release Notes - [@tldraw/editor] lots, wip - [@tldraw/ui] gone, merged to tldraw/tldraw - [@tldraw/polyfills] gone, merged to tldraw/editor - [@tldraw/primitives] gone, merged to tldraw/editor / tldraw/tldraw - [@tldraw/indices] gone, merged to tldraw/editor - [@tldraw/file-format] gone, merged to tldraw/tldraw --------- Co-authored-by: alex <alex@dytry.ch>
2023-07-17 21:22:34 +00:00
export class Validator<T> implements Validatable<T> {
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
constructor(validationFn: ValidatorFn<T>, validateUsingKnownGoodVersionFn?: undefined | ValidatorUsingKnownGoodVersionFn<T, T>);
2023-04-25 11:01:25 +00:00
check(name: string, checkFn: (value: T) => void): Validator<T>;
// (undocumented)
check(checkFn: (value: T) => void): Validator<T>;
isValid(value: unknown): value is T;
2023-04-25 11:01:25 +00:00
nullable(): Validator<null | T>;
optional(): Validator<T | undefined>;
refine<U>(otherValidationFn: (value: T) => U): Validator<U>;
validate(value: unknown): T;
// (undocumented)
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
validateUsingKnownGoodVersion(knownGoodValue: T, newValue: unknown): T;
// (undocumented)
readonly validateUsingKnownGoodVersionFn?: undefined | ValidatorUsingKnownGoodVersionFn<T, T>;
// (undocumented)
2023-04-25 11:01:25 +00:00
readonly validationFn: ValidatorFn<T>;
}
// @public (undocumented)
type ValidatorFn<T> = (value: unknown) => T;
Faster validations + record reference stability at the same time (#2848) This PR adds a validation mode whereby previous known-to-be-valid values can be used to speed up the validation process itself. At the same time it enables us to do fine-grained equality checking on records much more quickly than by using something like lodash isEqual, and using that we can prevent triggering effects for record updates that don't actually alter any values in the store. Here's some preliminary perf testing of average time spent in `store.put()` during some common interactions | task | before (ms) | after (ms) | | ---- | ---- | ---- | | drawing lines | 0.0403 | 0.0214 | | drawing boxes | 0.0408 | 0.0348 | | translating lines | 0.0352 | 0.0042 | | translating boxes | 0.0051 | 0.0032 | | rotating lines | 0.0312 | 0.0065 | | rotating boxes | 0.0053 | 0.0035 | | brush selecting boxes | 0.0200 | 0.0232 | | traversal with shapes | 0.0130 | 0.0108 | | traversal without shapes | 0.0201 | 0.0173 | **traversal** means moving the camera and pointer around the canvas #### Discussion At the scale of hundredths of a millisecond these .put operations are so fast that even if they became literally instantaneous the change would not be human perceptible. That said, there is an overall marked improvement here. Especially for dealing with draw shapes. These figures are also mostly in line with expectations, aside from a couple of things: - I don't understand why the `brush selecting boxes` task got slower after the change. - I don't understand why the `traversal` tasks are slower than the `translating boxes` task, both before and after. I would expect that .putting shape records would be much slower than .putting pointer/camera records (since the latter have fewer and simpler properties) ### Change Type - [x] `patch` — Bug fix ### Test Plan 1. Add a step-by-step description of how to test your PR here. 2. - [ ] Unit Tests - [ ] End to end tests ### Release Notes - Add a brief release note for your PR here.
2024-02-20 12:35:25 +00:00
// @public (undocumented)
type ValidatorUsingKnownGoodVersionFn<In, Out = In> = (knownGoodValue: In, value: unknown) => Out;
2023-04-25 11:01:25 +00:00
// (No @packageDocumentation comment for this package)
```