前端低代碼之路（二）-- 產品形態很重要

繼上篇，咱們講講低代碼的產品形態，爲啥這麼講，我我的認知市面上不太可能出現通用型低代碼平臺，低代碼的目的就是適應某一特定領域，來解決這一領域中開發人員不足，流程複雜，開發效率低的問題。因此必然是對某一個領域的適用性，好比營銷H5頁面的搭建，工做流的定義等。

那麼必然須要強依賴領域模型，也就是這一領域的產品形態。同時產品的設計相當重要。我將列舉幾個案例，只是討論，不分對錯。

先來看看有讚的店鋪裝修後臺，其實營銷領域中的組件也算比較全，還能適配小程序。

比較中規中矩的左中右模式

• 左側組件添加按鈕，負責添加組件
• 中間可視化預覽，兼顧刪除和排序的功能
• 右側選中組件的屬性設置，兼顧頁面設置，組件列表

本人也曾作過相似的工做，只是組件上需求量不大，該有的都有。加入了版本控制，就是歷史操做記錄。這塊在下一篇技術實現上會細講。這裏只是討論產品形態。

咱們看到這類頁面型編輯器，一類是業務無關的，相似簡單的H5生成器。我的比較喜歡maka，固然別的也不錯

另外一類就是相似有贊，阿里等電商平臺，這類產品跟平臺相關，是由於藉助電商生態，和商品系統，銷售系統等等數據進行打通的，這類系統就能夠作到不少特點組件，好比 秒殺，搜索，商品展現，店鋪信息等等。

營銷頁面生成系統優點很明顯，使用者可視化使用，無需專業技能，只須要根據一些說明文檔進行配置便可。

同時也有一些侷限：

• 因爲組件限制了靈活性，雖然使用大量模板來彌補不足。上篇說到的問題就是，幾乎不能100%的知足用戶，只能是用戶妥協，微調的可能性極低
• 加載效率的問題，因爲組件通常是一次性加載，根據配置列表的內容動態建立組件。組件的代碼仍是要加載進來，隨着組件個數增長，勢必增長代碼加載量
• 數據加載的量，舉例通常這樣的系統都會有商品模塊，每一個商品組件都是根據製做頁面的時候設置的商品動態請求商品信息，若是一個頁面，相似於活動會場頁面，就會有大量的商品組件，我的經驗30個總有的，這個時候問題就是太多的ajax請求會拖慢展現速度

通常上述問題也都有相應的策略去解決。這個須要下篇解釋。先暫時講講產品策略對於技術的影響，相似於這種比較吃展現的頁面型操做，產品的一個不適當想法就會讓前端忙的暈頭轉向。可是有些合理的產品策略仍是要響應。舉例以下：

• 展現效果需求，穩定性，不能有報錯，不能白屏。速度還得快，不能讓客戶等過久。
• 業務需求，組件的豐富，就是市面上有的咱要有，沒有的也但願有。例如，爲了有條理的展現更多商品，相似於分類的組件，爲了更好的控制頁面結構，相似於layout的需求
• 路由需求，隨着營銷類的運營能力提高，不少活動是以主題活動的形式開展，就不是一個一個單頁的宣傳了，每每是一個會場的概念，就會集合不少個單頁組成一些列的頁面搞活動，那麼就須要控制路由的能力
• 投放需求，活動頁面會有定點投放的須要，相似於某些活動只在杭州搞，杭州之外的地區不參加，頁面就要有根據地區展現的能力，還有有些活動是定點在某個渠道搞，其餘渠道不搞。
• 數據收集的須要，搞活動目的仍是要留存客戶，固然但願還有入口可讓用戶留下點信息。以便後續的變現。
• 數據分析的須要，通常來說，頁面訪問數據將來仍是要能提高之後的活動效果，用戶行爲數據分析，以便爲後續活動提供策略支持，簡單的uv，pv已經不能知足當下運營的須要了，而是要跟立體的數據，例如商品的點擊次數，用戶在頁面的留存時間，用戶在整個活動中的訪問鏈路。

