react-three-fiber
npm install react-three-fiber
React-three-fiber is a small React renderer for Three-js. Why, you might ask? React was made to drive complex tree structures, it makes just as much sense for Three as it makes for the Dom. Building a dynamic scene graph becomes so much easier because you can break it up into declarative, re-usable components with clean, reactive semantics. This also opens up the eco system, you can now apply generic packages for state, animation, gestures and so on.
Difference to react-three, react-three-renderer, react-three-renderer-fiber
This is a small reconciler config with a few additions for interaction and hooks holding it all together. It does not know or care about Three internals, it uses heuristics for objects and attributes, so that we can get away without creating a strong dependency. Three is constantly changing, we don't want to rely on a specific version or chase their release cycle. This library works with version 1 as well as their latest. At the same time we don't want to alter any rules, if something works in Three in a specific way, it will be the same here.
How it looks like ...
Copy the following into a project to get going. Here's the same running in a code sandbox.
Objects and properties
You can use Three's entire object catalogue and all properties. When in doubt, always consult the docs.
Shortcuts and non-Object3D stow-away
All properties that have a .set()
method (colors, vectors, euler, matrix, etc) can be given a shortcut. For example THREE.Color.set can take a color string, hence instead of color={new THREE.Color('peachpuff')
you can do color="peachpuff"
. Some set-methods take multiple arguments (vectors for instance), in this case you can pass an array.
You can stow away non-Object3D primitives (geometries, materials, etc) into the render tree so that they become managed and reactive. They take the same properties they normally would, constructor arguments are passed with args
. If you give them a name they attach automatically to their parent.
The following is the same as above, but it's leaner and critical properties aren't re-instanciated on every render.
You can nest primitive objects, good for awaiting async textures and such. You could use React-suspense if you wanted!
Piercing into nested properties
If you want to reach into nested attributes (for instance: mesh.rotation.x
), just use dash-case:
Extending or using arbitrary objects
When you need managed local (or custom/extended) objects, you can use the primitive
placeholder.
Events
THREE objects that implement their own raycast
method (for instance meshes, lines, etc) can be interacted with by declaring events on the object. For now that's prop-updates (very useful for things like verticesNeedUpdate
), hovering-state and clicks. Touch follows soon!
Gl data & hooking into the render loop
Sometimes you're running effects, postprocessing, etc that needs to get updated. You can fetch the renderer, the camera, scene, and a render-loop subscribe to do this.
Receipes
Handling loaders
You can use Reacts built-in memoizing-features (as well as suspense) to build async dependence graphs.
Dealing with effects (hijacking main render-loop)
Managing effects can get quite complex normally. Drop the component below into a scene and you have a live effect. Remove it and everything is as it was without any re-configuration.
Heads-up display (rendering multiple scenes)
useRender
allows components to hook into the render-loop, or even to take it over entirely. That makes it possible for one component to render over the content of another. The order of these operations is established by the scene-graph.
Managing imperative code
Stick imperative stuff into useMemo and write out everything else declaratively. This is how you can quickly form reactive, re-usable components that can be bound to a store, graphql, etc.
Then ...