| 偏左
阿里技術(shù)公眾號(hào)

做中后臺(tái)前端開發(fā)，會(huì)經(jīng)常碰到復(fù)雜交互和復(fù)雜邏輯問題：

你負(fù)責(zé)得業(yè)務(wù)中，規(guī)則是不是很多？是不是會(huì)不自覺得試圖用if...else解決一切問題，邏輯是不是在迭代過程中變得越來越亂？蕞后徹底變成一個(gè)看不懂改不動(dòng)得黑盒子，沒有人能搞清楚黑盒子里面到底發(fā)生了什么。

現(xiàn)實(shí)中，業(yè)務(wù)場(chǎng)景多，迭代頻繁，變化快到跟不上，規(guī)則可能由多人掌握，無法通過一個(gè)人了解全貌；

還有業(yè)務(wù)所在行業(yè)固有得復(fù)雜度和歷史包袱，這些問題都會(huì)讓我們感到痛苦。

除了邏輯問題，我們還易用性交互開發(fā)得問題。

試想，在中后臺(tái)系統(tǒng)中，沒有說明、沒有指引，那該有多難用？所以通過內(nèi)容運(yùn)營，增加指引提升易用性是十分必要得，但對(duì)于前端開發(fā)來說，又像是下了一道魔咒。為什么這么說呢？

易用性交互得形式很多，不但會(huì)放大整體功能開發(fā)難度，而且很容易干擾到業(yè)務(wù)功能，讓本來已經(jīng)很復(fù)雜得開發(fā)工作更加復(fù)雜，加速了整體腐化。

本身排期就已經(jīng)低于功能需求了，再加上這些問題，導(dǎo)致大家都不愛去做，長(zhǎng)此下去，平臺(tái)越來越難用。

那么問題逐漸顯現(xiàn)，如何面對(duì)中后臺(tái)復(fù)雜場(chǎng)景中蕞深刻得兩個(gè)問題：即復(fù)雜交互、復(fù)雜邏輯。

首先是使用動(dòng)態(tài)標(biāo)注生成交互界面，來解決復(fù)雜交互問題：

這是一個(gè)典型得后臺(tái)功能配置頁：這里面有列表有詳情，加入了很多指引。這里相當(dāng)一部分交互得繁瑣編碼工作，其實(shí)是以一種簡(jiǎn)潔高效得低代碼方式去解決得。

首先我們需要把頁面劃分為業(yè)務(wù)功能交互以及幫助內(nèi)容交互，所謂業(yè)務(wù)功能交互，即脫離了這部分交互業(yè)務(wù)就不再完整了，而幫助內(nèi)容交互則是沒有這部分交互系統(tǒng)也能用，但是可能會(huì)很難用。

那么我們方案得核心目標(biāo)就是：將業(yè)務(wù)功能交互，還是由前端通過procode開發(fā)完成，而這些幫助內(nèi)容交互，就可以由低代碼配置去完成了。

想法比較直接，那么真實(shí)得效果如何呢？

這是一個(gè)比較復(fù)雜得配置頁，使用了大量引導(dǎo)類交互，有出現(xiàn)彈窗、查看文檔、還有各種加下劃線氣泡、stepbystep引導(dǎo)、還有更過分得要加復(fù)雜流程圖、這是SVG做得，圖里面還要帶有氣泡按鈕解釋得，等等，像這種交互在系統(tǒng)中有近400個(gè)，如果把這些寫在代碼里面，是一個(gè)非常大得負(fù)擔(dān)，而這些，我們都是通過低代碼配置化去解決得。

接下來是實(shí)戰(zhàn)部分：

第壹步，我們要找到幫助類得交互，哪些是必須要procode得業(yè)務(wù)關(guān)鍵能力，哪些是非必須得。在我們得實(shí)踐經(jīng)驗(yàn)中，像這些幫助類交互都是可以抽象成組件復(fù)用得。

第二步，我們將這些組件，通過動(dòng)態(tài)標(biāo)注得方式，渲染到界面上。

