作者｜ Jackie，攜程前端開發，關注組件化開發，低代碼式建設，致力于通過前端技術解決現實問題。

樂高系統是攜程市場研發部開發的活動搭建平臺，主要滿足運營所需的各種營銷、廣告、頻道、定制等頁面的快速靈活搭建。平臺在自身發展的過程中不斷改進。剛開始著力于滿足運營配置需求，滿足業務需求，不斷擴充和豐富組件庫，目前平臺已配置了10000+ 有效頁面，同時在線頁面達到1000+，組件類型300+。當體量達到一定程度后，我們又在思考，平臺能力的邊界在哪里，如何推動平臺創造更大的價值？

這個時候，建設平臺不再局限于擴展組件等基礎建設，會更多地考慮如何將平臺建設為一種“開放性”的平臺，將平臺優秀，成熟，可擴展的“點“開放出去，使平臺或者平臺相關技術在其他團隊或者場景中有更多的應用，產生更大的價值。這種開放性的思路，也積極促進了平臺的進一步發展。

這篇文章將總結我們在平臺建設中一些相關思考和實現細節。

一、組件開放性建設 - 自定義擴展

在經過了自給自足的初期階段之后，我們覺得組件化、“低代碼式” 的搭建思路是正確的方向，一方面給運營同學提供了極大的方便，另一方面組件的“良性循環、迭代”促使組件功能更豐富，更靈活，更可靠。并且開發人員不需要把時間浪費在重復勞動上，可以設計和開發出更具通用性，更可靠，更“新”的組件模塊。

因此，除了在樂高平臺上“發揮能力”，我們希望樂高上的“業務組件”，“配置能力”等可以幾乎“無限制”的提供給其他開發者在其他需求中使用，因此進一步改造了平臺，使樂高平臺的組件庫更容易擴展，性能更好，使用性更廣。

樂高渲染和開發環境都是基于公司成熟的服務端渲染框架NFES，技術棧選擇為react+nextjs+mobx。

如渲染示意圖：

樂高整體框架相當于一個容器：

1）負責組織組件關系

例如父子組件關系，嵌套關系，組件依賴關系，數據依賴關系等。

2）解析組件

容器會提供公共模塊的注入（如：react，react-dom，公共庫等），目的是為了公共依賴的統一，并且還減小包的大小。容器在客戶端和服務端分別解析當前組件，以供渲染使用。

由于頁面其實是由多個不同組件構成，因此需要支持到組件級別深度的SSR（實現方式在后文會有說明）。

3）遞歸式渲染組件

組件結構可以看成是輕量的DSL，整體簡潔、扁平，不過為了能夠靈活的處理組件依賴、控制組件渲染時機（先后）、處理父子組件等問題，容器內部在node中間層“處理完數據結構”之后采用了“遞歸式”渲染的方式處理組件。例如tab切換類組件，tab關聯的可能還是tab切換，如此反復，其實就是個遞歸的過程。

1.1 構建組件?

樂高組件最終形式是一份UMD代碼，事實上是一份同構代碼，既能在服務端渲染又能在客戶端渲染。頁面渲染的時候，能夠在服務端和客戶端“按需”的，“動態”的拉取某個組件的資源包，這些也是為了組件解耦，方便擴展新組件，提升頁面渲染性能，同時為“多場景的使用組件”這一目標打下基礎。

“多場景的使用組件”，即為：

• 可以在樂高渲染引擎中動態使用
• 可以npm單包輸出
• 可以通過sdk（樂高渲染外殼+webapi接口）整體渲染引入到其他三方頁面

?這些是樂高組件可以充分發揮能力的幾個方面。為了達到這些需要在組件構建環節進行處理，如下：

1）構建“動態組件”資源包(js、css)，并支持同構渲染

構建工具默認打出的UMD包無法滿足樂高特定的渲染需求，需要自定義一些webpack插件干預構建結果，如：如何解決動態組件的公共依賴問題，如何使得渲染引擎能夠在客戶端和服務端都能夠解析到動態組件實例。

