開源React Native組件庫beeshell 2.0發布

  • 2019 年 10 月 10 日
  • 筆記

總第357篇

2019年 第35篇

2018年，我們開源了React Native組件庫——beeshell 1.0。時隔一年，我們對React Native組件庫繼續優化，實現beeshell 2.0升級，開源38個功能。希望更好的服務社區，同時也希望利用社區力量豐富React Native組件庫。

引言

隨著 React Native（以下簡稱 RN）技術的出現，大前端的發展趨勢已經勢不可擋，跨平台技術因其通用性、低成本、高效率的特點，逐漸成為行業追捧的熱點。

為了進一步降低開發成本、提升產品迭代的效率，美團開始推廣使用 RN 技術。隨之而來，相關業務方開始提出對 RN 組件庫的訴求。2018 年 11 月，公司內部發起了 RN 組件庫建設，旨在提供全公司共用的組件庫。鑒於我們團隊在開源 beeshell 1.0時，積累了豐富的經驗，於是就加入到了公司級 RN 組件庫的項目共建中。完成組件庫開發後，我們決定將共建的成果貢獻出來，並以 beeshell 升級 2.0 的形式進行開源，共計開源 38（33 個組件與 5 個工具）個功能。在服務社區的同時，也希望藉助社區的力量，進一步完善組件庫。

beeshell 2.0 效果圖如下：

圖D

背景

前端開發（包括 Web 與 Native 開發）是圖形用戶介面（GUI）開發的一種。縱觀各種 Web 以及 Native 產品介面，發現它們都是由一些基本組件（控制項、元素）組合而成。受益於組件化、模組化的開發方式，前端 MV* 框架（如：AngularJS、React、Vue.js 等）也得以蓬勃發展。藉助這些組件化框架，前端開發構建用戶介面的過程，本質上是：開發組件，處理組件間的組合與通訊。

這樣看來，如果實現一套通用的組件並有效復用，便可以大幅減少開發組件的工作，進而提升前端開發的效率。各個業務方對 RN 組件庫的訴求，目的也在於此：降低成本，提升效率。

然而，公司內不同事業部的業務場景和產品功能不盡相同，如何通過一套組件，來有效的支撐外賣、配送、酒旅及其他事業部的業務需求？這無疑對組件庫提出了更高的要求：

  • UI 風格一致性。在同一個業務中，各個組件要有一致的 UI 風格，保證用戶體驗、塑造品牌形象。
  • 通用性。可以支援不同的業務方，可以靈活訂製不同的業務需求，最大化組件復用率，減少重複開發。
  • 易用性。組件的功能、行為表現符合開發者的直觀感受，易於學習和使用、減輕記憶負擔；功能豐富，可以支援多種業務場景，支援特定業務場景的多種情況。
  • 穩定性。RN 組件庫需要同時支援 iOS、Android、Web 三個平台，組件要在三個平台可用、可靠、穩定。

簡而言之，組件庫的目標是通用、易用、穩定、靈活。

系統設計

圖H

我們的目標是提供一套通用、易用、穩定、靈活的組件。然而，對一個組件來說，如果通用性、靈活性強，則易用性、穩定性勢必較差。如何合理的處理這個矛盾呢？

為解決這個矛盾，我們使用了「關注度分離」的設計原則：首先將組件庫需要支援的功能與特性進行分解；進而仔細研究特性的不同側面（關注點），並提供相應的解決方案；最後整合各獨立方案，解決衝突部分，形成整體的解決方案。

「關注度分離」的設計原則，貫穿整個組件庫的設計與實現，是組件庫的核心思想。以該原則為基礎，衍生出了項目拆分、組件分層、功能解耦等具體方案，實現了一個組件庫體系，保證了可以兼顧到相互矛盾的兩個方面，實現最終目標。

架構升級

圖F

beeshell 2.0 與 1.0 的架構在整體上保持一致，共分成四層：業務層、組件庫（體系）、RN 層、系統層。而 beeshell 2.0 的架構升級，則主要體現在第二層與第三層。