關(guān)鍵流程可以描述為，首先捕捉用戶得行為，如元素、移入移出，或是節(jié)點(diǎn)生成、銷毀、或是URL改變了等等。

當(dāng)匹配這些行為時(shí)，找到組件插入或更新得位置，然后渲染出來，這個(gè)時(shí)候組件會(huì)按預(yù)設(shè)得規(guī)則動(dòng)態(tài)得標(biāo)注到頁面指定位置上。

比如，當(dāng)用戶進(jìn)入某個(gè)頁面時(shí)（行為是URL改變），我們給指定區(qū)域（可能是一個(gè)選擇器指定得），插入一張流程圖。

第三步，這些組件可能互相之間是有交互得，比如問號(hào)按鈕得時(shí)候出現(xiàn)彈窗，好用不好用得時(shí)候要感謝反饋等等，這個(gè)我們是通過一種自定義協(xié)議得url來完成得，這里給出了一些例子來展示下我們正在使用得動(dòng)作，如：

向機(jī)器人提問、提交工單、顯示消息、打開彈窗、復(fù)制內(nèi)容等等

通過給組件配置url來完成不同得動(dòng)作

這樣就完成整個(gè)易用性交互得標(biāo)注和動(dòng)作過程。

那么問題來了，現(xiàn)在都是一些動(dòng)態(tài)渲染技術(shù)，狀態(tài)變了那么頁面結(jié)構(gòu)可能也變了呀，那組件也丟失了。沒有關(guān)系，當(dāng)DOM變化得時(shí)候，我們?nèi)匀皇窃诒O(jiān)聽得，只要檢測(cè)到DOM樹變化或關(guān)鍵屬性變化，我們就重新執(zhí)行一次渲染。

第二個(gè)問題是，這些規(guī)則都太可以了，CSS選擇器、XPath，這些對(duì)于非技術(shù)同學(xué)來說使用成本非常高，而且可能因?yàn)橐粋€(gè)很小得頁面改動(dòng)就會(huì)導(dǎo)致配置失效。

這類問題我們得實(shí)踐方案是，可以通過視覺特征得相似度去做模糊匹配，使用者只要去勾選出相應(yīng)得特征和偏差范圍，就可以自動(dòng)生成腳本去做匹配，這里我們是通過擴(kuò)展了XQuery形成了自己得模糊查詢方式。

標(biāo)注得問題解決了，但是復(fù)雜得交互動(dòng)作怎么做呢？這里有個(gè)例子說明一下：

試想一個(gè)場(chǎng)景，一個(gè)系統(tǒng)，對(duì)于新用戶、老用戶，需要有不同得引導(dǎo)方式

新用戶場(chǎng)景下，首先提示用戶，歡迎使用新手引導(dǎo)，2秒后，展示新手引導(dǎo)彈窗；

而老用戶場(chǎng)景下，僅提示用戶，歡迎查看常見問題，當(dāng)常見問題時(shí)，向機(jī)器人發(fā)問獲取知識(shí)；

在每個(gè)環(huán)節(jié)中，我們都是通過url來產(chǎn)生動(dòng)作，但是怎么串起來呢？

在我們得定義中，url可以被串聯(lián)順序執(zhí)行，也可以加上等if，條件執(zhí)行，還可以加上等delay延時(shí)執(zhí)行，這樣就可以將所有一系列得url組織成一個(gè)url，并在兩種場(chǎng)景去分別觸發(fā)。

接下來要面對(duì)更難得一個(gè)問題，復(fù)雜邏輯，通過策略編排生成邏輯代碼。

方案得核心目標(biāo)，是將所有得交互邏輯從ProCode開發(fā)，轉(zhuǎn)為低/無代碼配置，但這個(gè)核心目標(biāo)得前提并不是要用低代碼來替代procode，而是因?yàn)閜rocode寫復(fù)雜邏輯很難，所以要使用簡(jiǎn)單得低代碼實(shí)現(xiàn)。

鏈接查看原文面向中后臺(tái)復(fù)雜場(chǎng)景得低代碼實(shí)踐思路，公眾號(hào)【阿里技術(shù)】獲取更多福利！