Page Maker是我在公司參與時(shí)間最長的一個(gè)項(xiàng)目了，自打?qū)嵙?xí)期做了webIM，轉(zhuǎn)正之后不久，就開始參與了PageBuilder項(xiàng)目的開發(fā)，前前后后大概經(jīng)歷了兩年的時(shí)間，后來由于公司業(yè)務(wù)調(diào)整，已經(jīng)在今年初逐步將項(xiàng)目交接了出去。雖然現(xiàn)在不再參與項(xiàng)目的維護(hù)，但是從這么長時(shí)間的開發(fā)過程中，還是學(xué)到了很多東西，也讓我成長了很多。其實(shí)最關(guān)鍵的，并不是具體解決了什么問題，而是解決問題的思路與方法。

PM 的產(chǎn)品定位是一個(gè)平臺，他所提供的核心能力就是頁面的可視化構(gòu)建，通過拖拖拽拽，就可以生成一個(gè)頁面，并所見即所得。為公司的各產(chǎn)品先以及后續(xù)的ISV提供穩(wěn)定 可靠 自由的頁面定制化能力，以此滿足客戶的多樣化需求。

在實(shí)際的開發(fā)過程中，我們遇到以及需要解決的問題有：

(相關(guān)資料圖)

組件化元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)組件開發(fā)規(guī)范運(yùn)行態(tài)資源加載與性能優(yōu)化基礎(chǔ)依賴管理

其實(shí)每個(gè)點(diǎn)都能單獨(dú)寫一篇文章的，這里就只簡單總結(jié)了。

組件化

在PM的實(shí)現(xiàn)中，頁面組件化是一個(gè)非常重要的前提，所以我們抽象出了兩個(gè)概念，即：

布局組件視圖組件

布局組件用以實(shí)現(xiàn)頁面布局，而視圖組件承載著業(yè)務(wù)數(shù)據(jù)，并以多樣化的形式展現(xiàn)給用戶。所以頁面長得好不好看，直接取決于視圖組件。 另外，為了提高視圖組件的可擴(kuò)展性，以及凸顯PM所強(qiáng)調(diào)的 可配置的能力，我們還抽象出了一個(gè)組件類型，即 屬性組件。

有了屬性組件，實(shí)施人員就可以給視圖組件配置不同的屬性，比如數(shù)據(jù)源，展示形式，等等，對于視圖組件來說，所有可變，可配置的，都以通過屬性組件來實(shí)現(xiàn)。通過 PM平臺，將屬性組件和視圖關(guān)聯(lián)展示到頁面上，并最終呈現(xiàn)給用戶。

元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)

基于元數(shù)據(jù)的應(yīng)用設(shè)計(jì)的最大的好處就是可描述和可擴(kuò)展。我們將頁面抽像為一套元數(shù)據(jù)結(jié)構(gòu)，而pb就是這套元數(shù)據(jù)的解析器。保存頁面，實(shí)質(zhì)上就是保存了一份元數(shù)據(jù)的實(shí)例。

