企業級自定義表單引擎解決方案（十五）–前端開源說明
- 一直做後端開發，前端還真不是強項，半桶水的樣子，好在現在前端框架和組件層出不窮，基本上勉強可以上路。
- 自定義表單對前端要求非常高，技術上的難度不亞於後端，而且要考慮擴展性、性能，對於擴展性的設計要求非常高，比如你做一個按鈕點擊事件，就要考慮文本框、下拉框的值改變事件，再比如介面上的參數來源，可以從其他介面傳入，也要考慮從菜單傳入或者其他規則傳入，總之就是要窮舉所有你能夠想到的，那麼就註定了研發自定義表單是不斷完善的一個過程，且對組件化設計要求非常高。
- vue和angular都有用過，最開始嘗試用angular來做，但做技術調研的時候，發現他的動態組件，動態屬性綁定這些很死，很難隨心所欲的動態載入渲染組件，動態應用一些屬性，於是不得不放棄，轉向用vue來實現，選擇的前端開發框架是ant vue.
- 對於性能這塊來說，做自定義表單，不能影響前端性能，不然基本沒什麼意義，至少和傳統碼程式碼的方式比不能差太多，對於自定義表單來說，渲染過程比較簡單，當用戶打開介面時，找到介面的表單定義資訊(Json數據，且是最新的數據)，根據介面資訊動態渲染介面，動態渲染是vue做的事情，這個改變不了，那麼找到最新的表單定義資訊就是比較影響性能的地方了。對於這塊來說，後端和前端都採用快取的方式實現，後端快取到記憶體中，前端把表單定義資訊存儲到indexdb中，絕大多數是從本地數據裡面取的，只有在第一次獲取表單定義數據和數據變更之後，才會從後端拿取數據，再存儲到indexdb中，這樣在生產環境，這塊的性能損失基本就比較小了。
- 前端開始採用的是單點登錄，但用戶部門等基礎數據、消息通知、Job、登錄等都是調用遠程伺服器上的服務，而自定義表單調用的本地服務，因此會有一些問題，所以把單點登錄去掉了，改為密碼模式登錄，拿到Token去請求介面，Token過期設置的是24小時，暫時還沒有做Token刷新。
- 前端除自定義表單外，其他都是調用的遠程伺服器介面，自定義表單介面調用的是本地啟動的後端項目介面，自定義表單前後端程式碼都可以本地調試。
使用說明
後端
- git切換到dev版本
- 後端VS打開項目文件 > 03_form\CK.Sprite.Form\CK.Sprite.Form.sln
- 設置CK.Framework.HttpApi.Host為啟動項目，直接運行項目，資料庫連接資訊已經在配置文件appsettings.json裡面，可用其他資料庫連接工具直接打開（外網公共的資料庫資源，請不要亂操作資料庫，定時還原）
前端
- 運行前，確定VUE_APP_Form_URL變數是否與後端啟動的埠一致
- yarn install
- yarn serve 或者 npm run serve（如果第一次運行報錯，退出之後再次運行即可）
- 如果不需要運行後端，請將VUE_APP_Form_URL參數改為//47.108.141.193:8031 站點由之前的SSO改為密碼Token認證，後端項目認證直接接入47.108.141.193:8031認證伺服器 認證服務、基礎數據、流程引擎、消息中心、Job管理等都是調用的47.108.141.193部署的站點，自定義表單部分運行的程式碼直接調用本地啟動項目。
- 自定義表單將所有表單定義資訊都存儲到本地快取的，部署的開源站點和本地的站點都是連接的同一個資料庫，但採用了Redis的發布訂閱功能，只要在任何地方改變了表單定義資訊，其他地方都會自動刷新本地站點的記憶體中的表單定義資訊。
運行演示
wike文檔地址：//gitee.com/kuangqifu/sprite/wikis/pages
後端開源地址：//gitee.com/kuangqifu/sprite
前端開源地址：//gitee.com/kuangqifu/spritefronts
體驗地址：//47.108.141.193:8031 （首次載入可能有點慢，用的阿里雲最差的伺服器）
自定義表單文章地址：//www.cnblogs.com/spritekuang/
流程引擎文章地址：//www.cnblogs.com/spritekuang/category/834975.html （採用WWF開發，已過時，已改用Elsa實現，//www.cnblogs.com/spritekuang/p/14970992.html ）
