業(yè)務(wù)專線：15989169178
自從angular/react/vue的出現(xiàn)顛覆了前端開發(fā)者開發(fā)模式以來(lái)，雖然新的前端框架依然不斷涌現(xiàn)，但是遲遲沒有一個(gè)新的前端框架進(jìn)入廣大前端開發(fā)者的視野。本文會(huì)從近兩年越來(lái)越火的lowcode/微前端出發(fā)，探討在傳統(tǒng)前端領(lǐng)域，下一代前端工程/框架的可能方向。
一、lowcode
lowcode 其實(shí)一點(diǎn)也不新，通過 GUI、配置化的方式代替?zhèn)鹘y(tǒng)的手寫代碼編程，從sql語(yǔ)句到dreamweaver,基于模型驅(qū)動(dòng)的可視化的編程工具層出不窮。而近兩年lowcode的興起，筆者認(rèn)為主要有以下原因：1.前端技術(shù)體系及工程化體系成熟，許多有追求的工程師渴望用新的輪子追求變革式的生產(chǎn)效率突破；
2.前端開發(fā)者依舊稀缺；
3.B端業(yè)務(wù)興起，大廠提前布局，希望在未來(lái)能夠商業(yè)化從中獲利；而和歷史上諸多嘗試相比，這次前端lowcode平臺(tái)的興起最大的不同: 大多數(shù)平臺(tái)的目的是為了解決普通人的編程問題，而不再是開發(fā)者的編程效率問題。
1.1 國(guó)內(nèi)lowcode平臺(tái)
目前應(yīng)用比較廣泛的：
易企秀、淘寶天馬 這樣的基于頁(yè)面模板搭建，開發(fā)人員開發(fā)模板（或者開發(fā)人員開發(fā)模塊和模板），運(yùn)營(yíng)人員配置頁(yè)面；阿里云鳳蝶、百度愛速搭這樣的組件配置平臺(tái)（可以通過配置組件實(shí)現(xiàn)模板功能）。這些平臺(tái)都一定程度滿足了用戶快速建站的需求，特別是時(shí)間緊、沒有開發(fā)人力時(shí)。
1.2 lowcode可以解決所有問題嗎？
lowcode平臺(tái)是為了提升一部分交互簡(jiǎn)單的前端開發(fā)場(chǎng)景開發(fā)效率的，這也就是說(shuō)對(duì)于使用者來(lái)說(shuō)最大的問題在于使用場(chǎng)景及時(shí)機(jī)的判斷上：誰(shuí)來(lái)判斷使用哪個(gè)lowcode的平臺(tái)，研發(fā)還是產(chǎn)品經(jīng)理？找到平臺(tái)后，誰(shuí)來(lái)判斷哪些業(yè)務(wù)可以使用平臺(tái)搭建？誰(shuí)來(lái)搭建？當(dāng)平臺(tái)只能滿足99%需求時(shí)怎么辦？所以很多時(shí)候，我們找到了平臺(tái)，配置了頁(yè)面，最后發(fā)現(xiàn)某個(gè)需求完成不了而不了了之。當(dāng)然，許多平臺(tái)支持開發(fā)人員開發(fā)定制模板或者自定義組件，但是，當(dāng)你有了自定義組件需求時(shí)，基于平臺(tái)開發(fā)還會(huì)比自行開發(fā)效率高嗎？
1.3 場(chǎng)景舉例
我們孵化了一款新的APP，希望配置一個(gè)簡(jiǎn)單宣傳頁(yè)，頁(yè)面內(nèi)容就是一張背景圖，一個(gè)下載按鈕。
我們使用平臺(tái)配置好了頁(yè)面，也配置好了按鈕的下載鏈接，此時(shí)PM提出了新需求，當(dāng)用戶已經(jīng)安裝了APP時(shí)不再下載而是直接打開APP，我應(yīng)該基于平臺(tái)開發(fā)一個(gè)自定義的action還是自己線下開發(fā)下呢？？？
1.4 serverless
當(dāng)然，lowcode平臺(tái)也提供了一些serverless的功能，但還是那個(gè)問題，誰(shuí)來(lái)評(píng)估要不要用serverless？誰(shuí)來(lái)使用？遇到不支持的問題該怎么辦？
二、微前端要解決什么問題
微前端是一種從后端微服務(wù)借鑒過來(lái)的架構(gòu)方式。市面上微前端的方案層出不窮，我就不列了，我們只需要明確下，微前端、前端微服務(wù)到底要解決什么問題：利用服務(wù)化、微服務(wù)的概念，有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署，解決大型項(xiàng)目的管理問題。
2.1 場(chǎng)景舉例
兩個(gè)不同團(tuán)隊(duì)的業(yè)務(wù)，需要合成一個(gè)：電商平臺(tái)、視頻PC發(fā)布平臺(tái)，需要統(tǒng)一到同一個(gè)站點(diǎn)，讓用戶實(shí)現(xiàn)發(fā)布視頻、掛接商品一條路徑走通。
當(dāng)業(yè)務(wù)簡(jiǎn)單時(shí)，可以讓兩個(gè)團(tuán)隊(duì)協(xié)助工作，但是當(dāng)各自業(yè)務(wù)越來(lái)越復(fù)雜，會(huì)有越來(lái)多的問題出現(xiàn)：技術(shù)棧必須統(tǒng)一開發(fā)、部署耦合運(yùn)行時(shí)一個(gè)業(yè)務(wù)的BUG可能帶崩整個(gè)系統(tǒng)
2.2 為什么提到微前端
微前端的興起，說(shuō)明前端工程復(fù)雜度的提升，越來(lái)越多的人遇到類似的架構(gòu)問題，說(shuō)明我們需要一個(gè)更上層的應(yīng)用框架來(lái)幫助我們解決類似應(yīng)用拆分隔離這樣的架構(gòu)問題。
三、前端框架及前端工程化
3.1 前端框架
我們思考 jQuery/React/Vue 這幾個(gè)劃時(shí)代框架/類庫(kù)的共性，會(huì)發(fā)現(xiàn)他們都是為了解決視圖層的問題而誕生的。
這不難理解，傳統(tǒng)前端的核心就是視圖，如何更快的幫助前端開發(fā)者更好的完成視圖開發(fā)工作，是大部分前端框架要解決的核心問題。
jQuery簡(jiǎn)化了視圖層開發(fā)的DOM API，React/Vue 更是繞開了API，顛覆了頁(yè)面的開發(fā)模式。這個(gè)過程中，隨著前端技術(shù)的發(fā)展，工程化在框架應(yīng)用中所占比重越來(lái)越大，大多數(shù)vue使用者創(chuàng)建項(xiàng)目都是通過vue cli創(chuàng)建。
3.2 什么是前端工程化？
工程化是一種思想，主要目的是為了提效，即提高開發(fā)效率，減少不必要的重復(fù)工作。工程化常見的方向有模塊化、組件化、規(guī)范化、自動(dòng)化4個(gè)方面。
回顧前端框架的發(fā)展，會(huì)發(fā)現(xiàn)前端框架的發(fā)展其實(shí)和工程化發(fā)展相輔相成，繞開DOM API、通過工程化實(shí)現(xiàn)更低的上手成本 是vue/react成功的根本，而vue/react在代碼運(yùn)行側(cè)已經(jīng)解決了足夠多的問題，前端框架后續(xù)的發(fā)展焦點(diǎn)需要更多的偏向工程化。
四、下一代前端應(yīng)用框架
使用高度工程化的應(yīng)用框架進(jìn)一步推動(dòng)組件化發(fā)展，再度重塑開發(fā)模式，這是我認(rèn)為下一代前端應(yīng)用框架需要做的事！
換句話說(shuō)，它需要更容易的讓開發(fā)者解決組件化、自動(dòng)化、規(guī)范化等工程化的問題，可以快速讓開發(fā)者實(shí)現(xiàn)一個(gè)lowcode、procode、微前端等平臺(tái)或是架構(gòu)。
五、我們?cè)谧龅氖?/p>
lowcode、微前端都是高度工程化的架構(gòu)實(shí)踐，我們將其中的架構(gòu)思路抽離出來(lái)，開發(fā)了一個(gè)服務(wù)于開發(fā)者的前端框架，并基于框架開發(fā)了內(nèi)部的lowcode平臺(tái)：
它的實(shí)現(xiàn)分兩部分
數(shù)據(jù)驅(qū)動(dòng)的前端應(yīng)用框架，讓開發(fā)者基于json配置組織頁(yè)面
lowcode 平臺(tái)（可視化配置平臺(tái)）,將配置json映射成普通人可用的配置項(xiàng)
組件數(shù)據(jù)：
底層基于成熟ui層框架實(shí)現(xiàn)，上層通過工程化實(shí)踐，將寫頁(yè)面變成寫配置，讓開發(fā)人員在寫頁(yè)面時(shí)，只需要寫一份json配置。
前端工作變成了兩部分：通用組件開發(fā)頁(yè)面配置開發(fā)簡(jiǎn)而言之，這個(gè)框架的作用是讓開發(fā)者基于json配置組織頁(yè)面。
5.1 一些框架細(xì)節(jié)
5.1.1 規(guī)范
我們給出了組件屬性名的命名規(guī)范，對(duì)于大多數(shù)組件（業(yè)務(wù)/通用）來(lái)說(shuō)，他們有相同或相似的屬性名,例：data/children/label。
類似 useState 可以對(duì)特定屬性名做校驗(yàn)、做測(cè)試,并且輕松實(shí)現(xiàn)預(yù)編譯優(yōu)化；
降低上手難度，對(duì)于大多數(shù)組件，只需要知道組件名就能輕松上手，利于組件推廣。
5.1.2 如何解決自定義開發(fā)問題
我們把自定義開發(fā)分為兩類：
自定義組件：主要是構(gòu)建層，可以讓自定義組件單獨(dú)部署上線；
自定義action：類似發(fā)布訂閱，指定觸發(fā)類型（點(diǎn)擊）、觸發(fā)事件名（dispatch(type)）,所有action收歸頂層管理。
5.1.3 如何更快的和后端聯(lián)系
框架推薦的數(shù)據(jù)交互方式：
1.編寫action（可以使用通用action: getData 快速獲取數(shù)據(jù)）
2.組件觸發(fā)action（init/click/scroll）
3.數(shù)據(jù)獲取并掛載
4.組件訂閱數(shù)據(jù)并更新
5.2 他的優(yōu)勢(shì)是什么
按照微服務(wù)的理念，樣式、自定義組件、自定義的方法可以第三方npm、線上鏈接注入 => 更好的實(shí)現(xiàn)模塊化和模塊隔離；
開發(fā)頁(yè)面變成開發(fā)組件和寫頁(yè)面配置 => 更方便實(shí)現(xiàn)自動(dòng)化和規(guī)范化；
組件的開發(fā)有著通用、可擴(kuò)展的規(guī)范 => 更好的實(shí)現(xiàn)組件化和規(guī)范化；
針對(duì)json配置的自動(dòng)化測(cè)試，針對(duì)json配置的上線部署、熱更新等等都會(huì)更有利于實(shí)現(xiàn)工程化；
六、愿景
我們希望找到lowcode平臺(tái)和普通前端開發(fā)的平衡點(diǎn)，既能提升傳統(tǒng)前端開發(fā)的效率，又可以為lowcode的發(fā)展賦能。
我們更希望能孵化出下一代的應(yīng)用框架，解決更多開發(fā)中、工程化實(shí)踐遇到的架構(gòu)問題。
轉(zhuǎn)自微信公眾號(hào)：百度Geek說(shuō)
