首頁  >  文章  >  web前端  >  (不可修改的引擎,React

(不可修改的引擎,React

Patricia Arquette
Patricia Arquette原創
2024-10-03 18:21:02538瀏覽

(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 內部耦合非常緊密,即使你想修改它也無法修改。它的設計從來沒有考慮到這個目的。此外,渲染和狀態更新的強耦合使得 React 不適合 HPSE 項目,在 HPSE 專案中,資料或 3D 元素等非視覺元件必須與 DOM 元素一起管理。

在 HPSE 中,事件呼叫和記憶體卸載的時間可能與各個元件無關,但 React 強制執行這種基於元件的結構,這使得處理此類需求變得困難。 React 的設計中,元件中的狀態變化會影響整個渲染樹,這也與 HPSE 最小化或控制此類影響的需要相衝突。

React Three Fiber (R3F) 等函式庫可讓您使用「HTML Element Like」語法建立 Mesh 或 Scene 等實例,但這只是適應 React 結構的 Three.js。 React 中的高耦合度只會加劇內部不可修改的問題。

React 的事件處理方式也存在問題。 React 使用合成事件系統來確保瀏覽器相容性和事件處理的一致性。然而,透過在事件處理中添加抽象層,該系統限制了 HPSE 所需的事件循環和時序的細粒度控制,從而難以實現必要的最佳化。

出現這些問題是因為 React 的設計理念與 HPSE 的目標根本不同。 React 建置時並沒有考慮 HPSE;它旨在優化標準網路用戶端的開發。如果 React 追求與 HPSE 類似的方向,那麼它的功能將會有很大不同,並且有理由在 HPSE 開發中採用它。但由於目標如此不同,他們不可避免地分道揚鑣。

這並不是說 Rea​​ct 的一切(例如路由或 useEffect)都不好。事實上,大多數這些功能都可以使用獨立的 JavaScript 模組或程式碼來實現。與 React 不同,通用 JavaScript 模組不會在專案上強制執行特定的管道或規則。此外,如果它們是開源的,您可以修改其內部結構以滿足您的需求。

以上是(不可修改的引擎,React的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn