CSSValueInput used useEffect and executed onChange etc events on its
own. What in case of any small changes caused loops and strange
behavior. Now should execute everything only as a result of user input.
`parseCssValue` - now stupid parse CSS value and someday will be used
only inside text-control.
setProperty - now accepts StyleValue, the string param is deprecated,
warning set.
CSSValueInput now not update styles during editing.
unit menu now not hiding during formulas etc
fixed bug with updating style on newly created items
fixed scrub bugs with unsubscribing
css-tree Adds 52101 gzip bytes.
A lot of size is coming from here
https://github.com/csstree/csstree/blob/97d7f3b95a3efd8f431af39986acc149dceefa59/lib/data.js
more than 1/3 of `esm` size (20+kb gz), and most huge are properties
json we need and use.
Doesn't look tree-shakeable, anyway can be loaded lazily as until
editing we don't need to validate CSS vars.
Investigating:
- [x] - Changing any style Combobox with mouse cause multiple value
updates to previous and current value (was a blur event issue)
Right now our build and CI take a lot of time. 1:40min - 2min on CI and
1min locally. We spend time on vercel, on main CI, on publish and
locally.
At the moment in packages anything outside of src folder is not checked
because of rootDir.
We have to generate "references" field on precommit.
All these issues can be avoided if remove .d.ts generation completely
and specify sources in "types" field. This way we get zero build time
for types and can switch to other build tool (like esbuild) for .js
generation and get almost instant build on vercel, on main CI and on
publish.
Downsides
- it can be slower (actually not really caz we delete .tsbuildinfo cache
anyway and we can still generate it with incremental flag)
- it contraditcs recommended practices for published packages (we can
generate .d.ts in publish script only and use "types" as source
internally)
Ivan Starkov