跳到主要內容

使用 React Native 建構 - Build.com 應用程式

·5 分鐘閱讀
Garrett McCullough
Garrett McCullough
資深行動工程師

Build.com 總部位於加州奇科，是最大的居家裝修用品線上零售商之一。該團隊擁有以網路為中心的強大業務已有 18 年，並於 2015 年開始考慮開發行動應用程式。由於我們團隊規模小且原生經驗有限，因此建構獨特的 Android 和 iOS 應用程式並不切實際。相反地，我們決定冒險嘗試非常新的 React Native 框架。我們的初始提交是在 2015 年 8 月 12 日，當時使用的是 React Native v0.8.0！我們於 2016 年 10 月 15 日在 App Store 上線。在過去兩年中，我們持續升級和擴展該應用程式。我們目前使用的是 React Native 0.53.0 版本。

您可以在以下網址查看該應用程式：https://www.build.com/app。

功能​

我們的應用程式功能齊全，包含您對電子商務應用程式的所有期望：產品列表、搜尋和排序、配置複雜產品的功能、我的最愛等等。我們接受標準信用卡付款方式以及 PayPal 和 iOS 使用者的 Apple Pay。

您可能沒想到的一些突出功能包括

  1. 約 40 種產品提供 3D 模型，並有 90 種表面處理
  2. 擴增實境 (AR) 讓使用者可以 98% 的尺寸準確度查看燈具和水龍頭在家中的外觀。Build.com React Native 應用程式在 Apple App Store 中以 AR 購物為特色！AR 現在適用於 Android 和 iOS！
  3. 協作專案管理功能，讓人們可以為專案的不同階段整理購物清單，並圍繞選擇進行協作

我們正在開發許多新的和令人興奮的功能，這些功能將繼續改善我們的應用程式體驗，包括下一階段的沉浸式購物與 AR。

我們的開發工作流程​

Build.com 允許每位開發人員選擇最適合他們的工具。

  • IDE 包括 Atom、IntelliJ、VS Code、Sublime、Eclipse 等。
  • 針對單元測試，開發人員負責為任何新組件建立 Jest 單元測試，並且我們正在努力使用 jest-coverage-ratchet 提高應用程式舊部分的覆蓋率。
  • 我們使用 Jenkins 來建構我們的 Beta 版和候選發布版。此流程對我們來說運作良好，但仍需要大量工作才能建立發布說明和其他成品。
  • 整合測試包括跨桌面、行動裝置和網路工作的共用測試人員池。我們的自動化工程師正在使用 Java 和 Appium 建構我們的自動化整合測試套件。
  • 工作流程的其他部分包括詳細的 eslint 配置、強制執行測試所需屬性的自訂規則以及阻止違規變更的 pre-push 鉤子。

應用程式中使用的函式庫​

Build.com 應用程式依賴許多常見的開源函式庫，包括：Redux、Moment、Numeral、Enzyme 和許多 React Native 橋接模組。我們也使用了許多 Fork 的開源函式庫；Fork 的原因是因為它們被棄用或因為我們需要自訂功能。快速統計顯示大約有 115 個 JavaScript 和原生相依性。我們想探索移除未使用函式庫的工具。

我們正在透過 TypeScript 新增靜態類型，並研究選用鏈結。這些功能可以幫助我們解決我們仍然看到的一些類別的錯誤

  • 類型錯誤的資料
  • 由於物件未包含我們預期的內容而未定義的資料

開源貢獻​

由於我們如此嚴重地依賴開源，因此我們的團隊致力於回饋社群。Build.com 允許團隊將我們建構的函式庫開源，並鼓勵我們回饋我們使用的函式庫。

我們發布並維護了許多 React Native 函式庫

  • react-native-polyfill
  • react-native-simple-store
  • react-native-contact-picker

我們也為許多函式庫做出了貢獻，包括：React 和 React Native、react-native-schemes-manager、react-native-swipeable、react-native-gallery、react-native-view-transformer、react-native-navigation。

我們的歷程​

在過去幾年中，我們看到了 React Native 和生態系統的蓬勃發展。早期，似乎每個版本的 React Native 都會修復一些錯誤，但會引入更多錯誤。例如，遠端 JS 除錯在 Android 上中斷了幾個月。值得慶幸的是，情況在 2017 年變得更加穩定。

我們反覆出現的一大挑戰是導航函式庫。長期以來，我們一直使用 Expo 的 ex-nav 函式庫。它對我們來說運作良好，但最終被棄用。但是，當時我們正處於大量功能開發階段，因此花時間更換導航函式庫並不可行。這意味著我們必須 Fork 該函式庫並修補它以支援 React 16 和 iPhone X。最終，我們能夠遷移到 react-native-navigation，並希望它能獲得持續支援。

橋接模組​

另一個重大挑戰是橋接模組。當我們剛開始時，缺少許多關鍵橋接器。我的隊友之一編寫了 `react-native-contact-picker`，因為我們需要在我們的應用程式中存取 Android 聯絡人選擇器。我們也看到許多橋接器因 React Native 內部的變更而損壞。例如，React Native v40 內部發生了重大變更，當我們升級我們的應用程式時，我必須提交 PR 以修復 3 或 4 個尚未更新的函式庫。

展望未來​

隨著 React Native 繼續成長，我們對社群的願望包括

  • 穩定和改進導航函式庫
  • 維護對 React Native 生態系統中函式庫的支援
  • 改善將原生函式庫和橋接模組新增至專案的體驗

React Native 社群中的公司和個人一直很樂意貢獻他們的時間和精力來改進我們所有人使用的工具。如果您尚未參與開源，我希望您會考慮改進您使用的一些函式庫的程式碼或文件。有很多文章可以幫助您入門，而且它可能比您想像的容易得多！