* 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.
This also temporarily removes `coreLogger`'s config from the public API One reason is that we don't have many logs that could benefit from suppressing (see diff) so the experimental API would not be useful to the user yet.
Also, the default config was suppressing useful warnings. Those warnings _would_ have been dead-code-eliminated in production mode anyway, so having a separate config to suppress them in dev mode makes it confusing.
Fixes P-171
* Minify r3f extension bundle, because it is expected by the React dead code elimination check, since we bundle React in it
* Add children to props, since it is required by React 18 types
* Fix getting context attributes for gl in ReferenceWindow
* Don't bundle threejs in extension
* Fix editor not responding to scene initialization
* Fix SnapshotEditor css
* Fix `process.env.version` in browser-bundles
- also fix tsdoc warns in mjs files
Co-authored-by: Fülöp Kovács <kovacs.fulop@gmail.com>
Co-authored-by: Cole Lawrence <cole@colelawrence.com>
* Change to `process.env.THEATRE_VERSION`
Co-authored-by: Fülöp Kovács <kovacs.fulop@gmail.com>
Co-authored-by: Cole Lawrence <cole@colelawrence.com>
Addresses the lack of options we currently have for surfacing issues in
our application via debugging tools. Prioritizes performance and
usability (visually) over clarity in some places that could have been
object mapped.
A logger with three separate audiences:
* `internal`: Logs for developers maintaining Theatre.js
* `dev`: Logs for developers using Theatre.js
* `public`: Logs for everyone
This logger supports:
* multiple logging levels (error, warn, debug, trace),
* multiple audience levels (internal, dev, public),
* multiple categories (general, todo, troubleshooting)
* named and keyed loggers (e.g.
`rootLogger.named("Project", project.id)`)
* console styling with deterministic coloring
* console devtool maintains accurate sourcemap link to logging origin
(e.g. `coreExports.ts:71` as opposed to `logger.ts:45` or whatever)
* swappable logger
* customizable filtering
* Accepts lazy `args`: `args: () => object` via
`logger.lazy.<level>("message", () => <expensive computation>)` (e.g.
`logger.lazy.debugDev("Loaded project state", () => ({ save: bigProject.exportToSaveable() }))`)
