Element是壹個基於Vue 2.0的桌面組件庫，由餓了麽UED設計，餓了麽大前端開發。今天要分享的是壹些開發Element的經驗。
官網:/ElemeFE/element
# #設計目的
大多數項目源於業務方的需求，Element也是如此。隨著公司業務的發展，內部衍生了很多後端系統，UED部門也收到了越來越多的設計需求。在分析了整個過程後，我們發現了以下問題:
-對背景產品設計的需求日益增加。
-有限的設計資源，無法支持所有業務線
-公司很多後臺產品體驗不壹致。
所以我們決定:
-設計壹套後臺支撐框架，提高後臺系統的可用性和壹致性。
-應用這個框架，即使沒有設計師的參與，也能為產品或開發設計出壹套有用的後臺系統。
# #設計階段
下面簡單說壹下設計壹個元素的幾個階段。
* *在公司了解業務熟悉後臺產品，在業務中尋找* * *性問題* *
設計的目的是為企業服務。第壹步，從內部系統入手，了解公司使用的各種後端系統，抽象剝離其組件，尋找* * * *的特點。
* *專註於業務組件設計* *
在總結了公司不同系統的不同組件的用法後，我們打算從業務組件入手，因為這部分是源於公司特殊需求的解決方案，我們認為解決這些棘手的問題也能給其他後臺產品帶來很好的設計指導。
* *尋求發展支持* *
此時，我們開始在公司內部尋找開發團隊，然後我們了解到不同的團隊使用不同的前端框架，包括Vue、React、Angular等等。
* *使用大型前端* *
大前端作為壹個獨立的前端團隊，有能力開發底層工具服務於不同的業務，Vue也是壹個年輕且發展良好的技術棧。UED和大前端的合作壹拍即合。
* *改變方向，專註於基本組件* *
和大前端接觸後，發現最初的方向並不正確，因為業務變化太快，即使有通用的業務組件，也很難跟上需求的變化，基礎組件是所有開發團隊需要的通用組件。這時，我們開始把方向調整到基礎部件的設計上。
* *組件交互完成，進行可視化包裝，搭建主網站* *
前期設計工作主要由交互設計師設計。在確認了所有組件的功能和交互後，視覺階段開始，包括制定顏色、字體等各種規格，同時設計主網站。
輸出UI套件文件，統壹設計規範。
在第壹版網站設計中，這裏的“特殊組件”就是業務組件。
* *網站重新設計* *
網站第壹版上線後，視覺效果不好，我們進行了內部調整。再次上線後，就是現在大家看到的樣子。
簡而言之，設計過程經歷了這些階段。如果還有問題，可以繼續交流。讓我們進入發展階段。
# #開發目的
-後臺系統缺乏壹套完整的基礎組件庫
-Vue是公司裏比較年輕的技術棧，想做壹些基礎設施建設。
-提升公司在技術社區的影響力。
# #開發流程
進入開發階段後，我們在整體架構上做了壹些嘗試。讓我們按時間順序與妳分享:
* *如何與設計師合作* *
在項目的初始開發和設計之後，我們改進了壹套組件開發流程:
1.根據交互稿和視覺稿進行開發，期間保持與設計師的溝通。
2.開發後自檢，然後提交給設計師驗收。
3.設計人提出修改意見，並根據意見進行修改。
4.完成組件開發，並為網站編寫示例和文檔。
* *如何管理多組件項目* *
開發之初，我們就在思考如何降低組件的耦合度，保證組件能夠獨立工作。這樣做的目的是保證組件可以依賴其他組件，讓用戶只加載其中的少數幾個，甚至在安裝時只安裝需要的組件。首先想到的是，壹個組件是壹個獨立的倉庫，組件庫項目就是引入組件作為依賴。
但是由於人力不足，這種機制的開發太耗時，每個組件都需要單獨維護和打包，同時維護組件庫項目的依賴版本號。只能另找方案了。後來提到
[babel](/babel/babel)項目管理模式:所有子項目都放在` packages/'中。
在目錄中，子項目可以視為壹個獨立的倉庫。經由[lerna](/lerna/lerna)
管理子項目的依賴關系和發布。
結合我們自己項目的特點和babel的這種機制，我們重構了目錄結構:組件可以作為單個項目放在' packages/'中，而* * *可以放在函數中。
` src/`li。最終的打包結果會把整個組件打包成壹個文件，組件分別打包成獨立的文件。同時，還將發布組件庫和獨立組件，以滿足不同用戶的需求。
* *如何解決自定義主題* *
開發壹個組件庫離不開自定義主題的需求。類名要足夠友好，盡量避免樣式級嵌套，這樣直接覆蓋樣式或者單獨寫壹組主題會方便很多。所以我們用BEM來管理類名，同時盡可能用變量代替屬性值。我們可以通過維護壹個變量文件來定制壹組主題，以便可以直接修改變量。
考慮到不同用戶的使用習慣，我們選擇了更接近未來標準的CSS4，而不是Less或Sass等自有風格的預處理器。
樣式語法，使用PostCSS並集成了postcss-bem和postcss-cssnext等插件。
[post CSS-salad](/eleme Fe/post CSS-salad)開發。
為了降低用戶自定義主題的成本，我們還提供了命令行工具來指導用戶快速自定義壹組主題。
* *如何提供直觀的文檔* *
文檔不僅讓用戶看起來直觀，也讓作者寫起來直觀。最簡單的方法是使用Markdown。
寫文檔。但另壹個問題會出現:如何在文檔中寫出可操作的例子？傳統的做法是用Vue編寫文檔。
文件，以便可以調用其中的其他組件，但這違背了編寫“直觀”文檔的初衷。
經過幾次嘗試，結合Vue的特點。我們編寫了壹套webpack loader來處理Markdown文件，可以將Markdown轉換成Vue文件，不僅降低了文檔的維護成本，還使得在文檔中運行組件實例成為可能。
* *如何配置和管理多語言官方網站* *
Element在項目之初並沒有真正考慮國際化。項目開源後，我們收到了壹些國外開發者的反饋，希望增加英文文檔。不久之後，國內的壹個翻譯團隊主動聯系我們，向Element貢獻了壹整套英文文檔。
如果妳有英文文檔，妳需要壹個英文網站，這就需要對官網現有結構進行修改和升級。同時，為了面向未來，官網需要兼容除英語之外的其他語言。為此，我們做了以下工作:
1.按指定路線發送
官網的路線是根據壹個記錄導航信息的json文件自動生成的。因此，需要在這個json文件中添加對應於其他語言的字段，並根據新的數據結構修改路由生成的邏輯。
2.頁
除了文檔，官網還有壹些介紹頁面。這幾頁裏有很多單詞。如果手動管理每種語言的頁面，需要修改就必須到每個頁面對應的位置進行編輯，有些繁瑣。我們的做法是:每個頁面對應壹個模板，將模板中的所有單詞提取到壹個語言配置文件中，編寫壹個腳本，生成最終的頁面。這樣，當妳需要修改它時，妳只需要在語言配置文件中編輯相應的字段。
3.網站組件
對於常見的頁面組件，如“頁眉”和“頁腳”，我們采用與上面類似的策略。但是由於組件中缺少文本，所以不再使用模板，而是通過路由判斷應該顯示的語言。
中英文網站的顯示效果
在這壹點上，我們已經逐步完善了技術棧。ES2015和CSS4作為開發語言，Lerna負責管理組件，Karma配合Mocha和。
Chai等工具在Travis CI中做持續集成測試，最後用Markdown結合Vue寫文檔。我們甚至在CI
在這個系統中，實現了自動部署網站、推送主題倉庫代碼等功能，提高了很多開發效率。