What is the purpose of a custom React renderers within a DOM host?

Question

Prelude

We are all familiar with the default renderers that comes with React - ReactDOM.

We also have custom React renderers that can be used to interface with "hosts" that aren't the DOM environment, such as mobile devices (famously React Native), VR devices, the terminal (like ink), and so on.

However, there are some custom renderers that operate within (or instead of) ReactDOM while in a browser host.

Core question

What is the purpose of custom renderers that operate within the browser host?

Examples

Some notable examples of custom renderers that operate within the browser host are:

• https://github.com/michalochman/react-pixi-fiber
• https://github.com/react-spring/react-three-fiber

The following snippet from react-three-fiber threejs elements are declared in React and under the hood it will "map" to particular canvas operations:

<Canvas>
    <ambientLight />
    <pointLight position={[10, 10, 10]} />
    <Box position={[-1.2, 0, 0]} />
    <Box position={[1.2, 0, 0]} />
</Canvas>

react-three-fiber is using a custom renderer to achieve the above, but I think it could also be achieved with side effects. Box could have a useEffect that performs operations against the threejs instance.

Possibilities / assumptions

So why choose a custom renderer? I believe it may be zero, one, or more of the following:

• There is some performance gain by bypassing lifecycle/side effects?
• Tighter control over sequencing and mounting/unmounting?
• Simplicity of code, after the initial hurdle of setting up a custom renderer, the rest of the mappings become easier?

Cree

this could answer it: twitter.com/0xca0a/status/1282999626782650368 but there's some more depth to it when you realize that react has nothing whatsoever to do with the dom. it doesn't even have a dependency on it. react is a cross platform component standard. so react-dom, which translates react that to the dom, makes just as much sense as translating react to konva, three, android, ios, windows, linux, gtk, shell, etc. – Fairbanks

Fantastic - thanks @Fairbanks (these are the kind of discussions and thought processes I am looking for). Its a really good starter – Cree

Answer 1

There are some interesting advantages when it comes to using a custom reconciler in React. As you see in the README.md file of react-pixi-fiber, it's totally possible to use ReactDOM to render the pixi elements instead of using the custom render from react-pixi-fiber.

Why create a custom renderer/reconciler then?

In this specific case the reason is that ReactDOM doesn't really deal with canvas elements. As you said though, that could have been achieved by a combination of custom hooks/components. If you read the why section of react-three-fiber you will see that by using their custom reconciler you can achieve two things, compared to custom components:

1. Everything from threejs will work here, because the support is built into the reconciler.
2. The performance is the same as when using threejs directly, because the reconciler has more control over what is rendered and when.

You can take a look here where there's an in depth explanation of the difference between render and reconcile and how the reconciler has fine grained access to: components lifecycles, decides the diffing and how elements are added/removed from the view (be in DOM, canvas, iOS etc).

Coup

Answer 2

Traditionally react renderers expose two functions: render(children, target) and unmountComponentAtNode(target). react-three-fiber actually exports these two as well and it could be used like that, but threejs in particular needs a lot of setup and boilerplate which is easier to abstract in a "Canvas" component. That component worries about setting up everything, resize, events, etc. It works in the DOM and in react-native.

Everything inside the Canvas component is regular React again. You have native elements (mesh, group, ...), components, hooks, etc. So you get the same benefits that React offers when you use it on the web or anywhere else: packing concerns into re-usable, self-managed components.

I've posted this above: twitter.com/0xca0a/status/1282999626782650368 This should make it pretty clear why React can always be a suitable choice over imperative layout inflating.

Fairbanks