[[405803]]

低代碼平臺解決的問題

低代碼平臺屬于APaaS(應用平臺即服務)，其解決的是企業內部應用協調和人效成本的問題. 隨著計算機技術諸如云服務等的發展, 傳統軟件服務已無法滿足數字化浪潮的壓力, 筆者對企業迫切需要解決的問題做了如下總結:

• 企業數據孤島(應用間數據共享,互通困難)
• 企業定制化需求日益增加(不同行業賦能不同的應用場景, 千“客”千面)
• IT人才供不應求
• 溝通成本,研發成本, 研發周期吃緊
• 產品迭代和響應性遲緩

所以我們迫切需要諸如低代碼/零代碼這樣的方案, 來解決上述問題.

當然lowcode平臺很早就已經出現了, 國外的西門子(SAP), 微軟, 谷歌已經有非常成熟的方案, 國內也不在少數, 但是形成跨行業通用解決方案, 還有很長的路要走(比如如何解決國內各大平臺的小程序搭建化).

其基本流程如下:

數據源

上面介紹了低代碼的基本概念和解決的痛點, 下面我們繼續分析一下低代碼的組成和數據源設計.

低代碼基本包含如下部分:

1.用戶端編輯器

2.管理終端

• 數據源
• 頁面(應用)管理
• 模版管理
• 組件管理
• 資源庫管理(圖片, 字體, 自有sdk, 插件等)
• 角色管理(非必需)

如下圖所示:

用戶端編輯器部分主要是設計拖拽, 組件渲染相關的技術基建, 這部分筆者在這之前文章中也做過大量分享, 比如智能網格布局拖拽模式, 自然流拖拽搭建模式, 自由布局模式等. 詳細可參考源碼:

• H5-Dooring | 智能網格拖拽搭建平臺
• H5-Stream | 自然流排序搭建平臺
• V6.Dooring | 自由布局可視化搭建平臺

本文的重心在數據源設計, 接下來我們開始數據源的分析.

什么是數據源呢? 筆者的理解就是 數據的來源，是提供某種所需要數據的母體。在數據源中存儲了所有建立數據庫連接的信息, 通過提供正確的數據源名稱，我們可以找到相應的數據資產。

低代碼的產物, 有純靜態的頁面, 也有需要對接動態數據的動態頁面, 低代碼平臺的數據源主要就是為動態頁面(業務系統)設計的. 低代碼平臺使用人員可以選擇或者創建數據源, 變量, 函數, 自定義事件等來供頁面和組件實現數據對接和頁面交互, 通過這種方式可以進一步降低數據對接復雜度并提高研發效能.

對于數據源的設計, 根據實際的業務需求, 我們可以分為靜態數據源和動態數據源. 靜態數據源是用戶可以通過可視化的方式在低代碼平臺上創建的, 比如編輯數據表格等.

動態數據源是指用戶可以自定義的請求第三方的數據服務, 組件消費數據源完全是動態調用的, 類似于我們傳統開發時使用的ajax請求.

基于以上的概念, 我來帶大家介紹一下H5-Dooring的數據源實現.

數據源編輯界面:

首先Dooring的每個用戶都有獨立的數據源倉庫, 可以配置不同的數據源供組件消費, 數據源會保存在對應的用戶下, 用戶可以讓不同的頁面/組件消費數據源.如下:

1. 靜態數據源實現

靜態數據源即用戶在平臺自己創建的數據源, 我們將此類數據源存放在公共狀態中讓組件消費, 比如redux或者vuex中, 同時對其進行數據庫存儲. 具體流程如下:

從代碼層面, 我們只需要把從服務器獲取的靜態數據源, 存儲到客戶端全局狀態中, 對于用戶自己創建的數據源, 我們提供數據庫的CURD操作即可. 如下圖:

2. 動態數據源

動態數據源設計需要一套組件數據協定, 需要約定第三方接口遵循低代碼平臺數據規范來返回數據, 后者手動通過編程的模式來對應字段和組件數據的映射關系.

具體方案類似于我在可視化組件中實現的第三方數據接入的方案:

這樣, 組件既可以消費靜態數據, 也可以動態加載第三方數據, 進而實現了低代碼動態頁面的搭建.

最后

最近H5-Dooring可視化搭建平臺也在持續推迭代, 數據源已基本搭建完成, 后續還會按照更智能化的方向. 一下即是最近的更新日志:

• 優化編輯器加載性能
• iframe容器組件添加邊框等屬性
• 富文本組件添加背景色配置
• 修復真機預覽時空數據還能顯示二維碼bug
• 優化頁面高度適配問題, 添加高度適配器
• 優化組件交互時空鏈接點擊出現message bug
• 更新dooring文檔

國內lowcode平臺仍然有很長的路要走, 期待大家一起努力💪!

本文轉載自微信公眾號「 趣談前端」，可以通過以下二維碼關注。轉載本文請聯系 趣談前端公眾號。