(Die unveränderliche Engine, React

Es gibt viele Spiel-Engines auf der Welt: Unreal Engine, Unity Engine, Godot Engine, Cry Engine und mehr.

Was haben diese Spiel-Engines gemeinsam? Anpassbarkeit. Unterschiedliche Spiele haben unterschiedliche Anforderungen und benötigen bestimmte Funktionen, um ihre Ziele zu erreichen. Es ist schwierig, alle möglichen Funktionen in einem einzigen Programm bereitzustellen, weshalb Entwickler bei vielen Engines den Quellcode ändern und eigene benutzerdefinierte Funktionen erstellen können. Anpassung ist ein wesentlicher Bestandteil dieser Motoren.

Jetzt kehren wir zur Frontend-Entwicklung zurück. React ist eines der beliebtesten Frameworks in diesem Bereich. Aber ist es ebenso üblich, den internen Quellcode von React in der Frontend-Entwicklung zu ändern, so wie es in der Spieleentwicklung üblich ist? Diese einfache Frage verrät viel darüber, was wir wirklich verfolgen und verdeutlicht den Richtungsunterschied zwischen der modernen Frontend-Entwicklung und anderen Bereichen.

React ist ein Framework, das nahezu unmöglich zu ändern ist. Wir empfehlen Ihnen, React so zu verwenden, wie es ist, und es ist nicht für Entwickler vorgesehen, die interne Architektur oder Rendering-Pipeline anzupassen. Daher bedeutet die Verwendung von React, dass Sie alle Ihre Anforderungen innerhalb der Grenzen der React-Struktur lösen müssen. Aber die Welt ist voller unterschiedlicher Anforderungen, und nicht alle davon können im Rahmen von React gelöst werden.

„So etwas wie ein kostenloses Mittagessen gibt es nicht.“
„Es gibt kein Tool, das alles kann.“

React ist nur ein Entwicklungstool, und es hat seine Grenzen.

Der Hauptgrund, warum Entwickler React verwenden, ist die Produktivität. React wurde mit der Frage erstellt: „Wie können wir DOM-Komponenten in der Webentwicklung effizienter entwickeln?“ Im Zentrum des React-Ansatzes steht das DOM. So wie automatisierte Funktionen im Allgemeinen einen Mangel an Anpassung bedeuten, bedeutet die „Produktivität“, von der sie sprechen, oft, dass „Sie die Rendering-Schleife, die eng mit dem Browser verbunden ist, nicht über das virtuelle DOM ändern können.“

Das erste große Problem bei React ist das DOM. Nicht alles dreht sich um das DOM und nicht jedes Programm arbeitet ausschließlich um das DOM herum. Dennoch stellt React das DOM in den Mittelpunkt seiner Philosophie. Die JSX-Syntax, bei der jede Komponente etwas „HTML-Element-ähnliches“ zurückgibt, spiegelt diese Denkweise deutlich wider.

Das zweite Problem ist das virtuelle DOM. So funktioniert das virtuelle DOM:

• Das DOM ist von Natur aus langsam.
• Um dies abzumildern, führt React eine schnellere interne Logik ein.
• Diese Logik erstellt ein Objekt, das die Form des tatsächlichen DOM-Baums kopiert, der als virtuelles DOM bezeichnet wird. Bei jedem Rendering findet React die Änderungen mithilfe dieses virtuellen DOM und aktualisiert nur diese Teile.
• Um dieses System zu implementieren, müssen DOM-Updates immer über das Root-DOM-Element erfolgen.
• Das Virtuelle DOM arbeitet nahtlos mit den internen Abläufen von React zusammen.

Die Frage ist, warum HPSE überhaupt ein solches System einführen sollte? Neben der Sorge, dass dieser Rendering-Ansatz verschiedene HPSE-Anforderungen nicht erfüllen kann, besteht die größere Sorge darin, dass er in diesem Zusammenhang keinen tatsächlichen Nutzen bietet.

In HPSE können DOM-Komponenten auf Klassenebene verwaltet werden. Wenn eine Instanz erstellt wird, wird ihre Div-DOM-Referenz der obersten Ebene als Mitgliedsvariable gespeichert. Die privaten Methoden der Instanz können die DOM-Referenz entweder direkt manipulieren oder mit querySelector() darauf zugreifen. In den meisten Fällen wäre dies schneller als der Vergleich des gesamten DOM-Baums.

Die Verwendung des virtuellen DOM ist lediglich eine Möglichkeit, Änderungen zu identifizieren. Wenn Sie die Änderungen jedoch bereits intern in Ihrer Instanz gespeichert haben, ist eine erneute Suche nach ihnen überflüssig. Sobald das DOM-Element aktualisiert ist, löst der Browser weiterhin ReFlow und RePaint aus, sodass es danach keinen Unterschied in der Leistung gibt.

Das ultimative Problem liegt in den „internen Abläufen“ von React. Was genau sind diese internen Vorgänge? Es mangelt an detaillierter Dokumentation oder Informationen und die meisten Frontend-Entwickler verstehen diese auch nicht vollständig. Der Browser-Client arbeitet bereits innerhalb der Abstraktionsschicht des Browsers selbst, was ihn für verschiedene Herausforderungen anfällig macht. Die undurchsichtigen und nicht veränderbaren internen Prozesse von React verschärfen diese Schwachstelle nur.

Änderungen an Komponenten in React müssen über das virtuelle DOM erfolgen, und das virtuelle DOM wird von der Fiber-Architektur verwaltet, die bestimmten Prioritätsregeln folgt. Es gibt jedoch kaum Dokumentation darüber, wie die internen Funktionen von React angepasst werden können, um die Anforderungen an Echtzeitleistung oder präzises Timing von HPSE zu erfüllen. Es fühlt sich an, als würde man ein AAA-Spiel mit einer Engine entwickeln, die nicht angepasst werden kann.

„Warum sich die Mühe machen?“

Das ist eine Frage, die immer wieder auftaucht.

React ist intern so eng gekoppelt, dass Sie es selbst dann nicht ändern könnten, wenn Sie es ändern wollten. Es wurde nie für diesen Zweck entworfen. Darüber hinaus ist React aufgrund der starken Kopplung von Rendering und Statusaktualisierungen nicht für HPSE-Projekte geeignet, bei denen nicht-visuelle Komponenten wie Daten oder 3D-Elemente neben DOM-Elementen verwaltet werden müssen.

In HPSE ist der Zeitpunkt von Ereignisaufrufen und Speicher-Unmounts möglicherweise nicht an einzelne Komponenten gebunden, aber React erzwingt diese komponentenbasierte Struktur, was die Bewältigung solcher Anforderungen erschwert. Das Design von React, bei dem Zustandsänderungen in Komponenten den gesamten Rendering-Baum beeinflussen können, steht auch im Widerspruch zu der Notwendigkeit von HPSE, solche Auswirkungen zu minimieren oder zu kontrollieren.

Bibliotheken wie React Three Fiber (R3F) ermöglichen es Ihnen, Instanzen wie Mesh oder Scene mit einer „HTML Element Like“-Syntax zu erstellen, aber das ist einfach Three.js, das an die Struktur von React angepasst ist. Das hohe Maß an Kopplung innerhalb von React verschlimmert nur das Problem der nicht veränderbaren Interna.

Der Event-Handling-Ansatz von React ist ebenfalls problematisch. React verwendet ein synthetisches Ereignissystem, um Browserkompatibilität und Konsistenz bei der Ereignisbehandlung sicherzustellen. Durch das Hinzufügen einer Abstraktionsschicht zur Ereignisverarbeitung schränkt dieses System jedoch die in HPSE erforderliche feinkörnige Kontrolle über Ereignisschleifen und Timing ein, was die Implementierung wesentlicher Optimierungen erschwert.

Diese Probleme entstehen, weil sich die Designphilosophie von React grundlegend von den Zielen von HPSE unterscheidet. React wurde nicht für HPSE entwickelt; Es wurde entwickelt, um die Entwicklung von Standard-Webclients zu optimieren. Wenn React eine ähnliche Richtung wie HPSE verfolgt hätte, wären seine Funktionen völlig anders gewesen, und es gäbe gute Gründe, es in die HPSE-Entwicklung zu übernehmen. Da ihre Ziele jedoch so unterschiedlich sind, trennen sich zwangsläufig ihre Wege.

Das soll nicht heißen, dass alles an React, wie Routing oder useEffect, schlecht ist. Tatsächlich können die meisten dieser Funktionen mithilfe eigenständiger JavaScript-Module oder -Codes implementiert werden. Im Gegensatz zu React erzwingen allgemeine JavaScript-Module keine spezifischen Pipelines oder Regeln für Projekte. Darüber hinaus können Sie, wenn sie Open Source sind, ihre Interna an Ihre Bedürfnisse anpassen.

Das obige ist der detaillierte Inhalt von(Die unveränderliche Engine, React. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!