跳到主要內容

React Native 核心貢獻者峰會 2024 回顧

·10 分鐘閱讀時間
Michał Pierzchała
Michał Pierzchała
Callstack 技術主管
Szymon Rybczak
Szymon Rybczak
Callstack 軟體工程師
Mo Javad
Mo Javad
Theodo 行動裝置主管 (英國)
Steven Moyes
Steven Moyes
Microsoft 資深產品經理

每年，React Native 社群的核心貢獻者都會與 React Native 團隊齊聚一堂，共同塑造此專案的方向。

去年也不例外，只有一個小小的例外。我們通常在 React Universe Conf (前身為 React Native EU) 前一天，在弗羅茨瓦夫的 Callstack 總部會面。在 2024 年，我們從過去的經驗中學習，將峰會舉辦了連續兩天，以便我們有更多非結構化的時間在一起。

all-participants

這項年度傳統已成為貢獻者分享見解和表達疑慮的寶貴機會，也讓核心團隊能夠分享其計畫，並從 React Native 生態系統的主要貢獻者 (包括合作夥伴公司、個別程式庫作者和朋友) 那裡收集意見回饋。

我們將峰會分為兩個軌道，涵蓋以下主題

在本部落格文章中，我們想讓您先睹為快這次聚會的成果。

發布​

我們針對 React Native 的發布流程進行了廣泛的討論。核心團隊感謝 Meta 以外的貢獻者參與發布的價值，並強調擁有每晚發布版本的重要性，這對於樹狀結構外平台 (如 React Native visionOS)、程式庫維護者 (Reanimated) 和框架 (Expo) 特別有益。我們討論了發布頻率，有些人要求更頻繁的發布以更快地發布修正，而另一些人則對第三方程式庫的影響和升級工作表示擔憂。

我們還集思廣益，討論如何減少意外的重大變更，並改善關於 React Native 和第三方依賴性之間相容性的溝通。

本次會議顯示了管理 React Native 發布的複雜性，以及考慮到需要考慮生態系統的所有不同部分，這個主題是多麼的微妙。

全新架構之後的下一步是什麼？​

既然全新架構已穩定發布，我們討論了接下來應該關注的重點。下一個重大事項可能是什麼？主題圍繞在

  • Web 相容性 – 在關於 React Strict DOM 專案方向的討論中總結，該專案應被視為暫時的 polyfill，而 Xplat 團隊則在 React Native 核心中實作正確的跨平台功能。
  • 穩定核心 API – 結果證明，我們需要對這對應用程式開發人員、程式庫作者、樹狀結構外平台意味著什麼達成更多共識。例如，可能需要從共用的 C++ 程式碼庫中提取 iOS 和 Android 的平台原生邏輯。其中一部分已在 LeanCore 2.0 的討論中涵蓋。
  • 舊架構支援 – 如預期的，團隊確認基於並行渲染的新 React 19 功能將無法在舊架構中運作。新功能主要針對新架構。由於 React 19 發布時程中的阻礙，目前仍不清楚在哪裡劃分新舊架構都支援的功能之間的界線。
  • React Native 的第三方程式庫 – 今天，我們程式庫作者可以使用 TurboModules、ExpoModules、最近的 Nitro 模組來實現橋接原生平台功能的相同目標。我們需要關於如何做好這件事的更佳文件。
  • Brownfield 文件 – 在峰會召開時，將 React Native 整合到原生應用程式的官方文件相當過時。從那時起，團隊就遵循了適用於 Android 和 iOS 的最新且更簡單的文件。
  • Metro web 的 Tree-shaking – 核心 Metro 團隊樂於合併 Expo 團隊在這方面的工作成果。

原生模組的 Web API​

本次會議專門討論 Microsoft 關於將 Web API 的子集引入 React Native 的 RFC。它旨在透過利用熟悉的 API 來增強 React Native 的可擴展性並吸引更多 Web 開發人員。開放存取大量現有的開放原始碼 Web 程式庫，這些程式庫沒有明確的 React Native 支援。

web-apis

標準化 Web API 規格不僅有益，而且對於 React Native 的成長至關重要，並且與我們的多平台願景和 react-strict-dom 專案非常一致。Web 透過其規格提供統一的介面，而 React Native 社群模組目前缺乏這種介面。Microsoft 已識別出約 200 個重要的 Web API，可以首先為他們支援的平台實作：iOS、Android、Windows 和 macOS。

我們鼓勵程式庫開發人員盡可能使其 API 與 Web 規格保持一致，因為這種標準化將改善跨平台的程式碼可移植性和開發人員體驗。

雖然該提案似乎對 React Native 的未來有利，但我們仍在集思廣益，討論下一步的行動。我們注意到的一個顧慮是 API 的治理，以及它們是否需要與平台實作分開儲存在不同的儲存庫中。另一個顧慮是，如果特定平台允許 W3C 未指定的行為，則會與官方規格產生分歧。我們需要弄清楚如何避免捆綁不必要的模組，例如使用 Babel 外掛程式。更不用說這項倡議的範圍相當大。

本次會議的結論強化了兩個重點：首先，整個 React Native 社群在盡可能採用 Web 相容規格方面達成了高度共識。其次，我們需要建立明確的技術策略，說明如何為不同的平台單獨維護這些 Web API 實作。Microsoft 可以與 Callstack 合作，完善原始 RFC，並針對少數 API 產生概念驗證實作，作為社群倡議。這種漸進式方法將有助於我們在擴大範圍之前驗證設計和開發人員體驗。

