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 | ||
package.json | ||
README.md | ||
setupTests.js | ||
tsconfig.json | ||
ui.css |
@tldraw/ui
License
The source code in this repository (as well as our 2.0+ distributions and releases) are currently licensed under Apache-2.0. These licenses are subject to change in our upcoming 2.0 release. If you are planning to use tldraw in a commercial product, please reach out at hello@tldraw.com.