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

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


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).


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.