第二層：組件庫體系

組件庫由 1.0 的一個項目演變成 2.0 的三個項目（版本），形成組件庫體系。具體包含：公司通用版本MTD、外賣訂製版本Roo和開源版本beeshell。

這種項目拆分的方式，符合「關注度分離」的設計原則，三個版本有各自不同的關注點：

  • MTD 的關注點是通用性、靈活性，所以提供的是基礎、通用的組件。組件的擴展能力極強，可以滿足多個業務方的訂製化需求。
  • Roo 是對 MTD 的繼承與擴展，訂製了外賣業務的 UI 風格與功能，通用性減弱，功能性和業務性增強，關注易用性、業務性、一致性。
  • beeshell（準確說是 2.0 版本）是對 Roo 的繼承與擴展，與 Roo 相比，去除了過於業務化的組件與功能，納入並整合社區的需求，關注通用性、易用性、穩定性。

組件庫體系的三個版本，內部的架構設計一致，本文只詳細介紹 beeshell 開源版本。

組件庫使用了分層的架構風格，分成了介面層、組件層、工具層以及三端適配：

  • 介面層。匯總所有組件，統一輸出，使用全部引入的方式，方便組件使用。另外，為了避免引入過多無用組件，引起資源包過大，也支援組件的按需引入。
  • 組件層。細分為原子、分子、擴展組件。 與 beeshell 1.0 相比，我們對組件在更細的粒度上進行拆分。同時，層次劃分也更加精細、明確。如上圖 F 所示：基礎組件細分為分子、原子組件。這樣，組件的繼承、組合方式更加靈活，能夠最大化程式碼復用。而且，原子、分子、擴展組件，各層次組件各司其職，「關注度分離」，兼顧通用性和易用性。
  • 工具層。與 beeshell 1.0 相比，工具更加完備。不但新增了樹形結構處理器、校驗器等；而且工具的獨立性更強，與組件完全解耦，與組件配合實現功能。 這樣，一方面，使得組件實現更加簡潔，提升了組件的可維護性；另一方面，可以將工具提供給用戶，方便用戶開發，提升組件庫的功能性、易用性。而且，工具與組件的解耦遵循「關注度分離」的原則。
  • 三端適配。RN 在整體上實現了跨平台，iOS、Android、Web 三端使用一套程式碼，但是在一些細節方面，例如：特殊 API 的支援、相對位置計算等，各個平台有較大差異。為了更好的支援三端，保證跨平台穩定性，還需要在這一層做很多適配工作。

第三層：RN 層

這一層新增了 MRN，MRN 是對 RN 的二次封裝，與 RN 底層實現保持一致。組件庫在兩個平台的表現一致。

MRN 是基於開源的 RN 框架改造並完善而成的一套動態化方案。MRN 從三個方面彌補 RN 的不足：

  • 動態化能力。RN 本身不支援熱更新，MRN 藉助公司內發布平台，實現包的上傳發布、下載更新、下線回滾等操作。
  • 雙端（未來三端）復用問題。從設計原則上保證開發者對平台的差異無明顯感知。
  • 保障措施。在開發保障方面：提供腳手架工具、模版工程、開發文檔等，方便開發者日常的 MRN 開發工作。提供多級分包機制，業務內部和業務之間能夠靈活組織程式碼；在運行保障方面，提供運行環境隔離，使得不同業務之間頁面運行無干擾。提供數據採集和指標大盤，及時發現運行中的問題，同時提供降級能力以應對緊急情況。

除此之外，整個組件庫體系，還具備以下特點：更加完善的測試方案；豐富的程式碼示例；使用 TypeScript（以下簡稱 TS）語言進行開發，充分利用 TS 的類型定義與檢查；針對每個組件都有詳細的文檔說明。

協作模式

這裡通過結構和流程兩個方面，詳細介紹 beeshell 1.0 與 beeshell 2.0 以及 MTD、Roo 的關係。三個版本之間通過 Git Fork 建立依賴關係，使用源碼依賴的方式實現項目拆分。對於用戶而言，不同版本的相同組件，底層依賴與實現都是一致的。

