前言
對於C端業務偏多的公司來說，在增長、運營等各方同學的摧殘下永遠繞不過去的一個坑就是大量的H5頁面開發，它可能是一個下載、需求告知、產品介紹、營銷活動等頁面。此類需求都有幾個明顯的缺點：
•開發價效比極低、上線時間緊，每次需要指派單獨同學支援。•溝通成本高，而業務邏輯高度相似。•高頻次的需求 有句話怎麼說來著，世界是"懶人"創造的，當我們煩透了無休止的重複工作時，一些"偷懶"的想法就會蹦出來。對研發而言我們不想花費過多的時間在此類簡單重複的工作上；對運營而言他們需要活動更快的迭代、發版，脫離研發的排期等限制；於公司而言節省人力成本就是節省財務成本，更大的提高效率就可以支撐配合更多增長營銷策略。
所以從技術賦能業務的角度出發，一套視覺化活動編輯系統是每個中大型公司必備的生產利器。
首先讓我們來挑幾個代表性的頁面簡單分析一下...
如下圖：
先從頁面上做個分析：
•圖1、3都屬於簡單的引流下載頁•圖2、4屬於普通活動頁•圖5無任何互動邏輯，只是單純的一個靜態告知頁•圖6從頁面結構和業務邏輯來說，屬於複雜活動頁
接下來拋開UI細節層面不談，對頁面進行一個拆解
•圖1、3 組合方式 （ 背景圖 + 按鈕 + [ ios、安卓 ]下載連結 ）
•圖2、4 組合方式 （ 背景 + 按鈕 + 活動規則 + 領券邏輯 ）
•圖5 組合方式 （ 背景 + 活動規則 ）
•圖6 組合方式 （ 背景 + 業務模組 + 活動規則 ） 
綜上分析可見，每個頁面由多個小模組構成，可以是基礎UI元件，也可以是一個複雜的業務元件，且組合方式多種多樣，可以預想到當我們將這些不同元件像元件庫那樣整合在一起且可以在頁面進行視覺化的編輯操作時，不同的元件不同的排列即可生成一個全新的活動，就像積木一樣擁有無限種可能，開發效率將會大大提高，本文將這兩個月鼓搗lego活動視覺化搭建系統（以下簡稱lego）從0到1的心路歷程整理出來供各位有相關需求的小夥伴參考，也歡迎大神交流指正。
核心方案
Lego採用Vue框架開發，通過對元件物料進行拆分再統一管理，形成一個可編輯的元件庫。JSON schema 來定義元件JSON規範，配合Vue的動態元件特性來實現動態的頁面渲染。動態表單用於根據不同元件特性生成對應配置表單。最後打包並優化多頁面，每個頁面單獨配置域名，一個負責內部編輯、一個負責對外展示。通過活動id獲取對應活動JSON資料動態渲染在活動展示頁面。
渲染流程：
多頁面流程：
關於最後的活動頁面展示除了多頁面外其實還有特別多種方案可選，選擇最合適自己業務的就好，後邊內容會細說這幾種展示方案。
關鍵詞：JSON schema、動態渲染、動態表單、元件管理、多頁面
技術方案
動態渲染
is
如何將不同的元件打散後再重新拼裝並渲染在頁面上是整個技術方案最核心的點，好在Vue提供了動態渲染元件方案，通過內建元件conpontent，渲染一個“元元件”為動態元件並根據 is 的值，來決定哪個元件被渲染。
props
大部分元件的可配置項無非就樣式、連結、事件、文案這幾種，我們將它們抽離成一個config物件，通過props的方式傳遞給子元件用於渲染樣式或者加一些點選事件等，比如bind繫結傳進來的style樣式，當然在這之前一定要定好基礎config的規範。
渲染函式
由於一些業務的原因，Lego除基礎元件外其它部分開放的自由度並不算高，所以props的方案目前可以滿足我們的需求，但如果你想開放更高的自由度，釋放系統的完全程式設計能力，比如配置一些點選事件，事件執行互動等等。那可以試試Render渲染函式。根據官網對它的描述，它比模板要更接近編譯器。而它的可配置物件足夠你肆意發揮了。
佈局方案
視覺化佈局的方案拋開大廠不談，根據公司人員配比，建議大部分中小公司只需要以下兩種方案的一種即可。根據不同的優缺點來選擇最適合你的方案，如果條件允許也可以二者結合實現。
抽屜式
自上而下順序排列，可以更換元件位置，但不能實現元素定位，沒有層級概念，遇到複雜佈局或者需要疊放元素時不夠靈活，如果需要實現複雜頁面的效果則需要引入複合UI元件的概念，它需要大量現成的UI元件。優點是將可操作程度限定在了一個可控的範圍內，對非設計人員來說只需要通過現有UI元件進行拼裝即可生成一個美觀度較高的頁面，lego即採用的是此方案。
自由式
完全可隨意拖拽元素位置，自由度高，只需幾個基礎UI元件即可，存在層級概念，可任意疊放拼裝，在無成品UI元件的情況下diy出複雜頁面。但頁面不可控，對操作人員的美感要求更高。更適合UI同學操作使用。下圖只是一個複雜佈局的例子，關注佈局即可先不要管業務邏輯如何實現。
關於自由度
結合佈局方案聊一下關於可編輯自由度的問題，編輯自由度應該綜合實際情況進行考量。
對於lego而言，UI同學僅參與元件設計的工作而不會去使用此係統去編輯釋出活動，而當UI同學不直接參與最後的拼裝上線時，高自由度的編輯操作對我們而言其實是個雞肋，直接開放高自由度給運營人員，由於存在層級疊放且可自由拖拽，這樣就會有可能面臨著大量的不可控的頁面樣式，即使在編輯完後UI同學對頁面效果把關，但相較於改起來的時間成本和活動質量來說是得不償失的。而且高自由度帶來的是更多的技術的考量和實現成本，巢狀元件的層級規則、拖拽方案、元件定位等等….所以當你的團隊技術實力和你能得到支援的資源不是那麼充分時，也許抽屜式的半自由度方案更加適合你。
半自由度從佈局方案到元件的可配置項上來說開放程度有限，元件方面針對基礎UI元件開放相對高的配置編輯項，同時積累大量的成品UI元件可選。在編輯時不需要考慮太細節的樣式問題，保證頁面質量。
當開發人力和資源和部門協同、工作流程都到位且規範的情況下，兩種方式結合其實是最佳的方案。可以提供不同模式來供不同人員使用，甚至可以實現線上編輯器來供研發人員直接進行程式碼調整。
元件分類
Lego將元件分為了兩大類：UI元件、業務元件
UI元件細分為基礎元件和複合元件，UI元件僅用來做靜態展示用。原則是自身不包含任何業務邏輯，由於採用半開放的佈局方案，對於複雜樣式來說我們又基於基礎元件封裝了很多不同功能不同用處的複合型UI元件用以滿足更復雜頁面的需求。比如不同主題的標題、按鈕、都可以單獨封裝出來直接用於拼裝。
業務元件是指那些和服務端有互動的有業務邏輯在裡的元件，屬於獨立的功能模組，可以理解成每個業務元件都是一個單獨的活動，比如購卡、抽獎、分享等等。lego針對業務元件的唯一原則就是不在系統內提供業務相關可配置入口，僅開放基礎樣式配置，如大小、主題色等。將許可權回收至研發手中，每個業務元件在營銷後臺中配置資料，通過不同活動id進行區分渲染。因為每個業務元件釋出前都經過了QA的完整測試流程，可以最大程度保證活動的穩定性，而不至於影響到業務。
配置項
每個元件根據自身特性擁有著不同的配置項，在選中元件後展示對應的配置表單是通過動態表單完成的，Lego系統使用了IView的元件庫，每個元件除自身屬性外還會對應一份配置物件，通過匹配配置物件來描述這個表單的結構，最後還是通過compontent對錶單元件進行迴圈渲染。
通訊
對頁面配置、元件增刪、某個元素的配置項等所有編輯後的變化通過Vuex做統一管理進行通知。需要注意的是很多情況下只是改變某個物件下的一個屬性，watch監聽不到這種物件屬性變化，而像是某個樣式的其中一個屬性變動是很頻繁的，所以可以通過新增一個changeStatus的狀態，每次屬性被改變後可以更改監聽changeStatus的狀態來通知Vuex進行對應更新，但要注意做好防抖。
輸出頁面
當編輯完元件並拼裝好整個頁面後，如何將這個頁面最終暴露給使用者，在這個問題上我們設計過兩種方案：
A方案：
從公司現有的活動專案新建一個頁面，將元件庫打包釋出到私有npm倉庫進行管理並在此處引入，提供一個獲取活動配置的介面給它，所有的活動都使用這個頁面作為落地頁，通過不同的活動id來獲取不同的活動配置資訊進行動態渲染。好處是上線方便，只要在lego系統進行釋出後拿到釋出後的活動id進行拼接即可，而無需進行頁面部署。缺點也很明顯，需要等待介面請求成功後才能進行渲染，一旦介面服務報錯線上所有活動全部都會失效，而且渲染速度勢必要比靜態頁面慢。這個方案我們最終放棄了，因為除了上述問題，最關鍵的阿是從技術方面，我們的node服務開發經驗較少，從技術方案到架構方面都比較薄弱，而且最開始從設計之初沒有考慮服務併發和資料庫壓力等，一旦像是通過公眾號推送的活動，它承載的的併發是非常非常高的。所以在沒有得到服務端同學參與的情況下沒有輕易採用此方案。
B方案
大體思路同上，還是通過活動id取配置資訊渲染頁面。但把請求node服務拿配置的方式改成了訪問本地json檔案，並在落地頁的歸屬上做了一些調整。步驟如下：
1.將lego分為兩部分：編輯系統、落地頁，配置多頁面打包。2.優化多頁面打包，做好檔案分割，兩部分各自引用自身需要檔案，提升頁面載入速度。3.兩個頁面分別配置一個域名，一個負責對內編輯，一個暴露對外作為落地頁展示4.每次上線活動打包前將配置資料拉到本地儲存為json，落地頁訪問本地的靜態資源。 這個方案實現了元件庫和公共方法的公用，同時針對每個頁面做了分割，實現按需載入，保證頁面效能。將網路請求node服務改為本地json，解決了併發的效能問題。缺點是當活動越來越多的時候，本地的json會越來越大，如果不及時清理無用資料，會導致頁面載入越來越慢。lego目前採用的是這個方案，後續會再進行優化。
多頁面優化
關於多頁面的優化使用了splitChunk進行檔案的分離，將系統端用到的各種資源單獨進行分離。這樣一來每個頁面只要載入自身需要的即可。
1.刪除預設配置2.單獨匯出chunk3.指定多入口頁面單獨進行配置chunk
優化後的頁面速度
總結
1.就這個系統來說還有很多缺陷，但已經可以落地使用。像是落地頁的方案目前還有明顯缺陷，既配置資料儲存在本地在一定程度上會拖慢載入速度。社群裡的SSR服務端渲染方案、每個活動打包為單獨靜態頁的方案都可以進行嘗試。但還是那句話，根據當前團隊的技術實力以及你能動用的資源綜合進行方案的比較，有時候最好的方案不一定適合你現在的情況。2.活動搭建系統在一定意義上可以解決90%的簡單頁面，但複雜的多頁面聯動的活動還是無法做到。3.元件的積累才是重中之重，在物料不豐富的情況下，開發效率提高有限，而一旦執行一年半載元件庫豐富起來，效率將會肉眼可見的提高。4.不要覺得自己的方案一定比別人的差，可以參考社群的大佬們優秀的技術方案和思路，但要從中找到自身需要的點即可。5.堅持獨立思考、重視基礎建設使技術賦能業務是每個開發人員應有的素質，與公司無關與團隊無關，只要你有想法總會有辦法將方案推動落地，自身的思考和實現的過程中的經驗積累才是最寶貴的財富。