{/****組件列表: 每往頁面中拖入一個(gè)組件，都會在該屬性下新增一條字段，用于描述該組件****/"componentList": [{"editableData": string,//組件的可編輯屬性    "cType": string,       //組件名稱    "hasCustomProps": Boolean, //組件是否有自定義屬性    "isContainer":Boolean,//是否是容器組件    "isSubcomponent":Boolean,//是否是子組件    "id": string,//組件id 唯一標(biāo)識    "parentId": string,//父級ID    "componentHolderKey":string,//對應(yīng)tab容器組件的tab    "appId":number,//組件屬性應(yīng)用的ID    "deletable":Boolean,//組件是否可以被刪除    "url":string,//iframe組件URL地址，之前ocean組件用的}],/*****頁面數(shù)據(jù)信息****/"pageSettings": {"title": "AAA",//頁面名稱     "template": "Classic",//頁面模版       "layout": "grid"http://布局類型 grid / vertical},//頁面的可編輯屬性pageProperty:{"editableData": {},}/**section列表，注意 有的section是沒有位置信息的，如容器組件內(nèi)的組件,是根據(jù)數(shù)組順序依次由上而下排列**/"sectionList": [{"id": string,//唯一的標(biāo)識       "targetLayout": string,//所屬的工作區(qū)       "x":number,//x坐標(biāo)       "y":number,//y坐標(biāo)       "w":number,//w 寬度       "h":number//h 高度}, {"id": "8d227680-f26a-11e6-9457-8f2c27c19ddf","targetLayout": "default1"}]}

組件開發(fā)規(guī)范

在這個(gè)問題下，細(xì)分的問題還是挺多的比如：

1. 技術(shù)選型

這個(gè)其實(shí)沒有太多可說的，公司整個(gè)平臺都采取的React框架，所以為了保持統(tǒng)一，當(dāng)然就是直接采用React

2. 組件開發(fā)模版

這里的模版設(shè)計(jì)所遵循的原則應(yīng)該是盡量簡潔，符合常規(guī)的開發(fā)習(xí)慣，并將細(xì)節(jié)封裝好隱藏在內(nèi)部。我們會提供一條龍的服務(wù)，包括但不限于構(gòu)建方案 組件注冊 以及對接CI服務(wù)，對于業(yè)務(wù)方來講，只需要關(guān)注于組件的開發(fā)即可。另外，模版設(shè)計(jì)時(shí)，一定要遵循模塊化 分層設(shè)計(jì)的思想，盡量減少后續(xù)模塊升級所帶來的遷移成本。

#源代碼目錄，項(xiàng)目基礎(chǔ)結(jié)構(gòu)，里面列的文件必須按照這個(gè)結(jié)構(gòu)存在，其他可按照自己的需求安排。/src    #export組件的文件，必須存在    index.js    #Page Builder屬性配置代碼存放的目錄    /props        #export 屬性組件文件        index.js#包信息描述package.json#文檔README.md#git忽略文件列表.gitignore#npm忽略文件列表.npmignore# webpack配置 可選 支持自定義擴(kuò)展webpack.config.js

4. cli工具

前端工程化設(shè)計(jì)中，一個(gè)很重要的原則就是自動化，將所有重復(fù)性的，工程化的工作，交給程序完成，從而盡可能的提升工作效率。所以我們開發(fā)cli工具，將組件注冊 git項(xiàng)目搭建，以及生成本地開發(fā)模版的任務(wù)全部集成在cli工具中，開發(fā)人員一分鐘的時(shí)間，就可以開始新組件的開發(fā)

5.css 模塊化

相對于JS的發(fā)展的來講，CSS的進(jìn)度確實(shí)緩慢了些。因?yàn)镻M頁面上的組件都是獨(dú)立構(gòu)建的，但是會放在同一個(gè)運(yùn)行態(tài)下，所以很容易出現(xiàn)樣式覆蓋的問題。為了保持樣式的穩(wěn)定，作為平臺，必須提供統(tǒng)一的css 模塊化方案。經(jīng)過技術(shù)方案的調(diào)研和對比，最終采取了styled-component。至于為什么不采用css module，是因?yàn)樗膆ash是在構(gòu)建過程完成計(jì)算的，而不是運(yùn)行時(shí)，所以不能從根本上解決PM平臺所面臨的問題。

6. 版本管理

對于組件的版本管理，我們沒有采取hash，轉(zhuǎn)而采用了npm包版本的方案。主要是考慮到更加直觀和友好，而且方便版本回退。

7. 上線發(fā)布流程

對于開發(fā) 測試以及線上環(huán)境，靜態(tài)資源都是共享的，所謂上線，只不過是將對于環(huán)境下的版本更新下而已。后端同學(xué)提供了導(dǎo)入導(dǎo)出工具，方便組件的發(fā)布上線。

8. CI持續(xù)化集成

每個(gè)組件都對應(yīng)獨(dú)立的前端項(xiàng)目，我們?yōu)檫@些項(xiàng)目接入CI服務(wù)，并將組件的構(gòu)建，版本發(fā)布以及靜態(tài)資源發(fā)布等等集成在CI任務(wù)中，另外，為了方便進(jìn)行組件的性能優(yōu)化，我們借助webpack 插件為每次構(gòu)建都生成一份構(gòu)建報(bào)告：

基礎(chǔ)庫管理

首先所面臉的問題：在我們的設(shè)計(jì)中，PM的每個(gè)組件的都是獨(dú)立的，單獨(dú)構(gòu)建的。因?yàn)榻M件開發(fā)都需要依賴React，如果在構(gòu)建時(shí)將React構(gòu)建進(jìn)去，那么運(yùn)行態(tài)下就會存在多份react，而react是不允許多實(shí)例共存的，所以這就產(chǎn)生了問題。除了react，還可能依賴其他一些比較大的類庫 比如recharts。