以上的點也就是我我的實踐中得出的低代碼平臺在營銷類頁面搭建應該考慮的問題。不敢說每一個方向都完美解決，只是針對性的進行了優化。具體代碼思路參考下一篇。

回過頭咱們，探討下工做流領域的低代碼，經驗所致，我開發過的只有阿里巴巴內網的工做流平臺，也就是釘釘的審批模塊。還有就是醫療行業的一個問卷系統。工做流系統，從工做流的定義，到自助表單的開發都有涉足。釘釘審批是2015年開發的，如今的開發者已經把產品向前推動了一大步。

這一類的產品的一個典型特色就是要完成必定的工做，這項工做能夠由各類獨立功能的節點組成有向無環圖。通常分爲

• 開始節點，業務發起的條件
• 操做節點，具有某種業務執行能力，例如審批，具有某些權限，例如 判斷條件，操做人設置等
• 條件節點，也就是根據上一個節點的執行結果進行條件判斷，走向不一樣的分支
• 結束節點，達到某種結果，而退出工做流。

這類操做其實開發起來很是簡單，緣由是基本是後臺操做，沒有特別的流量壓力，以及展現效果要求。並且操做每每在pc端完成，代碼容錯性高。惟一的要求就是配合工做流引擎根據業務定義，把各個節點的UI和相應的功能設置完成便可。還有就是完成工做流中的工做，幾乎都是須要一些數據的，也就是當前工做流中的表單，發起人或者流程節點中的操做每每都是圍繞最初始的一個表單進行操做。好比 請假，出差，設備領用，入職，離職，這些都須要一個原始表單，承載業務數據。伴隨而來的就是自助表單系統，也有些叫問卷系統，無論叫什麼，就是一個數據輸入工具。

這類表單系統從UI上來說並不複雜，並且不少工具組件庫都提供了form表單組件。我的經驗認爲有幾個重要的點值得注意（2個項目，一個阿里巴巴工做流，一個醫療行業問卷系統）。

• 數據的驗證，既然是數據輸入，就有一些必要的驗證，例如必填項，也有一些數據分析要求的格式驗證。例如 手機號碼，表單收集者確定不但願你填一堆沒必要要的文字。通常表單組件都提供了一些基礎驗證，可是也有例外，若是用戶有些特殊的驗證，例如組合驗證，幾個表單項的結果組合就不對，這種狀況也常見
• 控制操做，在不少調查問卷中經常出現，就是表單域的控制能力，根據某一內容的值，來判斷將要填什麼內容。在醫療行業特別明顯。例如 選擇性別，男性，那麼你後面就不能填月經時間是否是，因此在醫療問卷中這只是一個很簡單的例子，一般都是性別，年齡，科室，身高，體重一塊兒來決定你是要填什麼問題。
• 自動化填充，爲啥要講這個，這個也是在作相似表單系統的時候發現的，有不少數據要填的時候，填表人老是很反感。仍是醫療行業舉例，我姓名，性別，年齡，科室，身高體重等等固定信息不是在看病或者屢次檢查住院時都填好的，還要一併填寫，不人性化。利用如今不少AI技術，表單的填充也愈來愈智能，能自動填的自動填，能選的就不要讓用戶輸入。
• 表單效果，早期的時候你們都是習慣了瀑布流的結構，隨着移動的發展，表單結構也有了變化，也有比較多的樣式體現。這一點我仍是比較欣賞material-ui的作法，雖然表單是收集數據爲主，可是能作到好看又新奇不也挺好嗎

總結：產品形態決定了前端的技術方案。因此我一直認爲一個優秀的產品真的會成就一家互聯網公司。你想毀掉一個產品就給他找個不合適的產品經理。還有就是低代碼的平臺通常產品經理作很差，因此各位前端同窗必定多想一想產品的事，只有前端能作好低代碼，不服來辯。