摘要：在初步完成了在線流程圖編輯工具之后又接到了在線搭建頁面工具的需求剛開始其實并不想接項目因為從歷史以及現(xiàn)實原因來看個性化及動態(tài)渲染都是很難解決的痛點各種頁面搭建工具的不溫不火早已說明了這條路并沒有這么好走但從另一個方面來說既然有了這樣的需求那

在初步完成了在線流程圖編輯工具之后,又接到了在線搭建頁面工具的需求,剛開始其實并不想接項目,因為從歷史以及現(xiàn)實原因來看,個性化及動態(tài)渲染都是很難解決的痛點,各種H5頁面搭建工具的不溫不火早已說明了這條路并沒有這么好走,但從另一個方面來說,既然有了這樣的需求,那也就說明了現(xiàn)實的工作流程確實存在問題,本著解決問題的心態(tài),說不定可以從工具及產(chǎn)生的新式組件部分重新梳理底層開發(fā)規(guī)范,從而側(cè)面增強我司前端部門的重要程度.人總要有夢想是吧...

簡介

項目初版部分UI 組件使用了ant design加快進度.到目前為止基本解決內(nèi)部創(chuàng)建頁面模板,并發(fā)布到用戶服務(wù)器的流程.

目標

通過托拉拽方式快速生成頁面模板,進行預(yù)覽及發(fā)布.

使用人群分析

普通用戶需要所見即碎得的編輯方式,通過簡單,學(xué)習(xí)成本低的操作,比如拖拽頁面元素的方式來達到快速生成頁面的效果.當然,當頁面元素過多時,實際上拖拽的方式,就不如樹形結(jié)構(gòu)容易定位和編輯(可參考ps等軟件).

而對于運營人員甚至是原模板制作人員來說,除了希望通過操作已有組件進行頁面排版之外,還希望可以通過屬性配置及方法修改來完成獨立業(yè)務(wù)場景的活動頁面.

對于中后臺系統(tǒng)開發(fā)人員來說,大量的表單頁面以及更加復(fù)雜的業(yè)務(wù)流程流轉(zhuǎn),不僅需要頁面搭建工具,甚至做在線的IDE都不為過,當然現(xiàn)階段版本暫時不需要這種復(fù)雜場景.但在考慮整體架構(gòu)時,仍然需要針對這一情況進行分析.

為什么使用可視化搭建工具,而不是自研UI框架?

一方面工具能夠提高內(nèi)部開發(fā)效率,更快完成修改及簡單制作需求,而自研UI框架的難點在于如何持續(xù)投入,對于中小企業(yè)而言,盈利才是最終目標,就是對于模板開發(fā)人員來說,一個擁有眾多樣例及解決方案的開源庫,在實際工作中也能節(jié)省大量的時間.之前內(nèi)部失敗的幾個前端UI組件庫已經(jīng)說明了這一點,開發(fā)成本,實際用例,問題解決,相關(guān)文檔都會帶來各種各樣的問題.

另一方面,業(yè)務(wù)的大量擴張,各個業(yè)務(wù)線所要求的人力成本越來越高,逐漸走向惡性循環(huán).從用戶角度來說,越來越長的交付時間帶來的是體驗與質(zhì)量的大幅下降,阻礙了進一步的發(fā)展.

結(jié)合實際情況

這次的重點其實在于如何提高初級前端開發(fā)者的開發(fā)效率以及解決運營人員的上線后可維護的問題.那么,從產(chǎn)品形態(tài)來說,可以參考Dreamweaver的部分界面,比如設(shè)計視圖與預(yù)覽視圖.這樣可減少我司大部分模板開發(fā)人員的學(xué)習(xí)成本.
另外,通過提供部分開放的代碼編輯能力,來解決特殊的個性化需求.
這么看來,我一開始想的使用現(xiàn)有前端框架進行改造升級以及推動新的組件開發(fā)規(guī)范根本不現(xiàn)實.
因此,決定工具本身使用react進行實現(xiàn),組件部分結(jié)合已有的后臺模板字符串方式,劃分好樣式及腳本命名空間,按需加載即可.

功能實現(xiàn)

按照上述梳理,得出工具核心功能在于編輯狀態(tài)下的拖拽布局與組件屬性編輯以及預(yù)覽模式下的解析展示部分.再按照實際情況定義新的組件開發(fā)規(guī)范,并準備好組件管理系統(tǒng),就能完成初版目標.
這里的組件仍然采用原始的HTML+js+css的開發(fā)方式,所不同則是組件包會經(jīng)過后臺轉(zhuǎn)義以及前臺解析按照規(guī)則書寫的模板字符串,并輸出到頁面中進行展示.

數(shù)據(jù)結(jié)構(gòu)

在之前的項目中,到后期才發(fā)現(xiàn)因為自實現(xiàn)的狀態(tài)管理工具過于簡單且缺乏文檔,導(dǎo)致后期接手維護人員的難以修改.正好借著項目的機會,使用與react搭配較好的 redux進行開發(fā).
上個項目采用的扁平化狀態(tài)樹結(jié)構(gòu)在一開始只是為了查找方便,在學(xué)習(xí)了redux之后,發(fā)現(xiàn)范式化的state更加符合復(fù)雜的場景,特別是在排序以及關(guān)聯(lián)查詢方面.

項目中需要實現(xiàn)組件節(jié)點樹

及與節(jié)點相關(guān)聯(lián)的對應(yīng)窗口標題的數(shù)據(jù)

設(shè)計視圖

雖然已很久不用Dreamweaver,但確實不得不承認其所見即所得制作頁面效果在以前還是很讓人驚艷的.

而本項目中就功能程度而言肯定是遠遠不及的,以H5制作工具,或者各種原型工具來說(最近在用 xiaopiu.com,表單項設(shè)計很出彩),都是采用類ps的畫布方式.

而在本項目中,因為需要考慮運營人員的使用場景,采用全畫布形式最麻煩的地方在于以制作設(shè)計圖的思維在制作網(wǎng)頁,這樣會帶來制作步驟復(fù)雜,且層級較多,頁面節(jié)點一多各種互相遮蓋難以維護.這只是操作上帶來的問題,更麻煩的地方在于難以形成規(guī)范,這里的規(guī)范是制作頁面的規(guī)范,如果只注重定位而不注重文檔流自然布局,則會在區(qū)塊劃分上定義模糊不清,對于現(xiàn)今大多數(shù)動態(tài)獲取數(shù)據(jù)模板來說,也根本沒辦法定死位置.
那么,只要搞定設(shè)計視圖中最麻煩的節(jié)點拖拽排序功能,就能完成最基礎(chǔ)的設(shè)計視圖功能.

拖拽功能

這里使用了react-dnd,API定義及數(shù)據(jù)處理與DOM分離的方式確實讓我大開眼界,內(nèi)部已使用redux的架構(gòu)進行設(shè)計,核心部分都是純函數(shù),將DOM操作分離出去,也因此更容易進行擴展,后續(xù)會專門整理源碼閱讀筆記,以供參考.

需要支持平級排序與嵌套排序,包括浮動定位.

在使用Dnd的過程中,需要給視圖中可排序以及可嵌套放置的節(jié)點都設(shè)置類型,類似于唯一標識符,當綁定的DOM節(jié)點觸發(fā)事件之后,會通過之前已包裹完成的高級組件進行傳遞狀態(tài),從而觸發(fā)自定義的事件.

經(jīng)過幾次的修改,最終確定了定義可嵌套的布局容器以及無法再次嵌套只能排序的展示模塊

比較麻煩的處理在于限制拖拽即時排序方法,當有嵌套層級時,過于靈活的直接插入在用于深層級嵌套時反而讓使用者無所適從,比如想要做一個第二層級排序操作,但由于使用了即時排序,如果還有內(nèi)嵌層級,當移動進入時會進行插入操作.當然這一點本身也是因為思慮不周,認為只要鼠標經(jīng)過容器之上,既然無法判斷用戶是否需要插入嵌套層級,那么直接做插入處理,但真實對接業(yè)務(wù)場景卻發(fā)現(xiàn)有些容器內(nèi)部因為自身內(nèi)容過長,導(dǎo)致容易誤操作,之后約束了hover事件,采用drop事件用于判斷真實嵌套意圖或排序.

對于嵌套容器而言,排序時需要根據(jù)當前拖動節(jié)點與鼠標經(jīng)過節(jié)點的實際經(jīng)過位置以及之前的排序方式作判斷,比如當經(jīng)過可排序節(jié)點50%高度則自動做排序,對于可嵌套放置節(jié)點,需要記錄移出時方位,當經(jīng)過該節(jié)點之后,再做相應(yīng)排序規(guī)則.

同時,需要定義一個畫布級容器用于滿足浮動定位需求,當展示型模塊進行拖拽操作時,可放置在該容器中用于解決浮動定位排版需求.