圖X

結構方面：MTD 包含 beeshell 1.0 的全部內容，並進行了組件數量的擴充、組件功能的增強；Roo 包含 MTD，進行了訂製與業務擴展；beeshell 2.0 與 Roo 基本一致，去除業務部分，納入社區需求。

流程方面：

  • 首先，我們在 beeshell 1.0 的開發以及開源中，積累了豐富的經驗。在建設 MTD 公司通用版組件庫時，貢獻了 50% 的組件；同時，貢獻了許多設計模式與思路，大大加速了組件庫的建設。
  • 其次，在 MTD 建設完成後，為了更加方便、快速的接入外賣的相關業務，以 MTD 為基礎，訂製了外賣主題的組件庫 Roo，提升了組件庫的業務功能性和易用性。外賣相關的業務項目，在接入 Roo 後直接使用，無需再進行主題的訂製與調整，在一定程度上節省開發成本。
  • 第三，我們將共建的成果貢獻出來，以 Roo 為基礎，升級 beeshell 2.0 並開源。將部分過於業務化的組件移除，納入了社區的相關需求，保證組件庫的通用性、易用性與穩定性。
  • 最後，對於公司內部，各個業務方可以以 MTD 為基礎進行擴展，訂製自己的業務主題組件庫（Roo 就是第一個業務擴展）；對於社區，各個開發者可以根據實際的業務需求，以 beeshell 為基礎，訂製擴展組件庫。

綜上所述，我們以 beeshell 開發團隊為橋樑，建立了美團公司與開源社區之間進行技術交流的通道，美團公司、beeshell 團隊以及社區，可以在技術上互幫互助，共同建設、進步。

方案實現

UI 風格一致性

UI 風格一致性的重要之處在於，對內可以保持平台統一性、提升團隊效率、打磨細節體驗；對外可以塑造品牌形象、減輕用戶學習成本、保持產品的體驗一致性。UI 風格一致性的關鍵要素有很多，包括色彩、排版、字體、圖標以及交互操作等。從總體上看，可以歸納為兩類：樣式一致性和動效一致性。

beeshell 延用了 Roo（袋鼠 UI）的 UI 設計規範，其內容涵蓋了 PC 端與移動端、Web 平台與 RN 平台，對 UI 與交互給出了詳細的視覺規範，旨在保證外賣事業部，全部產品的 UI 一致性。UI 規範的技術實現方式如下：

圖E

Roo Theme 向上實現了 UI 規範具體內容，將設計規範統一收斂，向下輸出主題變數、組件樣式類、通用樣式工具等，供各個組件庫以及業務方使用。

Roo Theme 主要使用 Sass 預處理器實現，提供了各個組件的統一樣式類。為了滿足不同技術棧的需求，主題變數的輸出提供了 JavaScript（以下簡稱 JS）、CSS、Less、Sass、Stylus 多種語言，不同平台、技術棧可以根據情況自由選擇。

beeshell 基於 Roo Theme 輸出的 JS 主題變數，通過樣式和動效兩個方面，保證了 UI 一致性。

  • 樣式一致性。通過繼承、擴展 Roo Theme，定義全局性的主題變數，用於組件的樣式部分定義。主題變數範圍涉及品牌色、灰度、字體尺寸、間距以及組件級變數，為組件以及組件之間樣式一致性，提供了全面的保障。同時，組件庫提供了自定義主題變數的介面，可以重置相關變數的值，對 UI 風格進行一致性調整，實現一鍵換膚。另外，使用「內部樣式 < 主題 < 擴展樣式」的樣式優先順序覆蓋策略，保證了樣式部分的訂製能力（在下文「訂製化能力分級設計」章節中詳細介紹）。
  • 動效一致性。一方面，依賴主題變數中定義的動畫開關變數（主要考慮到一些低端 Android 機器的性能問題），用戶可以關閉某個組件的動畫；另一方面，依賴組件庫的良好分層設計，我們將動畫類獨立實現，這樣可以使用策略模式，將動畫方便的集成到任意組件中。

