在 DOM 主机中自定义 React 渲染器的目的是什么？答案

【问题标题】：What is the purpose of a custom React renderers within a DOM host?在 DOM 主机中自定义 React 渲染器的目的是什么？
【发布时间】：2020-12-30 19:54:28
【问题描述】：

前奏

我们都熟悉 React 自带的默认渲染器——ReactDOM。

我们还有自定义的 React 渲染器，可用于与不是 DOM 环境的"hosts" 交互，例如移动设备（著名的 React Native）、VR 设备、终端（比如ink)，等等。

但是，在浏览器主机中，有一些自定义渲染器在 ReactDOM 内（或代替）运行。

核心问题

在浏览器主机中运行的自定义渲染器的目的是什么？

示例

在浏览器主机中运行的自定义渲染器的一些值得注意的例子是：

react-three-fiberthreejs 元素中的以下 sn-p 元素在 React 中声明，并且在后台它将“映射”到特定的画布操作：

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

react-three-fiber 正在使用自定义渲染器来实现上述目的，但我认为它也可以通过副作用来实现。 Box 可以有一个useEffect，它对threejs 实例执行操作。

可能性/假设

那么为什么选择自定义渲染器？我相信它可能是以下零个、一个或多个：

绕过生命周期/副作用会带来一些性能提升吗？
对排序和安装/卸载进行更严格的控制？
代码的简单性，在设置自定义渲染器的初始障碍之后，其余的映射变得更容易了吗？

【问题讨论】：

这可以回答它：twitter.com/0xca0a/status/1282999626782650368 但是当你意识到 react 与 dom 没有任何关系时，它会有更多的深度。它甚至不依赖它。 react 是一个跨平台的组件标准。所以 react-dom 将 react 翻译成 dom 与将 react 翻译成 konva、three、android、ios、windows、linux、gtk、shell 等一样有意义。
太棒了 - 谢谢@hpalu（这些是我正在寻找的讨论和思考过程）。它是一个非常好的首发

标签： reactjs react-fiber

【解决方案1】：

在 React 中使用自定义协调器有一些有趣的优势。正如您在 react-pixi-fiber 的 README.md 文件中看到的那样，完全可以使用 ReactDOM 来渲染 pixi 元素，而不是使用 react-pixi-fiber 的自定义渲染。

为什么要创建自定义渲染器/协调器？

在这种特殊情况下，原因是 ReactDOM 并没有真正处理画布元素。正如您所说，这可以通过自定义挂钩/组件的组合来实现。如果您阅读 react-three-fiber 的 why 部分，您会发现通过使用他们的自定义协调器，与自定义组件相比，您可以实现两件事：

threejs 中的所有内容都可以在这里工作，因为支持已内置于协调器中。
性能与直接使用 threejs 时相同，因为协调器可以更好地控制渲染的内容和时间。

您可以查看here，其中深入解释了渲染和协调之间的区别以及协调器如何细粒度访问：组件生命周期、决定差异以及如何从视图中添加/删除元素（在 DOM、canvas、iOS 等中）。

【讨论】：

【解决方案2】：

传统的反应渲染器公开两个函数：render(children, target) 和 unmountComponentAtNode(target)。 react-three-fiber 实际上也导出了这两个，它可以像那样使用，但是threejs 特别需要大量的设置和样板文件，这更容易在“Canvas”组件中抽象。该组件担心设置所有内容、调整大小、事件等。它在 DOM 和 react-native 中工作。

Canvas 组件中的所有内容都再次成为常规的 React。您拥有原生元素（网格、组......）、组件、钩子等。因此，当您在 Web 或其他任何地方使用 React 时，您将获得与 React 相同的好处：将关注点打包成可重用、自我管理的组件。

我在上面发布了这个：twitter.com/0xca0a/status/1282999626782650368 这应该很清楚为什么 React 总是比命令式布局膨胀更合适。

【讨论】：