部分交互操作

還有一個麻煩之處在于設(shè)計視圖中需要能夠支持外部樣式表以及外部腳本,那么為了不與工具本身產(chǎn)生沖突,甚至影響到工具操作,這里的設(shè)計視圖中采用iframe作為展示層.參考react-frame-component,新建一個空白的iframe,在創(chuàng)建完成時手動重寫document,前期直接使用ReactDOM.unstable_renderSubtreeIntoContainer進行跨節(jié)點組件更新,在之后因為多次重復(fù)渲染的問題改成為ReactDOM.createPortal.

設(shè)計視圖采用iframe來實現(xiàn)的問題,還在于需要根據(jù)上下文進行重構(gòu)組件,其中畫布類容器中的拖拽放大縮小及框選對齊及同時編輯都需要根據(jù)iframe 的document重新計算.這里采用之前項目的邏輯,用react的方式進行組件重構(gòu)即可.

屬性編輯

依托于強大的狀態(tài)管理工具,我們將表單項與節(jié)點數(shù)據(jù)進行雙向綁定即可達到屬性編輯的效果,那么這里只剩下對于展示型模塊的屬性聲明.

不是IDE

其實工具本身起到的作用只是將代碼以更加通用的方式進行組合,在大部分實施及運營人員沒有辦法很快速的掌握組件化開發(fā)的情況下,也需要通過工程化的手段進行推動.至少通過工具及推出的新式組件開發(fā)規(guī)范,能夠?qū)⒅g那種低效的人工方式進行優(yōu)化升級,包括也能夠有一定的積累.更別說分離的模式更有利于自動化測試.

重新定義XML文件,用于支持展示型模塊的配置需求,這也算是一種聲明,效果如下:

同一類型模塊可以有多個展示(HTMl結(jié)構(gòu)及獨立功能),通用性配置項寫在模塊主XML中,展示包具體內(nèi)容結(jié)構(gòu)如下:

css部分會在上傳至應(yīng)用中心之后進行編譯,類css module方案增加標識符,局部實例采用模板引擎組合的方式,生成不重復(fù)的root className 進行包裝.

主體結(jié)構(gòu)部分采用html模板字符串方式,定義key-value形式的數(shù)據(jù)源,在設(shè)計視圖中根據(jù)用戶操作表單項進行數(shù)據(jù)修改,達到實時編輯效果.在內(nèi)部使用時還需開放局部的源碼編輯效果以滿足快速修改上線.

而工具內(nèi)部對應(yīng)進行節(jié)點數(shù)據(jù)存儲,最終拼裝完成一個模板頁面所需的組件節(jié)點樹.這里實際上將工具自身實現(xiàn)進行了隱藏,普通模板開發(fā)人員或許并不了解其內(nèi)部組件的實現(xiàn),但可以按照之前的經(jīng)驗進行模板片段的編寫,唯一區(qū)別則是需要增加模板字符串的認知及編寫.作為過渡方案來說,至少解決了現(xiàn)實成本問題.

表單項擴展

表單項描述中增加級聯(lián)標識符asFor與asForValue,由工具進行判斷是否顯示當前表單項,同時增加分類標識符classify,用于將過多的表單項進行組合分類展示.對與展示模塊開發(fā)者來說,只需要聲明type即可調(diào)用.后續(xù)通過擴展提供更多類型

解析翻譯

在通過拖拽及配置的方式完成設(shè)計視圖之后,只要再解析翻譯為預(yù)覽展示所需的各終端真實內(nèi)容即可.這里只需翻譯為HTML字符串即可.

終點or起點

初始的需求到這里基本已完結(jié),除了業(yè)務(wù)需求之外,我其實仍想探索出如何結(jié)合現(xiàn)實情況推動團隊的前端工程化發(fā)展,如果按照前端工程——基礎(chǔ)篇的階段總結(jié),那么我們甚至還在第一階段掙扎前行.

而在基本完成上述工具之后,我不由的思考,如果以工具作為起點,潛移默化的將高級能力植入到線上項目中去,應(yīng)當比硬推框架效果更好,同時也能夠進行積累.比如這次的頁面模板,在以前甚至連最基礎(chǔ)的資源壓縮都沒有做到,而通過新的工具統(tǒng)一進行壓縮,既沒有增加開發(fā)人員的工作量,又達到了效果.通過快捷工具的方式既減輕了使用者的開發(fā)壓力,又增強了線上項目的實際質(zhì)量,何樂而不為?更別說工具本身以及所產(chǎn)生的衍生物的價值.