下文詳細介紹樣式一致性和動效一致性。

樣式一致性

樣式一致性，可以從色彩和排版兩個方面來保證。

首先，介紹下色彩部分。在 App 應用中，色彩元素扮演的角色僅次於功能。人與電腦的互動，主要是與圖形用戶介面的交互，而色彩在該交互中起著關鍵作用。它可以幫助用戶查看和理解介面內容，與正確的元素互動，並了解相關操作。每個 App 都會有一套配色方案，並在主要區域使用其基礎色彩。

正因為有無數種色彩組合的可能，在設計一個 App 時，人們的配色方案也有無數種選擇。本文不糾結於如何選擇一個好的配色方案，而是介紹一個配色方案應該具有哪些元素。一套完整的配色方案，應該包括品牌主色、品牌功能色、中性色。本文以 beeshell 的配色方案舉例說明。

品牌主色

品牌主色應該是應用中出現最頻繁的顏色，通常用來強調 UI 中關鍵部分的顏色。beeshell 的品牌主色色值為 #ffd800，如下圖所示：

通常，一個產品的 UI 只會有一個品牌主色。然而，像 beeshell 這種品牌主色色值較淺的情況，一個品牌主色並不能夠支撐所有的應用場景。此時，可以通過加深主色的方式，再增加幾個色值，beeshell 的品牌主色還包括一個加深的色值 #ffa000，用於某些組件的激活狀態，如下圖所示：

對於品牌主色的個數，需要根據色值的情況而定，不必過於拘泥規則，只要能有一致性的用戶體驗即可。

品牌功能色

beeshell 的功能色內容與使用場景如下圖所示：

圖U

這四個色值，分別用於一般資訊、成功、警告、失敗這四種業務場景，以及從這四種業務場景所衍生出的場景。在一定程度上，保證色彩的一致性。

中性色

beeshell 的中性色（灰度）的內容與使用場景如下圖所示：

圖G

中性色應用於介面主體文本的顏色，灰度範圍的確定，可以大大提升色彩的一致性。

接下來介紹下排版，具體可以分為字體、間距、邊線。

字體

beeshell 的字體尺寸（Font Size）集，是基於 12、14、16、20 和 28 的排版比例，如下圖所示：

圖B

這樣的排版比例，可以使得介面的文字內容更加協調、流暢，進而提升了排版的一致性。

對於字重（Font Weight），beeshell 只使用正常（Normal）和加粗（Bold）兩種：Normal 用於一般文本；Bold 用於強調，吸引用戶注意力。只使用這兩種字重，也避免了因為不同字體家族（Font Family），對字重的支援範圍不同，而導致視覺差異。

除了字體尺寸和字重，影響排版的還有字體行高（Line Height）。為了達到適當的可讀性和閱讀流暢性，可以根據字體的大小和粗細，設定字體行高。默認情況下，RN 應用：行高 = 字體大小 * 1.2。如下圖所示：

圖L

beeshell 使用了默認的字體行高，在一定程度保證了可讀性和排版的一致性。

間距

間距是 UI 元素與元素之間、父元素與子元素之間的空白區域，一個應用排版風格一致性，很大程度取決於間距。一個組件的最終寬高，應該由內容、內邊距以及邊框決定，是自適應的，而不應該直接定義寬高。

對於同一個 App，間距應該在一個合適的範圍取值，可以通過定義『小號間距』、『中號間距』、『大號間距』等來劃分資訊層次。例如 beeshell 的 Button 組件，有三種尺寸。實現效果如下圖所示：

圖S

邊線

邊線（邊框）部分，需要統一元素的邊框寬度、顏色和圓角，邊線雖然對 UI 風格的影響較小，但是不可或缺。beeshell 使用的邊框寬度為一個物理像素，使用 RN 提供的 StyleSheet.hairlineWidth 介面實現；定義了三種灰度的邊框顏色；主要使用 2px 的圓角。

