solidified `solid-three`

[bigmistqke]

Implementation of proxy-based threejs renderer, based on the exploration done in the zustand-to-store branch.

This branch deviates from the previous goal of staying close to r3f's codebase in favor of simplification and solidification

Similarities

• Props management
• Children/scene graph management

Differences

• Custom event handling.
• We only store the props of the component in the threejs instance (behind $S3C symbol)
• No central store.
• useThree returns canvas, threejs' webgl-renderer, camera, raycaster and scene.
• useLoader is a very minimal wrapper around createResource.
• Current implementation defaults the catalogue to {}.
  • extend(THREE) if you do not want to think about treeshaking.
  • I am working on a babel-plugin to create automatic extend calls.

[vorth]

Are these similarities and differences comparing this branch with zustand-to-store, or with main? The latter is more valuable.

I really don't have a clue how to assess the merits of this PR, sorry. We don't have a test suite, so I can't really do it empirically. There's not enough information in the PR to really understand the changes and any tradeoffs they imply.

We really need user documentation, or at least LOTS of sample code. I think we're still in the unfortunate situation that someone can't really predict how to use the library without understanding both its implementation AND the tooling transformation it requires.

Also, if you're still using "T.whatever", we don't need any custom tooling, and I'd prefer to keep it that way. Just give me sample code for the registrations.

BTW you should change the version number from "0.2.0" to anything else.

[bigmistqke]

Are these similarities and differences comparing this branch with zustand-to-store, or with main? The latter is more valuable.

In comparison with zustand-to-store. This initial commit was a very barebones implementation of a three-renderer for solid. I have since re-implemented a lot of the API react-three-fiber provides.

I really don't have a clue how to assess the merits of this PR, sorry. We don't have a test suite, so I can't really do it empirically.

I created testing utilities for solid-three (see ./src/testing) and ported the tests from react-three-fiber. We have some tests failing due to missing API, but I would consider these non-essential.

There's not enough information in the PR to really understand the changes and any tradeoffs they imply.

From userland there are currently little changes, now that I re-implemented most of the API, except from some internals

• useThree-value is more minimal
• event-objects/event-handlers are simpler. react-three-fiber makes a lot of objects during event-handling, I don't know if we should reproduce this.
• missing API:
  • onPointerMissed
  • PointerCapture
  • performance-prop in canvas

We really need user documentation, or at least LOTS of sample code. I think we're still in the unfortunate situation that someone can't really predict how to use the library without understanding both its implementation AND the tooling transformation it requires.

Yes, I agree. I (and chatgpt) provided jsdoc comments for most of the functions, also internal ones. But we need documentation/examples, for sure. A REPL would be very handy.

[bigmistqke]

Following api still needs to be implemented:

• [ ] context.clock
• [ ] context.size
• [ ] context.viewport
• [ ] second argument to useFrame to schedule
• [ ] key-property to force re-creation of three-element

Following api might be implemented (let's discuss)

• [ ] context.control
  • This value is not used in solid-three internals but is a convention by react-three-fiber so that other components can react to it. It is a bit awkward that it is purely by convention and cannot be enforced.
• [ ] context.performance
  • Again not a value that is used internally by solid-three, but instead is a value that can be used to orchestrate a performance downgrade from the consuming code. I am not sure if this is something that we need to provide, as it can be easily implemented userside with a simple context.