首先需要改造組件的最終形式，使其可以接收公共依賴（react，react-dom，公共依賴等），這時可以修改默認打出的UMD自執行函數，使其返回一個普通函數，“依賴”可以通過渲染引擎在解析時通過“形參”變量傳入，如：

如圖，banner組件依賴React等，因此構建自動改變組件打包結果，使得banner成為這樣一個“function”：通過執行傳入e.React，e.ReactDom等依賴后，return得到真正的組件包。

實現方法是在自定義plugin中，接管組件的打包過程，替換依賴部分的代碼，將真正需要的依賴如react，react-dom等以形式參數的“代碼字符串”寫入到組件文件里面，最終通過替換字符串代碼改寫組件構建的結果（組件的文本字符串）。

此外客戶端還需要使得打包后的資源能夠掛載在某個全局對象下，以方便渲染時候按需獲取組件對象，這就需要通過配置構建工具實現。

而webpack的配置項globalObject的作用為：

• 當輸出為 library 時，尤其是當 libraryTarget 為 'umd'時，此選項將決定使用哪個對象來掛載 library。

這個正好可以為我們所用，如下：

客戶端通過注入腳本script的方式將組件掛載到前文提到的全局變量window.LEGAO_COMPONENTS上面，渲染引擎將通過組件唯一標志（組件英文名）獲取到組件實例。?

最終在服務端和客戶端通過不同的方式獲取到真正的組件：

客戶端：

• window.LEGAO_COMPONENTS[component.name](dependency).default獲取

服務端：

• component.realComponnet(dependency).default獲取

2）實現按需（服務端和客戶端）動態拉取組件

“樂高組件”可以托管到到公司框架部門開發的現成的靜態資源管理平臺ARES上面，它既能快速將我們的資源（組件的js,css）發布到CDN上面，又能夠幫助我們管理資源version，此外還支持自動線上構建（CI/CD）發布單個或多個組件包資源，相關API也很完善，如：

樂高腳手架通過ARES的“commit信息觸發CI/CD”機制，將單個或多個組件發布到CDN上面，當頁面被訪問時，渲染引擎會根據當前所需的“組件類型”按需拉取組件。

渲染引擎通過ARES相應的API（如：在node端預熱組件資源，獲取單個組件最新有效版本，資源地址等）獲取到資源地址，然后在服務端下載組件的javascript資源文件的文本內容，并通過requireFromString將字符串文件轉換為內存變量module，即而完成服務端的渲染，而客戶端則動態加載這些異步js，完成客戶端的渲染。

1.2 樂高腳手架@ctrip/legao-cli?

樂高平臺目前不僅“服務于”市場部活動組，越來越多團隊通過自定義組件的形式接入，例如一些頻道頁的模塊，用了現成的組件，業務邏輯不同的組件則由團隊自己定制開發。不僅達到組件“開發一次，到處使用”，還使得相關團隊的運營也能充分利用到樂高的便利配置系統。

為了建設“開放性”平臺，我們也需要做好開發環境的建設，以方便更多團隊開發組件。

@ctrip/legao-cli 能夠創建跟線上運行環境高度一致的“開發環境”，能夠通過proxy模式，代理測試線上代碼，能夠構建組件資源等。如下：

開發環境項目作用：

• 提供組件本地開發環境
• 可作為組件倉庫
• 可配置本地開發組件配置信息
• 配置線上打包（CI/CD）配置信息等

項目目錄說明：

• common : 組件公共模塊
• packages : 組件目錄
• legao.config.js : 組件開發配置項
• postcss.config.js等

其中legao.config.js影響開發環境最終拉取組件形式：

配置說明：

• env：組件及渲染server的接口請求環境
• components：當前需要開發調試或者代理的組件名稱
• devMode：為開發提供兩種調試模式：

1）dev：本地開發模式

組件默認走本地資源，相當于import xxx的形式，這種方式主要是方便開發環境的調試（更好的熱更新），開發環境會做好組件的引用，標記，獲取實例等工作。

server端讀取組件目錄mock/mockData.json的配置數據，作為組件的屬性傳入并渲染組件。

2）proxy：代理模式

在本地能夠代理和調試線上頁面內的對應組件，server端會請求線上頁面的組件配置數據，匹配替換頁面內對應組件的js模塊為本地模塊。

開啟這種模式后，通過一些配置就能完全模擬生產環境。

步驟為：設置生產host→在legao.config.js中配置需要代理的組件名稱→用https協議打開生產環境的頁面地址→完成。

1.3 開發環境其他配置項

開發環境默認設置了滿足當前開發和構建需求的各種配置，如babel配置（plugins, preset等），postcss配置，也支持擴展、修改這些構建配置項。“構建組件”的時候會讀取合并之后的配置項。

如postcss配置項，目前默認是采用postcss-px-to-viewport來處理組件的UI適配，可以根據需求修改或者增加其他處理配置項。（這里推薦用vw來做適配，比起rem，組件不依賴外部。像rem需要依賴根字體大小，但不同項目設置的計算比例是不一樣的，所以根字體大小無法保證統一，這樣不利于組件嵌入到其他項目（如sdk方式，npm包方式））。

?1.4 公共庫注入：@ctrip/easy

開發一個再簡單的頁面都需要面臨“水面下的冰山”，除了要實現核心邏輯，還需要實現其他必要功能。如“分享功能”，需要兼容app環境，微信h5環境，微信小程序嵌套環境，快應用，甚至其他app環境等等的方法，還有跳轉、登陸等，這些往往比我們最終要做的頁面的核心業務還要復雜。于是樂高結合現實開發需求，總結歸納了常用的方法，總結了通用庫：@ctrip/easy。

?這個庫提供了封裝大部分情況分享的setShare方法，兼容大部分情況的jump方法，還有login，model等等。樂高框架會向組件“注入”這個幾乎每個項目開發都需要的“業務方法”庫，使得任何樂高組件在實時渲染環境都可以直接使用。有了這個“環境”，開發者能夠集中精力快速開發組件中的業務核心代碼。

當然它也能單獨以npm形式引用。目前在公司內有了很多接入，節省了開發時間，提供了最佳實踐的方法。

二、組件開發特殊函數 - 為現實開發需求設計

作為一個開放性的平臺，在現實開發組件過程中，有一些比較特殊且必要的情況需要支持。

• 組件不是扁平羅列的結構，而是可以相互依賴和嵌套的（如父子組件，先后渲染依賴等）
• 需要有數據上的通信機制（數據依賴）
• 需要有組件級別的SSR為了滿足這些需求，樂高設計了一些簡單有效的機制。會“預處理”一些能夠運行在node端（中間層，頁面渲染之前）的靜態方法，渲染引擎會遍歷所有的組件，在拿到組件實例之后，判斷哪些組件是否含有這些靜態方法，然后通過執行這些靜態方法，把影響后續組件渲染的所有數據處理好。方法如下：

2.1 beforeRender靜態方法

作用：組件嵌套、依賴，組織組件關系等

組件使用實例：

如上圖，這是一個tab切換類組件，它的作用是切換其他任意的組件，它需要在beforeRender里面聲明好頁面上的哪些組件是它的子組件。為了處理這種父子依賴關系的組件，渲染引擎會利用這個函數在渲染之前就把所有父組件和子組件分開，放在兩個數組中，并把最終有依賴關系的數據結構傳給頁面渲染的部分，進行后續渲染。

說明：

第一個變量componentData，為該組件的配置數據，渲染引擎根據componentData下配置的關聯的“子組件id”等數據知道“當前頁面”上具體哪些組件是這個組件的子組件或者父組件，第二個變量為一個對象，對象包含幾個框架提供的方法，如：

分別對應下圖中的幾種情況：

2.2 asyncData靜態方法

作用：可以作為組件的服務端，中間層（node環境）

說明：主要用于在服務端請求接口獲取數據，需返回一個promise，最終執行結果數據，會在中間層賦值給當前組件的一個屬性：__FETCHED_DATA__。在服務端渲染的時候，組件第一時間可以拿到請求之后的數據，所以可以更充足、更細致的“ssr”。組件內部則可以根據“這個變量”來選擇是服務端渲染還是客戶端重新請求數據去渲染。

使用demo：

?這個函數的作用還有以下幾個其他的方面：

1）因為這個方法的執行環境是node，所以可以“直連”調用node接口和方法。不過這里的require是作用在node環境的，其實并不需要解析，例如require(“ctriputil”)，于是可以通過配置rule，利用string-replace-loader自動將require替換為__non_webpack_require__，來防止webpack處理require的資源，例如：

?2）req可以掛載單次請求級別的全局變量，例如一個頁面上有多個同一類型組件，每個都需要在node環境獲取用戶信息，那這個信息就可以掛載在req，防止同種組件重復請求。

3）allComponents參數：可以在此基礎上自定義邏輯，如修改其他組件的property控制它的具體渲染。

4）如有seo相關需求，可在asyncData resolve數據中返回自定義seo數據（框架會提前處理好動態meta等seo相關數據）。

2.3 provideData靜態變量

作用：狀態管理，公共變量，組件通信

說明：組件維度將某個變量注冊到全局store，可以提供給其他組件使用（訂閱數據）。如下圖所示，一個頁面上有一個“定位組件”和幾個依賴定位組件的組件，這些組件不僅需要在渲染時候能夠響應定位組件分發的定位數據，還需要再定位組件“點選城市”之后能夠響應數據的變化，從而刷新渲染。

實現是基于mobx，樂高渲染引擎會先在中間層通過組件上的provideData靜態變量搜集所有需要注冊到store的數據，然后在頁面渲染獲取組件module的時候，用mobx-react的observer包裹，使這個組件變成“reactive”的，最后將這些數據的宿主對象extraProps掛載在組件上，用來獲取數據，和改變全局數據。如props.extraProps.geoInfos等。使用demo，數據提供方：

數據使用方：

?也可以放在如useEffect中監聽（類組件可通過在componentDidUpdate等生命周期中監聽）props.extraProp上的具體某個字段，如定位信息geoInfo。

?那么所有監聽了extraProps.geoInfo的組件都會在“定位組件”分發了定位信息“ geoInfo ”之后觸發自身的渲染更新。

三、“在線依賴組件”探索 - 在線公共組件

很多機制的思考、開發動機都是來自于現實問題，開發研究也是不斷提取這些問題的本質，抽象化，并把解決方案具體化，在線公共組件也是在實際開發問題中提煉出來的。

考慮這樣一種情形，一個產品組件A，經過不斷的迭代擴展，有了十數種樣式，代碼實現很簡單，先抽取一個本地依賴的子組件如SingleProduct，然后通過產品組件A向SingleProduct傳入需要渲染的模板類型type字段等，最終在SingleProduct里面進行區分和渲染不同的UI。

?然后，需求來了，我們又要新增一些業務邏輯完全不同的產品組件B，C，D等等，并希望能夠完全復用組件A的樣式和業務邏輯（跳轉，埋點等），甚至是為B，C等組件新增的UI，也希望能夠在A組件里面能夠復用。

這個時候一般做法是直接復制組件A的代碼到組件B本地，或者破釜沉舟，將組件A和組件B等通用的樣式抽取成為UI組件，后者能解決一部分模板復用問題，但是事實情況是如果需要修改的UI組件的一丁點代碼，都需要將所有依賴它的組件A，B，C，D等等分別打包，發布，測試，上線，這無疑增加許多維護成本。而且“代碼復制，搬家的方式”從開發角度來看，存在代碼同步的問題，維護起來非常困難。另外，組件A，B，C等等每一個組件都打進來了需要復用的UI組件的所有資源。如果都用在同一個頁面上，就等于重復代碼一大堆，這又肯定增大了總體資源的大小。

?再比如：平臺已經有視頻組件，運營同學可以根據需求，給運營頁面增加視頻組件，他們可以自行配置視頻地址，封面等。這種視頻組件經過了長期迭代，已經是一種比較成熟的視頻組件了。如果新增的一種產品業務模塊，正好需要實現播放視頻的效果，那是自己copy代碼，重新實現一遍，還是直接復用之前開發的視頻組件呢？最方便的做法是希望能夠動態復用視頻組件，即，在“產品組件”需要視頻組件的時候才會拉取視頻組件，不需要的時候，代碼中是不會有視頻組件的資源的。

我們第一時間會想到走npm包的方式import引入，這是一種方式，但是這種要求我們引用的npm包的版本是最新的、沒有問題的版本。首先那么多的組件是否有精力都去維護npm包是一個問題（因為主要的使用方式是“樂高拉取CDN組件”，一般不需要打npm包，而且組件普遍功能迭代很快），其次npm引入的資源被直接打在了你的組件包里面。

我們都知道package.json里面的main，module，browser等的作用，它為了使最終包能夠根據不同的環境打出相對純凈的包，設計了區分不同環境的標志，并通過構建工具按需打出最終包。

所以，希望能夠考慮一種比較好的方案，既方便新增，維護，使用，又能夠獨立，減輕頁面資源大小。

事實上，通過這個案例，可以思考更多的類似使用場景。試想，如果一個部門的所有的公共組件資源能夠以一種在線引用的方式維護在CDN上面（云端），以供大家使用，這是不是一種非常方便復用公共組件的方式，同時非常方便維護更新。這是不是能夠大大促進“組件化”開發的良性循環呢？

如下圖：

?樂高組件眾多，300+組件，有豐富的組件資源，應該是比較適合這種的一種場景。

接上文產品組件的問題，現在樂高有了一種這種“云”依賴組件的機制，我們可以開發“UI原子組件”，這種組件就是純靜態的UI組件，也是普通的樂高組件，支持跟其他“樂高組件”一樣的各種機制，擁有一樣的數據結構。

那么現在我們可以在產品組件A，B等里面聲明依賴“UI原子組件”，然后傳入“原子組件”所需要的所有的業務字段，渲染類型字段等，這樣就可以使所有的產品組件（A，B，C…）使用到“UI原子組件”的樣式，這個組件能夠不斷迭代優化下去。而需要修改、維護UI的時候，基本只需要發布“UI原子組件”這一個組件就好了。

?樂高組件可以通過fnGetMetaComponent在任意組件里面動態的拉取線上的其他組件并使用。

此方法會掛載在組件props上，“在線引用”其他樂高組件，并覆蓋其渲染props（如id，property等）。產品列表中需要新增視頻展示，則產品組件可以關聯引用“視頻組件”，并將列表項的數據（如視頻地址）傳給視頻組件，用作渲染。

真實使用情形有兩種：

情況1：通過已保存的組件的唯一id拉取。

這種在樂高平臺的情況是：依賴的組件已配置到頁面（已保存，并生成了id）的組件。

其他組件可以用fnGetMetaComponent通過id依賴該線上組件，這種的使用場景下，被依賴的組件能夠讀取兩部分配置數據，一部分來自運營通過樂高offline配置，一部分是來自開發賦值，如：?

demo：

情況2：通過“組件類型名”拉取，支持服務端請求數據：這種就相當于import一個組件，但是沒有實際打包引入，而是通過在線資源引入。

demo：

?此外還可以提供插槽，如fnRenderProps方法：自定義內容插槽，可在父組件中自定義內部渲染，例如抽取AtomSwiper組件，只負責引入swiper和輪播，至于輪播的內容（組件）則可以通過fnRenderProps定義。

實現的大概過程如下：

• 渲染引擎在node環境（頁面渲染之前）識別“需要依賴的”組件，在線拉取和解析，并處理其服務端請求。

在處理這些“原子組件”服務端請求的數據時需要通過renderBy這樣的“依賴它的組件id”來區分哪份數據掛載在哪個渲染運行時下，因為原子組件需要考慮一份組件多次復用的情況。

fnGetMetaComponents則負責從所有的“在線組件”中查找，并覆蓋其渲染屬性，并返回最終需要渲染的組件。

目前樂高已經有較多這種 “在線組件”的使用場景。例如上文說到的產品組件，通過這種方式拆分為幾個組件：

• 產品組件（包含業務邏輯）
• 輪播組件、視頻組件
• 原子UI組件

如下圖：

