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 三個平臺，元件要在三個平臺可用、可靠、穩定。

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

系統設計

開源React Native元件庫beeshell 2.0釋出

圖H

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

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

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

架構升級

開源React Native元件庫beeshell 2.0釋出

圖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 建立依賴關係，使用原始碼依賴的方式實現專案拆分。對於使用者而言，不同版本的相同元件，底層依賴與實現都是一致的。

開源React Native元件庫beeshell 2.0釋出

圖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 規範的技術實現方式如下：

開源React Native元件庫beeshell 2.0釋出

圖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，如下圖所示：

開源React Native元件庫beeshell 2.0釋出

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

開源React Native元件庫beeshell 2.0釋出

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

品牌功能色

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

開源React Native元件庫beeshell 2.0釋出

圖U

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

中性色

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

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

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

字型

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

開源React Native元件庫beeshell 2.0釋出

圖B

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

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

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

開源React Native元件庫beeshell 2.0釋出

圖L

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

間距

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

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

開源React Native元件庫beeshell 2.0釋出

圖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）屬性，如下圖所示：

程式碼實現為：

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

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

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

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

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

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

提供 Label 屬性，型別為 ReactElement 物件，任意定製 UI，如下圖所示：

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

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

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

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

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

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

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

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

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

功能豐富

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

元件豐富度

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

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

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

功能豐富度

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

開源React Native元件庫beeshell 2.0釋出

圖O

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

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

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

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

其次，綜合分析得出，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 布林型別。這樣符合使用者的直觀感受，更加易用，降低使用成本。

常用屬性名舉例如下：

開源React Native元件庫beeshell 2.0釋出

文件

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

元件名稱。
元件描述。
引入方式，包括全部、按需兩種引入方式。
示例演示，動圖與靜圖。
示例程式碼，使用虛擬碼，言簡意賅，能說明使用方式即可，同時，附有完整示例程式碼的連結。
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 實現）。

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

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

開源React Native元件庫beeshell 2.0釋出

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

開發除錯

受益於 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

核心貢獻者

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

參考資料

beeshell 1.0 開源推廣文章
MATERIAL DESIGN

團隊介紹

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

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

---------- END ----------

開源React Native元件庫beeshell 2.0釋出

背景

系統設計

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

架構升級

圖F

協作模式

方案實現

UI 風格一致性

樣式一致性

動效一致性

定製化能力分級設計

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

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

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

功能豐富

元件豐富度

功能豐富度

易用性提升

命名

示例

測試

開發除錯

未來規劃

開源相關

Github 地址：beeshell

核心貢獻者

參考資料

相關文章