跳到主要內容

舊金山聚會回顧

·9 分鐘閱讀時間
Héctor Ramos
Héctor Ramos
前 Facebook 開發者推廣工程師

上週我有機會參加在 Zynga 舊金山辦公室舉辦的 React Native 聚會。大約有 200 人參加，這是一個與我附近對 React Native 感興趣的其他開發人員交流的好地方。

我特別有興趣了解更多關於像 Zynga、Netflix 和 Airbnb 等公司如何使用 React 和 React Native 的資訊。當晚的議程如下

  • 在 React 中快速建立原型
  • 為 React Native 設計 API
  • 彌合差距：在現有程式碼庫中使用 React Native

但首先，活動以簡短的介紹和近期新聞回顧開始

如果這些聚會之一在您附近舉行，我強烈建議您參加！

在 Zynga 中快速建立 React 原型​

第一輪新聞之後，Zynga（今晚的主辦方）進行了簡短的介紹。Abhishek Chadha 談論了他們如何使用 React 快速建立行動裝置上新體驗的原型，並示範了一個類似 Draw Something 的應用程式的快速原型。他們使用與 React Native 類似的方法，透過橋接器提供對原生 API 的存取權。當 Abhishek 使用裝置的相機拍攝觀眾的照片，然後在某人的頭上畫了一頂帽子時，就示範了這一點。

在 Netflix 中為 React Native 設計 API​

接下來是今晚的首次專題演講。Clarence Leung，Netflix 的資深軟體工程師，發表了他關於為 React Native 設計 API 的演講。他首先指出人們可能會處理的兩種主要程式庫類型：元件（例如標籤列和日期選擇器）以及提供對原生服務（例如相機膠卷或應用程式內付款）存取權的程式庫。在為 React Native 建置程式庫以供使用時，可以採用兩種方法

  • 提供平台專用元件
  • 一個跨平台程式庫，針對 Android 和 iOS 具有類似的 API

每種方法都有其自身的考量，這取決於您來決定哪種方法最適合您的需求。

方法 #1

作為平台專用元件的範例，Clarence 談到了來自核心 React Native 的 DatePickerIOS 和 DatePickerAndroid。在 iOS 上，日期選擇器會呈現為 UI 的一部分，並且可以輕鬆嵌入現有的檢視中，而 Android 上的日期選擇器則以強制回應方式呈現。在這種情況下，提供個別的元件是有道理的。

方法 #2

另一方面，相片選擇器在 Android 和 iOS 上的處理方式類似。有些微差異 — 例如，Android 不會像 iOS 那樣將相片分組到資料夾中（例如「自拍」），但可以使用 if 陳述式和 Platform 元件輕鬆處理這些差異。

無論您決定採用哪種方法，最好盡可能縮小 API 介面並建置應用程式專用的程式庫。例如，iOS 的應用程式內購買框架支援一次性、消耗性購買以及可續訂的訂閱。如果您的應用程式只需要支援消耗性購買，您可以免除在跨平台程式庫中支援訂閱。

在 Clarence 的演講結束時，有一個簡短的問答環節。其中一個有趣的重點是，在 Netflix 為這些程式庫編寫的 React Native 程式碼中，大約 80% 在 Android 和 iOS 之間共用。

彌合差距，在現有程式碼庫中使用 React Native​

當晚的最後一場演講是由來自 Airbnb 的 Leland Richardson 進行的。演講重點是在現有程式碼庫中使用 React Native。我已經知道從頭開始使用 React Native 撰寫新應用程式有多容易，所以我非常有興趣了解 Airbnb 在其現有原生應用程式中採用 React Native 的經驗。

Leland 首先談到了綠地應用程式與棕地應用程式。綠地意味著開始一個專案，而無需考慮任何先前的成果。這與棕地專案形成對比，在棕地專案中，您需要考慮現有專案的需求、開發流程以及所有團隊的各種需求。

當您處理綠地應用程式時，React Native CLI 會為 Android 和 iOS 設定單一儲存庫，並且一切都能正常運作。Airbnb 使用 React Native 的第一個挑戰是 Android 和 iOS 應用程式各自擁有自己的儲存庫。多儲存庫公司在採用 React Native 之前需要克服一些障礙。