?如此，三個組件都可以單獨復用，單獨按需拉取，單獨維護。

四、@ctrip/legao-nfes-sdk建設：組件移植渲染      

樂高組件建設希望開發的組件，無論業務組件也好，通用組件，在線組件也好，能夠不局限于只在樂高平臺本身使用。

當然組件已經支持打包npm包了，為什么還需要sdk呢？

還是為了方便維護和使用。通過sdk能夠根據運營配置需求動態拉取需要的組件，以及組件資源，并且這種對接方式對于接入方來說簡單，易用，更新任何組件都不需要重新發布。能夠做到“動態資源，實時拉取，按需加載”，使“樂高組件”能夠無縫渲染到其他頁面。

如下圖：

嵌入案例：

?實現方式其實就是把樂高渲染引擎拆分成渲染sdk和webapi服務，服務是基于公司的serverless開發的webapi，扮演樂高渲染引擎的中間層服務的角色。

?目前這種對接方式已經大量在各種對接三方頁面的場景中使用（如任務組件，選貨組件，星球號，商城，會員，售賣等等），事實證明，這種輕量、友好的方式能夠推動樂高組件的更多使用，也屬于樂高“開放性建設”的一個方面。

五、動態表單能力建設

樂高有大量的組件，每個組件都有不同的屬性配置面板，如果都去花費人力開發維護，則無疑是一項巨大的工作，不利于組件的擴展，于是我們基于自身需求，開發了“動態表單”。初期是希望能夠解決組件的配置問題，但是后來建設中覺得這種表單其實有更廣闊的應用場景，可以走出樂高，走向公司，為更多類似的表單場景提供配置能力，這也是樂高“開放性”建設的思考的一個點。

動態表單孵化于建設平臺過程中，是一種可視化在線配置動態表單方案，專注于解決通用常規表單的可視化自由配置，目前能夠解決大部分的常規表單的在線配置場景，支持數據聯動、復雜數據嵌套、拖拽布局等。

已實現的動態表單具有如下亮點：

• 可視化：可視化搭建、修改和預覽表單。
• 可拖拽布局：控件可在畫布內拖拽至任意坐標，以搭建最佳布局。
• 可擴展：可二次開發，可擴展控件集。
• 可聯動：某個控件可以控制別的控件的顯示和隱藏。
• 支持復雜數據類型：支持對象結構以及對象數組結構等復雜數據類型(JSON)的配置。

基本架構模塊如下：

渲染介紹

系統有表單生成器編輯面板Form Generator，表單渲染入口Form Viewer兩個主要模塊。這兩個模塊共用常規的基礎組件如輸入框，顏色選擇等，還有一些基于業務擴展的復雜組件，例如熱區選擇，視頻上傳，數據聚合（JSON列表）等。

?目前，動態表單已經大量使用在樂高的組件配置界面，如：

?當然，樂高開放性建設的最終目標是，期望動態表單能夠作為成熟的獨立的npm包，為其他表單場景提供公共功能，打造輕量“泛應用”動態表單。

六、其他方面

樂高系統的靈活，以“開放性”建設為目標還催生了一些其他方面的能力。

6.1 靜態頁面建設能力：DIY

樂高除了有已開發好的組件外，還提供了一種可供運營同學配置靜態模塊的能力，稱作“DIY組件”。這部分可以讓運營同學自行拖拽配置自定義的模塊，例如配置不同形式的表單表單提交模塊，配置靜態頁面，最終以組件形式由樂高渲染。

?樂高開放了這個界面的拖拽配置能力和接口服務能力，比如你有一個需要運營自己拖拽配置界面的需求，但是不需要樂高默認的渲染，那你可以在這個場景下新增場景，并配置自定義字段。然后將上圖中的“可選字段組件”跟這些自定義字段進行關聯，使用方（也就是開發同學）通過接口獲取運營同學配置之后的數據，就可以根據實際需求進行渲染（可不依賴樂高渲染）。

6.2 產品樣式擴展：產品畫布

樂高基于“DIY組件”擴展了產品畫布的功能，之前提到的 “原子產品組件”配合產品畫布功能可以擴展更多“自定義的樣式”。

