What are best practices for managing frequent updates across a tree of objects?

[taybenlor]

This weekend I built a small practice project, I'm relatively familiar with React and Three separately and so have been interested in react-three-fiber. The project was a simulation, following a React style I decided to have a state object outside the render tree, that I would then pass in by props each time it changed. I had something like this:

export type SimulationData = {
  bacteriaArray: BacteriaData[];
};

export type BacteriaData = {
  key: string;
  position: THREE.Vector3;
  velocity: THREE.Vector3;
  rotation: THREE.Euler;
  rotationVelocity: THREE.Vector3;
  age: number;
  temp: number;
};

I updated the SimulationData using a tick method that went through and updated all the bacteria based off a time delta. It also handled other things like creating new bacteria, bouncing the bacteria when they went outside my stage, things like this.

Then I had two main components Sim and Bacteria. Sim rendered a list of Bacteria in a group and Bacteria rendered a mesh.

The approach I took was clearly wrong, but it went something like this in Sim:

const [sim, setSim] = useState(Simulation.create());

useFrame((state, delta) => {
  const newSim = Simulation.tick(sim, delta);
  setSim(state);
})

I saw that the docs said not to call setState inside useFrame but I wanted to give it a go anyway, since this seemed the most intuitive. This performed really poorly. I'm guessing because my tree of components had to be fully re-rendered each frame, which had a bunch of overheads. I ended up taking this approach as it seemed intuitive to me as a good functional react style.

To get it performing well I moved all the updating to be within each Bacteria component, and they directly updated their own group using a ref rather than using props to update their position etc.

The issue I ran into was that all the state information was trapped inside the Bacteria component, the parent component couldn't know about it. This made it difficult to operate on the whole simulation at once, making this harder to work with than a traditional scene graph.

It seemed like useFrame was appropriate for managing updates when they are localised to just the current component, but when things need to sync across multiple components it didn't really fit anymore. I can see that there are react-three-fiber physics libraries - so this kind of thing must be possible! I just couldn't figure it out.

So that brings me to my question:

What are best practices for managing frequent updates across a tree of objects?

[drcmda]

https://docs.pmnd.rs/react-three-fiber/advanced/pitfalls

in principle you always go useFrame if you need to update something at high rate, always without exception. you don't setState in it because why would you? all it would cause is a needless back and forth. in useFrame you mutate the view, just like the frameloop in a three vanilla app would.

it then does not matter where state comes from, if it's local or remote. if your state is remote (for instance a state manager) then you can access it throughout the component graph, but you don't bind components to it, you merely read from it in useFrame and apply it.

[taybenlor]

Thanks, this is really helpful!

But it seems like this approach removes the benefit of the render tree in React?

The conceptual power of React is the idea that you have a pure function that takes in props and outputs a rendered object. You can nest these structures and know that data only goes down the tree and you'll never have individual component state go out of sync with the rest of the tree.

It seems like what you're suggesting is that I need to render and synchronise in two places. One is automatic within the React render tree. The other is manual within useFrame mutating my rendered state based off references to external state. This seems like an easy way to introduce bugs and have things go out of sync?

you don't setState in it because why would you? all it would cause is a needless back and forth

In this case the idea is that the parent component Sim would update its state every tick, and then use the natural result of the render tree to pass props to its children. To me this seems like an intuitive and typical way to use the React render tree.

[drcmda]

the dom is event driven, slow declarative state makes sense there. the moment you animate you would also move out of that, you would never call setState in a loop. react is too slow for that, but even if it weren't, it would not make much sense in a loop based context.

three is loop based and you need a clear régime to handle that. you don't update things with single declarative props because

• it is important when things are changed (before or after render) and this has to be composable
• you can't just += 0.1 sth because it would run slower or faster depending on the monitors refresh rate, you need deltas
• without dirty flags (needsUpdate) many prop changes would do nothing at all
• there will always be imperative function calls (lookAt, etc) or calculations in threejs

useFrame for loops, slow state as declarative props, or both:

const ref = useRef()
// flag state
const [hover, hovered] = useState(false)
// turning local flag state into animation
useFrame(() => {
  ref.current.color.lerp(v.set(hovered ? "green" : "blue"), 0.1)
})
return ...

[drcmda]

ps. i've been asking react for an official means: facebook/react#18499 but this has more to do with mutating a view that's guaranteed to be static. a framework just updating stuff with setState without overhead would not work for threejs.

[taybenlor]

Thanks, this is really helping me develop a mental model of how I should use @react-three/fiber. I've also been looking at how the APIs for Zustand and @react-three/cannon work. I'm thinking now that I should use Props and the render tree as a way to describe my object tree (e.g. create meshes, and set static properties), but not as a way to describe any frequently updated properties (e.g. physics). Those should be handled via refs and external state, then updated by directly mutating the object in something like useFrame or through subscriptions.