next solid-three
#12
next solid-three
#12
Conversation
This commit discards Nikhil Saraf's older architecture based on the SolidJS universal renderer, in favor of his newer approach that looks more like Threlte: https://github.com/nksaraf/react-three-fiber/blob/chess-solid-three/solid-example/src/components/ModernPiece.tsx This approach uses context to maintain the scene graph, thus avoiding the need for the universal renderer, which adds build-time complexity and a layer (or two) of abstraction. It also uses a "T" proxy object to instantiate the three.js objects and add them to the scene appropriately. Issues: The example seems to leave the canvas at some default size, rather than filling the viewport. This approach still has a dependency on "scheduler", an NPM package apparently created as a reusable React internal package. We might consider replacing that.
unclear why this is being done in the first place.
in core/events.ts the raycasting was checking for state.events.enabled, but this was being overwritten with events().
…lback> remove artefact from original useRef
…leRefObject<DomEvent | null> remove artefact from original useRef
circular dependency was causing type-errors
An endless effect was created by calling `props.onCreated` inside a useIsomorphicLayoutEffect. In the original r3f-code it is an IsomorphicLayoutEffect with empty dependency-array, but using onMount did not render any image.
I believe we can actually just remove the effect all together, since it originally in r3f never wanted to be re-run anyway.
rotate matrix add envMap to gems
was creating issues with drei's `<OrbitControls/>`
a bit of a silly property, since with solid-store we can just access the store directly, but handy when porting.
Use solid's utility functions `mergeProps` and `splitProps` to compose arguments, instead of de-structuring and spreading. This way reactivity is preserved.
…dren: JSX.Element }`
still remnant of experiment with suspending creation in case of Suspense
bc npm lifecycles are the worst.
and add complex git-command copy+pasted from https://stackoverflow.com/a/62192503/4366929 otherwise submodule's head would be detached after `git submodule update --remote --rebase`
devPreinstall still created a bug where `apps/playground` would error bc it wasn't able to read the package.json of drei (although the submodule was already cloned)
Sorry for the late response. It's funny you say that. That's one of the first things that I did when adapting this code. Here's an early version of the generalised proxy renderer. I haven't really bothered open sourcing it the up to date code because I'm working in a private monorepo with my app. I am running into performance issues, especially surrounding the way props are tracked when components are created. I would love to combine efforts. :) Also can you re-share the discord link? I can't open it. |
Implementation of proxy-based threejs renderer, based on the exploration done in the zustand-to-store branch: see #12 This branch deviates from the previous goal of staying close to r3f's codebase in favor of simplification and 'solidification'. How the props are managed (= applying jsx-props to three-instand and managing of the scene graph) and the Primitive-component are copied from the zustand-to-store branch. differences: - Custom event handling - Augment the threejs instance with far less in comparison then r3f: we only store the props of the component
This branch continues the
context-and-proxies-branch from @vorth in which he took the proxy-implementation from @nksarafsolid-three-chessbranch ofreact-three-fiber.This branch' intention is to remove all the dependencies and artefacts from
react, remove the dependency onzustandas an internal state manager in favour ofsolid/storeand streamline the code, while keeping as close as possible to r3f's v9 codebase.what has been done
.currentuseThreeworks different then r3f's, while they have selectors to subscribe to store-updates, with ouruseThreeis just a wrapper arounduseContext(ThreeContext), as we don't have to worry about unnecessary re-renders.corenow uses solid-store specific code to update the store, so the distinction betweencoreandsoliddirectory is further made unclear.const state = store.getState()and the like.store.subscribe()has been replaced bycreateEffect(on(() => store, () => {…}))which I am not 100% sure is the same.store. subscribemight be deep-tracking bc off the whole immutable-thing.applyPropsto prevent unnecessary creations/cleanups of effects withmapArray(() => Object.keys(props), ...)and checking if prop is possibly reactive (=== a getter or function)solid/index.tsis moved tosolid/renderer.ts.core/renderer.tsis removed. It contained some types it itself had inherit from the removed reconciler.ts, they have been moved tothree-types.ts.index.ts,solid/index.tscore/index.tsnow only export filesapplyPropsthree.js).prettierrchad the line"plugins": ["prettier-plugin-tailwindcss"]which caused my prettier to not function. I replaced our.prettierrcwith the one of r3f to prevent unnecessary differences between codebases.coreandsolid-repo back intocore, more closely mimicking r3f's project-structurecore/componentstocore/proxy(bc I thought it was a better parallel withreconcilerand i preferred how it looked lol)reflections
Currently our codebase is somewhere between r3f's main branch and v9. For example,Instanceis typed like the main branch, but we haveStageslike v9. Probably these changes happened after nikhil made his implementation (found pr when they made the change). Idk if we should pull everything closer to v9 or not. I think yes, but my previous attempts have all failed.Instance has been ported to current v9 implementation. Our codebase is now up-to-date.
As I said above; since we now have solid-store-related code throughout the codebase idk if it still makes sense to make the distinction between the two. I think mb it's best to just bring it back into 1 repo and try to mimic the structure as closely to r3f as possible, so we can at least manually compare the two when needed.I went ahead and merged those directories
I think it would probably be good to try out some more complex examples, to test out this version. Maybe port the examples of r3f.