跳到主要內容

一篇標記為 "events" 的文章

查看所有標籤

舊金山聚會回顧

·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 組件來利用基於 View Controller 的導航欄樣式。

還有一些注意事項需要牢記

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

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

閉幕詞​

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

  • Deco 宣布了他們的 React Native 展示，並邀請所有人將他們的應用程式添加到列表中。
  • 最近的文件全面改版獲得了讚揚！
  • Deco IDE 的創作者之一 Devin Abbott 將教授 React Native 入門課程。

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