最後，樣式的一致性，還涉及到圖標、布局等相關內容，因為 beeshell 對這些內容的涉及較少，這裡不做詳細介紹。

動效一致性

動效展示了應用的組織方式和功能。

動效可以：

  • 引導用戶在視圖中的視覺焦點。
  • 提示用戶完成手勢操作後會發生什麼。
  • 暗示元素間的等級和空間關係。
  • 讓用戶忽視系統背後發生的事情（比如抓取內容、或載入下一個視圖）。
  • 使應用更有個性、更優雅、體驗更加一致。

beeshell 組件庫基於 Animated 進行了二次封裝，提供 FadeAnimated 和 SlideAnimated 兩個動畫類，支援淡入淡齣動畫和滑動動畫，可以使用策略模式集成到任何組件中。

beeshell 將逐漸在所有的組件集成這兩種動畫，保證動效的一致性。下文展示已經實現了動畫的組件，先睹為快。

Button 組件使用 FadeAnimated 類實現動畫，動效如下圖所示：

Modal 組件使用 FadeAnimated 類實現動畫，動效如下圖所示：

Dropdown 組件使用 SlideAnimated 類實現動畫，動效如下圖所示：

訂製化能力分級設計

要開發一套全公司共用的組件，需要同時滿足酒旅、外賣 C 端、外賣 B 端以及外賣 M 端等業務的需求，這對組件的訂製化能力提出了更高的要求。

為了進一步增強組件的訂製化能力，提升組件的通用性、靈活性；同時，避免屬性（API）的無節制增加，進而導致組件難以維護，我們設計了訂製化能力分級的策略。

這裡以一個常見的業務場景：底部上滑彈框，來舉例說明分級設計。

圖M

如上圖所示：第一個例子比較通用、規範。「區域文字內容」的文案與樣式需要支援自定義；第二個例子，需要支援多行文字以及圖標，即「區域內容」需要支援自定義；第三個例子，自定義的重點，由區域以及區域內部，轉移到區域之間的布局，「區域布局」需要支援自定義。

區域文字內容、區域內容、區域布局，三個層面的靈活性，可以涵蓋一個業務場景所有訂製化需求了。以當前業務場景為例，來講解如何使用訂製化能力分級設計，完成全部的訂製化需求。

首先實現了一個 BottomModal 底部彈框組件，然後開始進行訂製化設計。

第一級訂製化：訂製主題變數

「完成」文本的顏色，使用的是主題變數定義的品牌主色（Brand Primary Dark），beeshell 默認的品牌主色為黃色。

通過組件庫提供的自定義主題變數介面，可以修改品牌主色的色值，進而修改了「完成」文本的顏色。同理，可修改「取消」、「標題」的顏色。

修改品牌主色，影響範圍很大，所有組件的色彩風格統一變化。如果我只想把文本的顏色改成紅色，但是並不想修改品牌主色，應該如何訂製呢？可以使用第二級訂製化。

第二級訂製化：提供訂製屬性

這裡提供 LabelText（類型為 String）和 LabelTextStyle（類型為 TextStyle）屬性，如下圖所示：

圖C-1

程式碼實現為：

<Text style={this.props.labelTextStyle}>{this.props.labelText || '完成'}</Text>

LabelText 用於訂製文案內容，將 LabelTextStyle 整體暴露出來，而不是只暴露顏色單個屬性，這樣有兩點好處：

  • 開發者都熟悉 Style 這個名稱與用法，但並不知道 xxxColor 是什麼，組件更加易用。
  • Style 不僅可以訂製 Color，還支援 fontSize、fontWeight 等屬性，訂製能力更強。

以上兩級主要是樣式部分的訂製，使用了樣式優先順序覆蓋的策略，擴展樣式（labelTextStyle）覆蓋主題，主題覆蓋內部樣式。

下一步，就是對於多行文字、圖標的支援。

第三級訂製化：開放渲染區域