架構(gòu)思考

做組合

每個能夠延伸下去的業(yè)務(wù)場景其實都很復(fù)雜,如果真按照之前的模式給每一個場景多帶帶開發(fā)工具,那么項目周期就太長了.特別是一旦工具內(nèi)部做交互性功能,比如建站工具中嵌入問卷,或者數(shù)據(jù)大屏中加入流程流轉(zhuǎn),不統(tǒng)籌兼顧根本玩不轉(zhuǎn).

為什么需要做組合?一部分原因當然是為了節(jié)省開發(fā)人力,另外一部分則是這些場景都有一定的共性:建站中的展示型模塊,自定義表單中的表單項,甚至是數(shù)據(jù)圖表以及流程節(jié)點,都能變成數(shù)據(jù)節(jié)點進行組裝.

每一種工具最終的產(chǎn)物其實都只是代碼的組合,所不同的是之前靠人編輯,現(xiàn)在用工具生成.只考慮通用的業(yè)務(wù)場景,再將其進行歸納,實際上已經(jīng)解決了大部分的線上開發(fā)效率問題.

通過分析可以看到:這些場景都需要一個能夠進行托拉拽操作的畫布,一個畫布構(gòu)成的最小單元(以下稱為節(jié)點)來進行排版,一套直觀的邏輯輔助編輯工具(這里采用流程圖)控制事件,一個可真實渲染的設(shè)計視圖(編輯狀態(tài),生成運行時所需的store),以及對應(yīng)終端平臺的翻譯器(預(yù)覽狀態(tài),解析之前生成的store并按規(guī)則進行渲染)就能做到組合.

nodeTree

控制整個應(yīng)用渲染的頁面結(jié)構(gòu)的數(shù)據(jù).定義規(guī)范基礎(chǔ)結(jié)構(gòu):

對節(jié)點樹操作的行為由框架直接提供,對拖拽行為進行封裝,并提供回調(diào)即可.

對于各個場景下所需的展示型模塊來說,只需要遵循統(tǒng)一規(guī)范,由框架進行抽象即可

節(jié)點注冊

目前看來仍然采用之前的XMl文件定義即可,對于額外的數(shù)據(jù)信息,比如問卷系統(tǒng)中需要的事件或流程圖需要的連線等都通過關(guān)聯(lián)表的形式,進行數(shù)據(jù)擴展.

事件

一部分由全局定義公共事件,比如頁面初始化以及節(jié)點銷毀,關(guān)聯(lián)狀態(tài)重置.另一部分由模塊多帶帶聲明,比如問卷中表單項條件跳轉(zhuǎn),在模塊中聲明onChange事件,由用戶通過流程圖工具綁定對應(yīng)節(jié)點.這里的觸發(fā)效果應(yīng)當由公共事件與模塊修改自身屬性事件共同擴展.當然,這里不需要做到自定義的程度,只要根據(jù)預(yù)先設(shè)置的規(guī)則進行處理即可.

能力擴展

這里的能力擴展是為了分離核心功能,當工具需要比如組件樹展示,格式刷等額外功能時,通過類似中間件形式增加工具能力,插件可使用內(nèi)部數(shù)據(jù)流進行功能擴展

同時在框架中提供預(yù)留UI渲染節(jié)點:

節(jié)點能力定義

所有節(jié)點皆采用鼠標移動至上方,顯示可拖動區(qū)域及快捷菜單的方式

總結(jié)

在這一過程中,既有產(chǎn)物,又能重新梳理組件開發(fā)規(guī)范,做到由上到下統(tǒng)一整合,避免之前的那種割裂式開發(fā)流程,這樣即使前端框架或引用的庫發(fā)生了變換,只要根據(jù)規(guī)范進行聲明即可,在做到這一步的基礎(chǔ)上,再談其它,我想應(yīng)該就會容易很多.

工具本身也是為了解放前端工程師,畢竟日復(fù)一日的業(yè)務(wù)代碼的堆積很容易消耗工作的積極性,沒有人天生想一直成為資源池的一部分.通過建立新的基礎(chǔ)研發(fā)體系,讓工程師站在不同的角度看待問題,即使是無聊的業(yè)務(wù)代碼,經(jīng)過包裝,重新聲明,附加配置項等步驟之后,也會發(fā)現(xiàn)哪里可以復(fù)用,哪里寫的有問題等之前忽略的信息.我覺得這才最有價值的地方