Use big object for constants

[steveruizok]

A recurring pattern with tldraw is that a user will want to configure something that we don't expect to be configurable. Often these are constant values, i.e. the drag distance or some timing or default. Some of these, such as our styles, can be configured by users because they're objects. They can be imported and mutated before the editor is created.

import { STYLES } from '@tldraw/tldraw'

STYLES.color.push([ value: "neon", icon: "color" ])

This PR moves all of our constants into one big object. (Well, technically two objects for the editor and tldraw packages).

Now all values, even primitive values, can be configured.

import { tldrawConstants } from '@tldraw/tldraw'

tldrawConstants.TEXT_PROPS.lineHeight = 1.5

Change Type

• sdk — Changes the tldraw SDK
• feature

Release Notes

• Move constants to editorConstants and tldrawConstants

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
examples	✅ Ready (Inspect)	Visit Preview	Apr 29, 2024 8:39pm

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
tldraw-docs	⬜️ Ignored (Inspect)	Visit Preview	Apr 29, 2024 8:39pm

[mimecuvalo]

Speaking of constants (and maybe this is piling on too much to this PR/discussion!) but I would really love this aspect of tldraw to be configurable when it comes to constants:
Linear bug: https://linear.app/tldraw/issue/TLD-2060/editor-api-styles-enum-isnt-easy-to-access

Quote:

When trying to wire up a custom app, it seems like styles like colours, fill, etc. aren't easily accessible.
When using a function like editor.setStyleForNextShapes(DefaultColorStyle, 'red'); I don't want to use the string 'red' directly but an enum of available colors to me. (Same goes for fill style, or any other style)

And also maybe it's overridable, maybe not 😬

I'm bringing it up because if we're gonna rework this it's worth considering how that would fit into the overall story here.