提供 Label 屬性，類型為 ReactElement 對象，任意訂製 UI，如下圖所示：

圖C-2

到這裡，區域以及區域內部的訂製化需求，就都可以滿足了。但是區域布局的訂製化，因為布局情況太多，並不容易實現。如果再提供幾個屬性，用於訂製布局方式、頭部邊框樣式、底部按鈕，按照這種方式，屬性會無節制增加，勢必造成組件難以維護，易用性也會大打折扣。那應該如何實現？我們設計了第四級。

第四級訂製化：繼承/組合基類

在 beeshell 1.0 的開源推廣文章中也有講到過，我們在組件庫開發之初，對常見組件，進行了全面的梳理。在比較細的粒度，對組件進行拆分，以繼承的方式，層層依賴，以功能漸進式增強的方式，實現各個組件。

這樣使得開發者，可以在任意層級上繼承、組合組件，進行訂製化開發，提供了極強的擴展能力。具體實現如下：

首先，組件庫實現一個 SlideModal 滑動彈框組件。這是一個比較底層、基礎的組件，功能相對少，支援多個方向的滑動動畫，內容完全由開發者自定義，通用性、訂製化能力極強。實現效果如下：

然後，組件庫實現了 BottomModal 組件，繼承 SlideModal，固定滑動的方向和開始位置，彈框內容橫向拉伸至全螢幕、縱向自適應，功能增強而訂製化能力減弱。實現效果如下：

前文已經講到，產品需求已經超出了 BottomModal 訂製化的能力，強行實現只會帶來不良後果。所以，我的方式是組合使用 SlideModal，開發一個新的組件，也就是第四級訂製化。新組件的實現效果如下：

第四級訂製化，是使用了新的思路，不再盲目的增加一個組件的功能，來幫助開發者滿足產品需求，而是提供了基礎工具。基礎工具實現了底層、複雜的部分，表現層的部分則讓渡給開發者，用戶自己實現，「授人以魚不如授人以漁」。

對比業界的開源 RN 組件庫，也沒有幾個可以達到第四級的訂製化能力。beeshell 通過四個級別的訂製化的能力，可以輕鬆搞定所有的產品的需求。總之，訂製化能力分級設計，是對訂製化需求進行分類，針對每一類的訂製化需求，設計了相應的策略，最終合成一個完整的解決方案，符合「關注度分離」的設計原則。

功能豐富

功能豐富旨在支援多種業務場景，支援特定業務場景的多種情況，進而提升組件庫的易用性。功能豐富通過兩個方面保證：組件豐富度、單個組件的功能豐富度。

組件豐富度

為了保證組件豐富度，我們通過多種渠道（既有組件整理、業務組件提取、參考標杆項目）來收集組件。最終規划了包括通用類、導航類、數據錄入類、數據展示類、操作回饋類、基礎工具在內的 6 個大類，共 50多個功能，旨在覆蓋儘可能多的業務場景。

目前，beeshell 已經實現了 38 個功能，與業界標杆項目的對比情況如下圖：

圖K

雖然，beeshell 的組件數量還比不上 Antd Mobile RN（用不了多久也會超過），但已經超過 NativeBase 和 React Native Element。beeshell在組件數量上有很大優勢，可以支援更多的業務場景，且支援全部引入和按需引入，用戶無需擔心打包過多無用程式碼的問題。

功能豐富度

功能豐富度針對的是單個組件所支援的功能，旨在覆蓋特定業務場景的多種情況。

圖O

對於一個組件的功能豐富度，我們通過多方式收集、功能綜合分析、UI 模型抽象、技術實現、驗證回饋幾個步驟來保證。

  • 多方式收集。通過多種方式來收集組件功能，收集方式包括：組件既有功能、業務新需求、標杆項目特性。
  • 功能綜合分析。對收集的功能進行全面、綜合分析與考慮，得出組件需要支援的功能特性。
  • UI 模型抽象。對組件功能進行抽象設計，根據 UI 模型，明確抽象設計的合理性和有效性。
  • 技術實現。根據平台特性、技術選型來完成程式碼實現。
  • 驗證回饋。組件實現後，會應用到業務或者示例工程來驗證，如果組件並不能滿足需求，需要重複執行以上幾步。

