f2d8fae6ea
This change hoists opacity out of props and changes it to a number instead of an enum. The change to a number is to make tldraw more flexible for library consumers who might want more expressivity with opacity than our 5 possible values allow. the tldraw editor will now happily respect any opacity between 0 and 1. The limit to our supported values is enforced only in the UI. I think this is limited enough that it's a reasonable tradeoff between in-app simplicity and giving external developers the flexibility they need. There's a new `opacityForNextShape` property on the instance. This works exactly the same way as propsForNextShape does, except... it's just for opacity. With this, there should be no user-facing changes to how opacity works in tldraw. There are also new `opacity`/`setOpacity` APIs in the editor that work with it/selections similar to how props do. @ds300 do you mind reviewing the migrations here? ### Change Type - [x] `major` — Breaking Change ### Test Plan - [x] Unit Tests - [ ] Webdriver tests ### Release Notes [internal only for now] |
||
|---|---|---|
| .. | ||
| src | ||
| api-extractor.json | ||
| api-report.md | ||
| CHANGELOG.md | ||
| editor.css | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
| setupTests.js | ||
| tsconfig.json | ||
tldraw/tldraw
Benchmark
To run the benchmarks
yarn workspace @tldraw/tldraw benchmark
Or
yarn workspace @tldraw/tldraw benchmark "file_search_string"