LeanCore 2.0​

2019 年，React Native 團隊啟動了 Lean Core 倡議。目標是解決 React Native 核心的表面區域，並減少過時和舊有的 API 和組件。從那時起，React Native 組件和 API 表面就早就應該進行另一輪清理了。

今天，有許多組件沒有積極維護，而是有更佳的社群替代方案。此外，還有一些組件有重複項，最終應合併以提高可維護性。

在 API 方面，許多 JS 層 API 都與原生 iOS 和 Android 實作綁定，而不是真正與平台無關。例如，對於 Pressable，我們有 android_disableSound 和 android_ripple 等 props。理想情況下，React Native 組件應具有不與任何特定平台綁定的最小可能 API 表面。

隨著樹狀結構外平台的成長並被生態系統更多地採用，需要有一條路徑來縮減 React Native 核心的組件和 API 表面，減輕 React Native 核心團隊的負擔，並使樹狀結構外平台和程式庫維護者更容易保持最新狀態。

作為額外的好處，這將使初學者應用程式開發人員更容易上手 React Native，因為他們需要學習的重複組件和「陷阱」更少。如果存在更佳的社群替代方案，則可以指示開發人員並鼓勵他們使用可用的社群替代方案。

在會議期間，我們討論了

  • Lean Core 的高階動機以及對相關方 (開發人員、程式庫維護者、Meta) 的好處
  • 在一些真實世界的生產 React Native 應用程式中使用的組件的匯總檢視
  • 從核心中移除候選組件的標準
  • 執行 Lean Core 2.0 的明確行動計畫，包括
    • 淘汰的高階流程
    • 處理 Meta 在內部使用具有更佳社群替代方案的組件的情況，

作為下一步，核心貢獻者小組將研究收集更多遙測和資料、評估社群替代方案，並彙編一份 RFC，詳細說明擬議的變更。

Nitro 模組 - 透過將 props 公開為 jsi::Values 來解除封鎖檢視組件​

最近，Marc Rousavy 引入了 Nitro 模組，作為建立原生模組的替代方法。Nitro 模組利用實驗性的 C++ Swift Interop，並結合了許多增強功能，可以在某些情況下提高效能。但是，在本次會議期間，我們討論了 Nitro 模組與現有 TurboModules 之間涉及的各種權衡取捨。

雖然 Nitro 模組提供了一些效能優勢，但它們也存在需要解決的限制和考量。例如，使用實驗性互通功能可能會引入 TurboModules 中不存在的複雜性或相容性問題。我們的討論重點放在這些權衡取捨，以及將 Nitro 模組的一些改進向上游導入 React Native 核心的可能性，這可以讓開發人員受益於適用於所有人的更高效能模組。

樹狀結構外平台與 CocoaPods​

樹狀結構外平台展現了 React Native 的全部威力，我們可以在行動裝置、桌上型電腦甚至 VR/XR 裝置上運行的不同平台之間共用一個 JS 程式碼庫。目前建立這樣的平台並不是最容易的過程，實際上沒有關於如何建立、開發和維護事物的指南。此外，React Native Core 在某種程度上與 Android 和 iOS 平台綁定。未來，我們的目標可能是實現所有平台都受到同等對待，並透過相同的 API 與 C++/JS 核心整合的場景。

oot-platforms

在本次會議期間，不同平台的維護者討論了問題、他們遇到的困難以及統一建立和維護新樹狀結構外平台的流程的解決方案應該是什麼。

本次會議的另一個方面是討論 CocoaPods 以及與管理原生依賴性相關的未來計畫。最近，CocoaPods 團隊宣布他們已轉為維護模式，並且不會發布新的重大改進或功能。可以使用各種替代方案，在本次會議期間，我們討論了它們的優缺點，以及遷移會是什麼樣子。

桌面上的 React Native​

來自 Microsoft 的 Steven 和 Saad，react-native-windows 和 react-native-macos 的維護者，主持了一次會議，以聽取和收集貢獻者關於桌面平台的意見回饋。討論的主題包括探索如何提高 React Native 在桌上型電腦上的採用率 (例如在 Visual Studio 中擁有專用的工作流程，或將桌面公開為 Nx 的一部分)，以及如何支援 Expo，這一直是提高採用率的持續痛點。

macOS 和 Windows 之間社群模組的可用性存在很大差異，這主要是因為 iOS 程式碼大多與 macOS 相容，而 RNW 則需要客製化的實作。在為 Windows 版 React Native 開發全新架構時，團隊看到了 C++ 模組的潛力，它可以實現跨平台更廣泛的程式碼共用，這有望減輕針對桌面平台的負擔。值得注意的是，在社群方面，Software Mansion 正在努力為他們最受歡迎的模組 (例如 React Native Screens、Gesture Handler 和 Reanimated) 新增桌面支援。

我們仍然對幾天的時間一起度過幾個小時，就能產生如此多的知識共享和跨領域的想法交流印象深刻。在本次峰會期間，我們為將幫助我們改進和重塑 React Native 生態系統的倡議播下了種子。

如果您有興趣加入 React Native 的開發，請務必加入我們的開放式倡議，並閱讀我們網站上的 貢獻指南。我們希望在未來也能與您親自見面！