下文以 SlideModal 組件的實現，舉例說明：

首先，通過多種方式，收集到的滑動彈框場景如下：

圖Q

其次，綜合分析得出，SlideModal 組件需要支援的功能有：彈出位置自定義、滑動方向自定義、全螢幕/半屏自定義。

然後，進行 UI 模型抽象，抽象設計如下圖所示：

圖N-1

圖N-2

由 UI 模型得出，SlideModal 組件通過 (offsetX, offsetY) 坐標值來定義彈出位置；為了支援全螢幕/半屏效果，將螢幕分割為 4 個區域，分別自定義觸控效果（阻斷點擊或者擊穿）；彈框內容在一個區域展示，每個區域有 3 種滑動方向（圖 N-2），共支援 12 種滑動動效。

最後，是基於 RN 平台的技術實現，並經過大量業務場景的驗證回饋。SlideModal 組件的最終實現效果如下：

對比業界開源 RN 組件庫，針對滑動彈框場景，沒有幾個可以超過 SlideModal 的業務支援能力。

SlideModal 組件只提供底層支援，如果要應用到真實的業務場景，還需要基於該組件進一步開發。beeshell 也提供了更高層次的訂製組件，例如：Dropdown、Popover 等，可以直接使用。

除了 SlideModal 之外，還實現了其他功能強大的組件：Slider 滑塊組件，支援縱向和橫向滑動；Rate 評分組件，實現一套滑動評分的機制，支援訂製任意 UI 元素。由於篇幅有限，在此不再贅述。

易用性提升

組件易用性的提升，通過命名、文檔和示例這三個方面來保證。

命名

命名包括組件名、屬性與方法名。

一個組件，實際上就是 Web 頁面或者 App 中的元素、控制項，通常因為原生控制項的能力薄弱，而進行二次封裝。所以組件名與原生控制項名的名稱，盡量保持一致。例如，Form 與 HTML Form 標籤一致，Switch 從 iOS 控制項 UISwitch 中得來。這樣的命名，可以給與開發者更加直觀的感受，通過名稱就能知道組件大概的 UI 與功能，降低學習和使用的成本。

屬性與方法的命名，既要考慮原生控制項的屬性名，又要考慮組件庫命名的一致性。例如，表單錄入的相關組件，包括 Input、Radio、Checkbox、Switch 等，組件的值要統一使用 Value 命名，值變化的回調使用 onChange，選中狀態使用 Checked 布爾類型。這樣符合用戶的直觀感受，更加易用，降低使用成本。

常用屬性名舉例如下：

文檔

文檔規定了統一的格式，旨在全方位介紹組件，方便開發者使用，格式內容如下：

  • 組件名稱。
  • 組件描述。
  • 引入方式，包括全部、按需兩種引入方式。
  • 示例演示，動圖與靜圖。
  • 示例程式碼，使用偽程式碼，言簡意賅，能說明使用方式即可，同時，附有完整示例程式碼的鏈接。
  • API 說明，分成 Props 和 Methods 兩部分。
    • Props 包含 Name | Type | Required | Default | Description。
    • Methods 格式借鑒 RN 官方文檔格式。

示例

beeshell 組件庫遵循「關注度分離」的設計原則，對組件進行細粒度的拆分，進行了分類、分層，以及基礎工具與組件實現的功能解耦。

這些設計雖然大大提升了組件庫的靈活性，但是在一定程度上，對開發者提出了更高的要求。開發者需要理解各個組件與工具，靈活的組合各個元素，才能更好的完成業務需求。

為了方便開發者，更有效、合理的使用組件，我們將會實現一些經典的業務場景，以示例的形式開源出來。藉助美團的平台服務，為用戶提供在線演示的功能，用戶可以下載美團 App（iOS 與 Android 都可以），掃描下圖二維碼，即可快速體驗各種應用場景。

