頁面可視化搭建, 是一個歷久彌新的話題. 更廣義上講, 頁面是 GUI 的一部分, GUI 的拖拉生成在各種開發工具上很常見, 如 Android Studio, Xcode, Visual Studio 等. 前端頁面早在十幾年前就能用 Dreamweaver, Frontpage 等工具可視化搭建出來.
但是現在已經很少人使用 Dreamweaver 了, 其主要原因是頁面承載的內容已經和頁面源碼分離, 由后端接口返回再渲染到頁面, 靜態頁面網站無法承載大量的動態內容.
大多數互聯網公司需要做許多的活動頁面來承載運營業務. 運營活動頁面的特點是: 頁面功能大同小異、需求急、時間緊、下線快、研發性很比低.
前端工程師無法持續開發無窮無盡的活動頁面, 需要采用活動頁面可視化搭建工具, 由運營人員/產品人員直接生成活動頁面.
研發人員的工作轉變為提供滿足活動頁面業務需要的活動模板.
中后台系統開發
在公司內部, 需要做許多的中后台支持系統, 這些系統的管理端一般用 web 頁面承載. 那么問題來了, 中后台系統的前端工程, 怎么保障可用性、可維護性和頁面呈現一致性? 這些系統與后台邏輯強關聯, 一般由后台開發人員開發; 后台開發人員寫代碼邏輯是沒有問題的, 但是其前端開發能力相對較弱. 所以需要增強他們開發前端頁面的能力, 前端開發能力由前端服務化提供.
前端服務化的第一種方式是提供一套組件庫, 如 餓了么的 Element.
組件庫一般由前端開發人員封裝成模板工程, 模板工程提供公共樣式和函數庫, 並對編寫的代碼做校驗和約束, 一定程度上降低了前端開發難度, 統一后台人員代碼風格. 此時后台開發人員的開發方式為: 在代碼中用組件拼湊頁面, 然后寫代碼邏輯.
前端服務化的第二種方式, 是提供頁面可視化組裝系統, 這個系統輸出組裝后的前端工程源碼. 這樣的系統比提供組件庫和模板工程的方式走得更遠: 通過可視化生成模板工程, 后台開發人員不需要在代碼中拼湊前端頁面, 不需要關注前端組件, 只需要編寫代碼邏輯.
這種方式可以參考阿里的 ice.
Dynamic Logic 編輯
這類頁面搭建工具支持在界面上輸入邏輯代碼, 實現頁面 Dynamic Logic 編輯, 如后台接口請求邏輯, 業務判斷邏輯等.
這些邏輯代碼需要有合適的插入點, 一般在事件鈎子中提供插入點, 如頁面 onload、網絡請求狀態變更、按鈕事件、數據變更等.
做到可以支持編輯 Dynamic Logic 是超牛逼的事情, 這類工具對頁面的理解最深入, 對開發者的技術能力、前端架構能力和開發能力都要求很高.
總結
- 頁面由
HTML Tree,Data,Dynamic Login組成. - 頁面可視化搭建工具用於提升各類人員的頁面搭建效率.
- 頁面可視化搭建其實是前端服務化的方式.
- 頁面可視化搭建工具需要平衡自由度和效率.
- 組件和模板是頁面可視化搭建框架的核心.
參考鏈接:
https://github.com/CntChen/cntchen.github.io/issues/15
在數據驅動的大背景下，應用框架處理的問題實際上只有一個：數據管理。
其中“數據”既包括組件數據也包括業務數據，而“管理”既包括如何保存數據，也包括以何種方式讓用戶來讀寫數據。
我們仍然從使用場景出發，來分析出數據管理的應用場景，最后再考慮設計實現。
在前端領域內，用戶對交互的需求是漸進增長的，業務的需求是漸進的，因此應用的復雜度整體看來也是漸進的。
所以我們只需要明確出最簡單和最復雜的情況，就可以勾勒出框架需要支持的范圍了：
- 按業務經驗，最簡單的情況無非就是純展示的“詳情頁” 或 “列表頁”。最符合本能的邏輯寫法應該是:
- 拼好組件樹。如果是靜態的數據，直接在每個組件上的屬性里設置好即可，流程結束。
- 如果是動態數據，那么使用 ajax 獲取到數據。將獲取的數據格式化成組件所能接受的格式，然后使用 api set 進去。
在這個場景中用戶需要了解兩件事情:
- 組件的數據格式，實際上就是組件的屬性，在 IDE 中已經是直接暴露出來的。
- 設置數據的 api 。
再接着看最復雜的場景，我所接觸過的最復雜的前端應用都是業務關聯極強的工具，例如雲計算平台的控制台，客服系統的控制台，包括這個 IDE 也算。這類產品的復雜體現在兩個方面:
- 有大量的交互細節，例如組件狀態要和權限結合(例如 按鈕的 disable 狀態)、組件要根據需求動態顯示或隱藏，表單的校驗，異步狀態的提示或管理(例如發送請求后，按鈕上出現loading)。
- 除了組件數據，還有大量的業務數據要管理，並且是其中有很多聯動關系。例如在雲計算控制台里面有 ECS、LBS 等概念，ECS 和 LBS 有關聯關系，ECS如果改名了。不僅要更新ECS自己的詳情顯示，還要自動更新關聯的LBS的顯示等。
有了這兩個端點，就找到了要提供的能力的上限和下限，接下來就是框架設計中最有意思也最困難的部分了——如何提供漸進式地開發體驗。這幾乎也是所有優秀框架的共有的一個品質。漸進式的體驗意味着用戶只要了解最基本的功能就能馬上開始工作，當要處理更高級的需求時才需要再學習高級的功能。更進一步話，最好這些高級功能也是用一種可擴展的機制來實現的，如中間件，學習一次機制，即可解決無限的問題。
異步狀態數據源:
打開這個思路后，你會發現幾乎其他所有問題，都可以用這個方案來解了！
為專有的問題領域建立專有的數據源，同時建立數據源到組件數據源的映射關系。即能擴展能力，又能分離代碼。