Since `sheet.deleteObject()` doesn't actually delete the values
of the props of that object, I decided to rename it to `detachObject()`.
Also, the param `override` sounded too similar to the concept of value overrides,
so I renamed it to `reconfigure`.
* Implement an internal library for studio notifications
* Improve design a little
* Document code
* Change relative import to absolute one
* Fix tiny styling issue
* Add notifications playground
* Add notifications empty state and keep notifications buttons always visible
Also fix a bug related to not clearing the type and uniqueness checkers.
* Simplify notifications playground
* Treat window as optional in case it runs in server code
* Fix popover behavior when open and clicking on trigger
* Remove console log
* Resolve merge conflicts
* Remove destructuring in favor of property access
* Extract usePopover return type into an interface
* Fix merge
* Update dependencies which pass tests locally
* Break the yarn cache in an attempt to fix checks
* playground: Add wrapping error info for build.ts
* playground: Don't use dev mode in CI tests
* playground: Use tsc for typecheck
* playground: Specify working esbuild version 0.13.15
* playground: Use only promises in build.ts
* playground: Ensure serving in ci e2e
* Add echo for vercel for build:static
Before this commit, the exports field of `@theatre/r3f` was:
```
"exports": {
".": "./dist/index.js",
"./extension": "./dist/extension/index.js"
},
```
So users could import the extension from '@theatre/r3f/extension'
However, if the user’s bundler doesn’t support the exports field, they’d have to import from @theatre/r3f/dist/extension. There are 3 problems with this approach:
1. We have to ask users to try both paths and see which works for their bundler.
2. Users can’t copy code from each other if their bundler setups are different.
3. To make matters worse, if a user’s bundler supports exports, they can’t import from @theatre/r3f/dist/extension.
This is all confusing, so we're fixing it by exposing @theatrer/3f/dist/extension and not @theatre/r3f/extension. Uglier, but more consistent, and avoids the above 3 problems.
Remove cold derivation reads
Prior to this commit, the first render of every `useDerivation()` resulted in a cold read of its inner derivation. Cold reads are predictably slow. The reason we'd run cold reads was to comply with react's rule of not running side-effects during render. (Turning a derivation hot is _technically_ a side-effect).
However, now that users are animating scenes with hundreds of objects in the same sequence, the lag started to be noticable.
This commit changes `useDerivation()` so that it turns its derivation hot before rendering them.
Freshen derivations before render
Previously in order to avoid the zombie child problem (https://kaihao.dev/posts/stale-props-and-zombie-children-in-redux) we deferred freshening the derivations to the render phase of components. This meant that if a derivation's dependencies changed, `useDerivation()` would schedule a re-render, regardless of whether that change actually affected the derivation's value. Here is a contrived example:
```
const num = new Box(1)
const isPositiveD = prism(() => num.derivation.getValue() >= 0)
const Comp = () => {
return <div>{useDerivation(isPositiveD)}</div>
}
num.set(2) // would cause Comp to re-render- even though 1 is still a positive number
```
We now avoid this problem by freshening the derivation (i.e. calling `der.getValue()`) inside `runQueue()`, and then only causing a re-render if the derivation's value is actually changed.
This still avoids the zombie-child problem because `runQueue` reads the derivations in-order of their position in the mounting tree.
On the off-chance that one of them still turns out to be a zombile child, `runQueue` will defer that particular `useDerivation()` to be read inside a normal react render phase.
