滴滴 WebApp 團隊在去年底用 Vue.js 2.0 對業務進行重構，並開發了一套移動端元件庫 cube-ui 支撐業務的開發。經過了一年多的業務考驗，cube-ui 也日趨成熟，而且我們相信除了在滴滴內部，cube-ui 也一定也有它的用武之地。好的東西必須要和大家分享，所以我們非常開心的告訴大家， cube-ui 在今天正式開源，地址 github.com/didi/cube-u… 。
cube-ui 從滴滴業務中提煉而來，由滴滴 WebApp 前端架構組開發和維護。cube-ui 的目標是讓移動端的開發更加容易，讓開發人員更加專注於業務邏輯的開發，提升研發效率。
特性
質量可靠
由滴滴內部元件庫精簡提煉而來，經歷了業務一年多的考驗，並且每個元件都有充分單元測試，為後續整合提供保障。
體驗極致
以迅速響應、動畫流暢、接近原生為目標，在互動體驗方面追求極致。
標準規範
遵循統一的設計互動標準，高度還原設計效果；介面標準化，統一規範使用方式，開發更加簡單高效。
擴充套件性強
支援按需引入和後編譯，輕量靈活；擴充套件性強，可以方便地基於現有元件實現二次開發。
優勢
相對於同型別的移動端元件庫，cube-ui 有哪些優勢？
追求極致的體驗
我常說一句話：“移動端元件庫寫的好不好，就看 Picker 元件寫的好不好”，因為想把這個元件寫好是需要花一定功夫的。cube-ui 的 Picker 是目前所有移動端元件庫中實現最細緻，體驗也是最好的，接近原生 iOS 選擇器的效果。類似的還有 IndexList 索引列表元件，我們在一些互動的細節上都考慮的非常細緻，比如對吸頂標題的處理，按壓態的處理等。後編譯技術
後編譯技術是滴滴前端團隊在“一個專案中引用多個 ES6 開發的模組，由於 Babel 編譯會產生多份額外程式碼”的問題的思考並總結出的一套優化的技術方案。cube-ui 元件庫也用到了該技術方案，它會讓最終使用方引用 cube-ui 元件庫編譯產生的程式碼體積減少，在一定程度上優化了效能。
元件
cube-ui 元件主要包括 3 個部分，基礎元件、彈出層元件和滾動元件。目前總共開源了 14 個元件，我們的原則是隻開源通用性強的元件。雖然目前元件的個數不多，但是在元件的體驗和互動，包括易用性上我們都追求極致。
使用
cube-ui 支援 2 種使用方式，宣告式和 API 式。
<template>
<cube-button @click="showToast">show toast</cube-button>
</template>
<script>
export default {
data() {
return {
toastTxt: 'toast content'
}
},
methods: {
showToast() {
this.$createToast({
txt: this.toastTxt
}).show()
}
}
}
</script>複製程式碼如上程式碼所示，這裡面實際上使用了 2 個 cube-ui 的元件，cube-button 和 cube-toast。可以看到，cube-button 我們是用了宣告式的建立，而 cube-toast 是通過例項上的 $createToast API 呼叫。
Vue.js 是比較推崇宣告式的方式使用元件，但是考慮到元件巢狀較深的場景，子元件的樣式可能被父級樣式影響，所以我們針對彈出層型別的元件設計了 API 方式的呼叫，它們最終會掛載到 body 元素下，避免了樣式受父級影響。
擴充套件
cube-ui 的某些元件有著很好的擴充套件性，我們可以根據實際場景需求做功能的擴充套件，舉例說明：
Popup
彈層類元件的基類，內建所有的彈層類元件（Toast、Picker、TimePicker、Dialog、ActionSheet ）等都是基於 Popup 元件實現，當然我們也可以基於它開發更豐富的彈層類元件。
Picker
移動端選擇器元件， TimePicker 就是在 Picker 基礎上封裝出來的元件，當然我們也可以基於 Picker 擴充套件出一個城市選擇器元件。
演示
演示地址，推薦在手機上瀏覽。
掃碼體驗：
架構設計
cube-ui 底層依賴了 Vue 和 better-scroll，並依賴了一系列工具做了構建部署、單元測試等工作；在這些基礎上，cube-ui 實現了一系列的元件，如圖所示：
展望
未來我們會持續對 cube-ui 迭代和優化，包括但不限於以下幾個方向：
豐富元件庫
我們會考慮根據滴滴內部的需求以及社群的反饋開發更多通用的元件。
支援換膚功能
我們會對換膚功能做很好的支援，和 UI 團隊配合設計出幾套皮膚，同時也支援自定義皮膚能力。
支援 TypeScript/Flow
靜態型別檢查作為未來的趨勢，cube-ui 也會考慮對它們的支援。