為了繞過這個問題，Airbnb 首先為 React Native 程式碼庫設定了一個新的儲存庫。他們使用持續整合伺服器將 Android 和 iOS 儲存庫鏡像到這個新的儲存庫中。在執行測試並建置套件後，建置成品會同步回 Android 和 iOS 儲存庫。這讓行動工程師可以在不改變其開發環境的情況下處理原生程式碼。行動工程師不需要安裝 npm、執行封裝器或記住建置 JavaScript 套件。編寫實際 React Native 程式碼的工程師不必擔心在 Android 和 iOS 之間同步其程式碼，因為他們直接在 React Native 儲存庫上工作。

這確實帶來了一些缺點，主要是他們無法發布原子更新。需要原生程式碼和 JavaScript 程式碼組合的變更將需要三個獨立的提取請求，所有這些請求都必須仔細地登陸。為了避免衝突，如果自建置開始以來 master 已變更，CI 將無法將變更登陸回 Android 和 iOS 儲存庫。這會在高提交頻率的日子（例如，當發布新版本時）造成長時間的延遲。

從那時起，Airbnb 已轉向單一儲存庫方法。幸運的是，這已經在考慮之中，一旦 Android 和 iOS 團隊習慣使用 React Native，他們就很樂意加速朝單一儲存庫邁進。

這解決了他們在使用分割儲存庫方法時遇到的大多數問題。Leland 確實指出，這確實會對版本控制伺服器造成更大的壓力，這對於規模較小的公司來說可能是一個問題。

導航問題​

Leland 演講的後半部分重點是一個我非常關心的主題：React Native 中的導航問題。他談到了 React Native 中大量的導航程式庫，包括第一方和第三方。NavigationExperimental 被認為是有前途的東西，但最終並不適合他們的用例。

事實上，似乎沒有任何現有的導航程式庫適用於棕地應用程式。棕地應用程式要求導航狀態完全由原生應用程式擁有。例如，如果使用者在呈現 React Native 檢視時工作階段過期，則原生應用程式應能夠接管並根據需要呈現登入畫面。

Airbnb 也希望避免在過渡期間用 JavaScript 版本取代原生導航列，因為這樣做可能會產生不協調的效果。最初，他們將自己限制在強制回應呈現的檢視中，但當涉及到在其應用程式中更廣泛地採用 React Native 時，這顯然會產生問題。

他們認為他們需要自己的程式庫。該程式庫名為 airbnb-navigation。該程式庫尚未開源，因為它與 Airbnb 的程式碼庫緊密相關，但他們希望在年底前發布它。

我不會詳細介紹該程式庫的 API，但以下是一些主要的重點

  • 必須預先註冊場景
  • 每個場景都顯示在自己的 RCTRootView 中。它們以原生方式在每個平台上呈現（例如，在 iOS 上使用 UINavigationController）。
  • 場景中的主要 ScrollView 應包裝在 ScrollScene 元件中。這樣做可讓您利用原生行為，例如點擊狀態列以在 iOS 上捲動到頂部。
  • 場景之間的轉換以原生方式處理，無需擔心效能。
  • 自動支援 Android 返回按鈕。
  • 他們可以透過 Navigator.Config 無 UI 元件利用基於檢視控制器的導航列樣式。

還有一些注意事項要記住

  • 導航列在 JavaScript 中不易自訂，因為它是原生元件。這是故意的，因為使用原生導航列是此類型程式庫的硬性要求。
  • 每當 ScreenProps 透過橋接器傳送時，都必須序列化/反序列化，因此如果在此處傳送過多資料，則必須小心。
  • 導航狀態由原生應用程式擁有（也是程式庫的硬性要求），因此像 Redux 這樣的東西無法操縱導航狀態。

Leland 的演講之後也進行了問答環節。總體而言，Airbnb 對 React Native 感到滿意。他們有興趣使用 Code Push 來修復任何問題，而無需通過 App Store，而且他們的工程師喜歡 Live Reload，因為他們不必在每次小變更後都等待原生應用程式重建。

總結​

活動以一些額外的 React Native 新聞結束

聚會提供了一個與社群中其他開發人員會面和學習的好機會。我期待著將來參加更多 React Native 聚會。如果您參加了這些聚會之一，請留意我，並告訴我我們可以如何讓 React Native 更適合您！