關(guān)于這個(gè)問題，我們最開始采用的方案是 webpack dll。一切看起來都是那么完美，直到我們在升級react 16 的過程中，痛苦出來了。因?yàn)閞eact升級，所以我們要構(gòu)建出新的dll來，dll更新了，那么原來那些發(fā)布過的組件，都需要基于新的dll重新構(gòu)建一遍，才能在運(yùn)行態(tài)下正常渲染。OMG，工作量太大了，而且涉及到多個(gè)業(yè)務(wù)線下的上百個(gè)組件。問題已經(jīng)比較嚴(yán)重了。

經(jīng)過商量，我們最終用webpack external 代替了 dll的方案，雖然dll在運(yùn)行態(tài)下的性能會稍好一些，但是所帶來的問題已經(jīng)遠(yuǎn)遠(yuǎn)超過收益了。

運(yùn)行態(tài)資源加載與性能優(yōu)化

前面提到PageMak是一個(gè)平臺，各個(gè)業(yè)務(wù)方都會在這個(gè)平臺上開發(fā)和發(fā)布組件，然后在運(yùn)行態(tài)下統(tǒng)一加載和渲染。那該怎么加載 加載哪些，才能達(dá)到更好的頁面加載性能，就是一個(gè)很值得研究的話題。 關(guān)于這個(gè)問題的方案，其實(shí)演變了很多。

野蠻時(shí)代

剛開始的時(shí)候，按照我們的設(shè)計(jì)，每個(gè)業(yè)務(wù)線都有一個(gè)前端項(xiàng)目，這個(gè)項(xiàng)目下維護(hù)著該業(yè)務(wù)線下的所有組件，也就是說，所有的的組件都會打包在一起，單個(gè)組件沒有獨(dú)立的版本控制。所以，順利成章的，這種情況下，我們在運(yùn)行態(tài)就按照業(yè)務(wù)線來加載組件，如果當(dāng)前的租戶開通了應(yīng)用，那么，就會去加載這個(gè)組件。這也是最初的設(shè)計(jì)，后來做了一點(diǎn)點(diǎn)的優(yōu)化，就是判斷下，如果當(dāng)前的頁面上拖入了某業(yè)務(wù)線下的組件，才會加載這個(gè)業(yè)務(wù)的組件。這里的判斷邏輯由后端同學(xué)實(shí)現(xiàn)。，前端只負(fù)責(zé)加載和渲染。

工業(yè)社會

后來，隨著業(yè)務(wù)線組件的增加，這個(gè)項(xiàng)目變得越來越龐大，如果某個(gè)頁面上只拖入了業(yè)務(wù)線下的一個(gè)組件，那么該業(yè)務(wù)線下的所有組件都會加載進(jìn)來。而且更嚴(yán)重的是上面提到的，單個(gè)組件沒有的獨(dú)立的版本控制，這其實(shí)是很要命的。所以為了解決這個(gè)問題，經(jīng)過商量過后，我們決定將單個(gè)組件拆分為獨(dú)立的前端項(xiàng)目?；诖?，我們在運(yùn)行態(tài)下資源加載的顆粒度，就可以控制到組件級別的了。

也就是說，我們通過元數(shù)據(jù)分析，可以得知該頁面上拖入了哪些組件， 以及組件的版本。然后，加載模塊就會將所有的組件通過異步腳本的方式加載進(jìn)來，交給渲染器去渲染。（至于渲染器如何知道哪些組件加載進(jìn)來了，哪些組件沒有加載進(jìn)來，這是通過一個(gè)組件的注冊模塊來實(shí)現(xiàn)的。）

方案走到這里，已經(jīng)將所有的冗余的資源都去掉了，看似很完美，但其實(shí)還是有問題的。

首先，一個(gè)頁面上可能會拖入很多組件，少則七八個(gè)，多則一二十個(gè)，每個(gè)組件都對應(yīng)一個(gè)js資源，那么要想頁面渲染出來，至少將這些js腳本全部加載完成。但是，客戶端對于并行請求數(shù)是有限制的，沒記錯(cuò)的話應(yīng)該是5個(gè)，從這方面考慮的話，前端性能優(yōu)化的一個(gè)很重要的方向就是資源合并，比如常見的雪碧圖。