?運營同學通過樂高的“DIY組件”，可自主拖拽配置產品UI界面，最后只需要把“產品畫布”的場景號配置到上述的“原子產品UI組件”的屬性中，即可實現自定義渲染界面，如圖：

6.3 npm倉庫建設

樂高打包機制增加了構建為npm包的配置，并打包到單獨的文件夾中（方便發布npm包）。

?腳手架在打包“樂高框架”所需要的umd包的同時，也同時打出適用于npm方式引入的React組件包。發布了這些npm包（react組件）后，就能被使用方import引用。

另外樂高有很多一些交互復雜，并且效果不錯的組件，如轉盤組件，九宮格，紅包雨等等，這些組件默認是跟業務邏輯緊密相連的，有使用方想用這些交互，而里面的具體邏輯自己實現，所以開放一些成熟的靜態組件是有必要的。

樂高基于目前的組件庫在建設一個靜態組件庫，基于storybook，根據“實際需求”去逐步開放一些純靜態的組件，例如轉盤抽獎等。

?另外，可以開放一些上面提到的UI原子組件如（產品UI組件，定位組件等），這些組件是相對獨立，可復用的組件，可以嘗試在樂高之外的其他頁面上復用，走樂高sdk復用，或者npm包復用。

6.4 熱區能力建設

熱區能力最初是由配置banner而來。剛開始為了復雜多變的banner配置，我們開發了banner組件，多banner組件等，但是后來發現，需求要配置比例大小不一的多banner，甚至是圖形不規則的復雜banner，這個時候再從配置上增加字段顯然是不好的，配置復雜不說，圖片被切的支離破碎，從最終的渲染效果上有可能因為圖片較大，網絡較差，看起來也是支離破碎的。

從運營同學的角度看，這簡直是折磨，要切一大堆的圖，要配置一堆參數，到后來由于要配置極度不規則的圖形（例如地圖那種banner）直接沒有了辦法，這才催生了我們開發熱區banner。

?樂高支持的熱區可以支持任意圖形的熱區（通過多個定位點連接起來）。

?具體實現方案也經過了一系列的改進，最開始的基于html的map和area標簽法，如：

?后來優化為記錄點的坐標以及圖片的寬高方法，通過點擊事件獲取到點擊時相對于圖片的坐標。最終遍歷每個熱區的描點坐標信息，判斷點擊坐標是否在當前熱區中（實現思路——射線法，從點發射一條射線，點在多邊形內則會產生奇數個交點，點在多邊形外則有偶數個交點）。

熱區banner一上線就大量被使用，節省了運營同學配置時間，極大的提高了banner配置的效率，也優化了這一塊的渲染效果。

既然熱區這么好用，應該擴展到別的方面，于是就有了熱區規則，熱區tab切換等。甚至是可以考慮將具體交互，如點擊跳轉，點擊領券，點擊彈出等等封裝為事件組件，將UI和交互事件解耦。

從配置面板到熱區渲染這一套流程可以開放出來給開發同學使用，如上圖的banner，甚至是更復雜的拼接banner，即使是開發來做，都需要耗費大量精力去擺位置，切圖等。如果遇到復雜的banner，可以直接使用樂高的熱區banner配置。如果需要的只是熱區的配置和區域數據，可以利用樂高開發的“熱區采集工具“收集運營配置的熱區數據，根據實際開發需要處理渲染或邏輯。?

最后

上面提到的眾多的“開放性”建設，有成熟的，有在實踐嘗試中的，還有正在規劃和思考的，我們的目標是立足當下，維護好成熟的，努力建設還在實踐嘗試中的，然后不斷的思考優秀的、可以更進一步優化的“點”。

開放性建設是雙向促進的，既能給開發同學帶來方便和最佳實踐，同時也在反向推動“樂高”平臺的優化，給運營同學帶來諸多方便。

樂高的開發是不斷的發現和總結來自于現實的問題，提取問題的本質，抽象化問題，具象化解決方案，來逐步優化和擴展平臺，這樣才能在有限的資源下推動平臺創造更大的價值。