測試

程式碼開發的目標有兩個：第一個是實現需求，第二個是保證研發品質。研發品質對公共組件庫來說，尤為重要。測試是為了提高程式碼品質和可維護性，是實現程式碼開發第二個目標的一種方法。

beeshell 1.0 中已經集成了「黑盒測試」與「白盒測試」。beeshell 2.0 在原有的基礎上，進行了一定程度的優化，程式碼的可靠性與安全性，仍然保持最高級別，而測試覆蓋率則由原來的 70% 提升到了 80% 以上，使用 SonarQube 的分析統計結果如下圖：

圖A

不僅如此，beeshell 2.0 在測試領域繼續探索，集成了「灰盒測試」（基於開源方案 Detox 實現）。

灰盒測試，是介於白盒測試與黑盒測試之間的一種測試，灰盒測試多用於集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程式內部的情況。灰盒測試不像白盒那樣詳細、完整，但又比黑盒測試更關注程式的內部邏輯，常常是通過一些表徵性的現象、事件、標誌來判斷內部的運行狀態。

灰盒測試效果如下圖所示：

通過黑盒測試、白盒測試、灰盒測試，三種測試方案，更加全面的保證組件庫的程式碼品質，大大提高了程式碼可維護性。

開發調試

受益於 MRN 平台，JS 程式碼與 Native 程式碼得以完全分離。

beeshell 源碼工程，包含了包括組件源碼、示例程式碼、測試文件在內的全部 JS 程式碼，Native 部分則只負責打包生成容器（本文以美團 APP 舉例說明），通過下載並安裝 .app（iOS）或者 .apk（Android） 文件至模擬器，直接載入本地服務提供的 jsbundle，快速進入開發調試。

前端開發再也不用關心 Native 的部分，無需耗時耗力的維護 Native 環境、依賴，極大降低了前端開發成本。開發調試流程如下圖所示：

圖P

未來規劃

我們的目標是把 beeshell 建設成為一個全面且完備的組件庫，不僅會不斷豐富 JS 組件，而且會不斷加強複合組件去支援更多的底層功能。

我們為組件庫發展規划了三個階段：

  • 第一階段，beeshell 1.0 版本，開源 20+ 組件，主要提供基礎功能。
  • 第二階段，對我們在開發 React Native 應用幾年時間積累的組件進行整理，同時參考業界的標杆項目，開源 50+ 組件。
  • 第三階段，調研移動端 APP 常用的功能與場景，分析與整理，然後在 beeshell 中實現，開源 100+ 組件。

此次 beeshell 2.0 升級，共計開源 38 個功能，而且已經詳細的規划了另外的 15+ 組件，也會在近期開源，目前處於第二階段的收尾階段。

第三階段的建設，也在緊鑼密鼓的籌備當中，要實現 100+ 組件任務十分艱巨，希望大家踴躍參與，共同建設。

開源相關

Github 地址：beeshell

核心貢獻者

小龍，澤楠，軼超，宋鵬，孟謙

參考資料

團隊介紹

外賣事業部終端團隊，負責的多個終端和平台直接連接億萬用戶、數百萬商家和幾萬個運營人員，目標是在保障業務高穩定、高可用的同時，持續提升用戶體驗和研發效率。

  • 在用戶方向上，構建了全鏈路的高可用體系，客戶端、Web前端和小程式等多終端的可用性在99%左右；跨多端高復用的局部動態化框架在首頁、廣告、營銷等核心路徑的落地，提升了30%的研發效率；
  • 在商家方向上，從提高進程優先順序、VoIP Push拉活、doze等方面進行保活訂製，並提供了Shark、短鏈和Push等多條觸達通道，訂單到達率提升至98%以上；
  • 在運營方向上，通過標準化研發流程、建設組件庫和Node服務以及前端應用的管理與頁面配置等提升10%的研發效率。

———- END ———-

VirMach 便宜 VPS

QNews

QNews