作者 | 偏左
來源 | 阿里技術公眾號

一 中后臺前端研發(fā)復雜度背景

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

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

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

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

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

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

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

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

那么問題逐漸顯現(xiàn)，如何面對中后臺復雜場景中最深刻的兩個問題：即復雜交互、復雜邏輯。

二 復雜交互解法

1 思路

首先是使用動態(tài)標注生成交互界面，來解決復雜交互問題：

這是一個典型的后臺功能配置頁：這里面有列表有詳情，加入了很多指引。這里相當一部分交互的繁瑣編碼工作，其實是以一種簡潔高效的低代碼方式去解決的。

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

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

想法比較直接，那么真實的效果如何呢？

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

2 實踐

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

第一步，我們要找到輔助類的交互，哪些是必須要procode的業(yè)務關鍵能力，哪些是非必須的。在我們的實踐經(jīng)驗中，像這些輔助類交互都是可以抽象成組件復用的。

第二步，我們將這些組件，通過動態(tài)標注的方式，渲染到界面上。

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

當匹配這些行為時，找到組件插入或更新的位置，然后渲染出來，這個時候組件會按預設的規(guī)則動態(tài)的標注到頁面指定位置上。

比如，當用戶進入某個頁面時（行為是URL改變），我們給指定區(qū)域（可能是一個選擇器指定的），插入一張流程圖。

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

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

通過給組件配置url來完成不同的動作

這樣就完成整個易用性交互的標注和動作過程。

3 相關問題

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

第二個問題是，這些規(guī)則都太專業(yè)了，CSS選擇器、XPath，這些對于非技術同學來說使用成本非常高，而且可能因為一個很小的頁面改動就會導致配置失效。

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

4 復雜交互動作

標注的問題解決了，但是復雜的交互動作怎么做呢？這里有個例子說明一下：

試想一個場景，一個系統(tǒng)，對于新用戶、老用戶，需要有不同的引導方式

新用戶場景下，首先提示用戶，歡迎使用新手引導，2秒后，展示新手引導彈窗；

而老用戶場景下，僅提示用戶，歡迎查看常見問題，當點擊常見問題時，向機器人發(fā)問獲取知識；

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

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

三 復雜邏輯解法

接下來要面對更難的一個問題，復雜邏輯，通過策略編排生成邏輯代碼。

方案的核心目標，是將所有的交互邏輯從ProCode開發(fā)，轉為低/無代碼配置，但這個核心目標的前提并不是要用低代碼來替代procode，而是因為procode寫復雜邏輯很難，所以要使用簡單的低代碼實現(xiàn)。

點擊鏈接查看原文面向中后臺復雜場景的低代碼實踐思路，關注公眾號【阿里技術】獲取更多福利！