(The Unmodifiable Engine, React

世界上有很多游戏引擎：Unreal Engine、Unity Engine、Godot Engine、Cry Engine等等。

这些游戏引擎有什么共同点？可定制性。不同的游戏有不同的要求，需要特定的功能来实现其目标。在单个程序中提供所有可能的功能是很困难的，这就是为什么许多引擎允许开发人员修改源代码并构建自己的自定义功能。定制是这些引擎的重要组成部分。

现在，让我们回到前端开发。 React 是该领域最流行的框架之一。但是，正如游戏开发中修改引擎很常见一样，前端开发中修改React内部源代码也同样常见吗？这个简单的问题揭示了我们真正追求的很多东西，并凸显了现代前端开发与其他领域之间的方向差异。

React 是一个几乎不可能修改的框架。我们鼓励您按原样使用 React，并且它不适合开发人员自定义其内部架构或渲染管道。因此，使用 React 意味着你必须在 React 结构的范围内解决你的所有需求。但世界充满了各种各样的需求，并不是所有的需求都可以在 React 的框架内得到解决。

“天下没有免费的午餐。”
“没有任何工具可以完成所有事情。”

React 只是一种开发工具，它有其局限性。

开发人员使用 React 的主要原因是生产力。 React 是带着这样的问题创建的：“我们如何在 Web 开发中更有效地开发 DOM 组件？” React 方法的核心是 DOM。就像自动化功能通常意味着缺乏定制一样，他们谈论的“生产力”通常意味着“你无法通过虚拟 DOM 修改与浏览器紧密耦合的渲染循环。”

React 的第一个主要问题是 DOM。并非所有事物都围绕 DOM 展开，也并非每个程序都仅围绕 DOM 运行。然而，React 将 DOM 置于其哲学的核心。 JSX 语法中的每个组件都返回“类似 HTML 元素”的内容，清楚地反映了这种思维方式。

第二个问题是虚拟DOM。虚拟 DOM 的工作原理如下：

• DOM 本质上很慢。
• 为了缓解这个问题，React 引入了更快的内部逻辑。
• 此逻辑创建一个复制实际 DOM 树形状的对象，称为虚拟 DOM。每当渲染发生时，React 都会使用此虚拟 DOM 查找更改，并仅更新这些部分。
• 要实现这个系统，DOM 更新必须始终通过根 DOM 元素。
• 虚拟 DOM 与 React 的内部操作无缝配合。

问题是，为什么 HPSE 首先要采用这样的系统？除了担心这种渲染方法无法满足各种 HPSE 要求之外，更大的担忧是它在这种情况下缺乏实际实用性。

在 HPSE 中，DOM 组件可以在类级别进行管理。创建实例时，其顶级 div DOM 引用将存储为成员变量。实例的私有方法可以直接操作 DOM 引用，也可以使用 querySelector() 来访问它。在大多数情况下，这比比较整个 DOM 树要快。

使用虚拟 DOM 只是识别更改的一种方法，但如果您已经将更改存储在实例内部，则再次搜索它们是多余的。一旦 DOM 元素更新，浏览器仍然会触发 ReFlow 和 RePaint，因此之后的性能没有差异。

最终的问题在于React的“内部操作”。这些内部操作到底是什么？缺乏详细的文档或信息，大多数前端开发人员也没有完全理解它们。浏览器客户端已经在浏览器本身的抽象层中运行，使其容易受到各种挑战。 React 不透明且不可修改的内部流程只会加剧此漏洞。

React 中对组件的更改必须经过虚拟 DOM，而虚拟 DOM 由 Fiber 架构管理，遵循特定的优先级规则。然而，关于如何定制React内部函数以满足HPSE的实时性能或精确计时需求的文档却很少。感觉就像用无法定制的引擎开发 AAA 游戏。

“何苦呢？”

这是一个不断出现的问题。

React is so tightly coupled internally that even if you wanted to modify it, you couldn’t. It was never designed with that purpose in mind. Moreover, the strong coupling of rendering and state updates makes React unsuitable for HPSE projects, where non-visual components like data or 3D elements must be managed alongside DOM elements.

In HPSE, the timing of event calls and memory unmounts may not be tied to individual components, but React enforces this component-based structure, making it difficult to handle such requirements. React’s design, where state changes in components can affect the entire rendering tree, also conflicts with HPSE’s need to minimize or control such impacts.

Libraries like React Three Fiber (R3F) allow you to create instances like Mesh or Scene using an "HTML Element Like" syntax, but that’s simply Three.js adapted to React’s structure. The high level of coupling within React only worsens the issue of unmodifiable internals.

React’s event handling approach is also problematic. React uses a synthetic event system to ensure browser compatibility and consistency in event handling. However, by adding an abstraction layer to event processing, this system limits the fine-grained control over event loops and timing needed in HPSE, making it difficult to implement essential optimizations.

These issues arise because React’s design philosophy is fundamentally different from the goals of HPSE. React wasn’t built with HPSE in mind; it was designed to optimize the development of standard web clients. If React had pursued a similar direction to HPSE, its features would have been vastly different, and there would be a case for adopting it in HPSE development. But since their goals are so divergent, they inevitably part ways.

This isn’t to say that everything about React, like routing or useEffect, is bad. In fact, most of these features can be implemented using standalone JavaScript modules or code. Unlike React, general JavaScript modules don’t enforce specific pipelines or rules on projects. Moreover, if they are open-source, you can modify their internals to suit your needs.

The above is the detailed content of (The Unmodifiable Engine, React. For more information, please follow other related articles on the PHP Chinese website!