自服務大屏踩坑實踐

項目背景

客戶自服務項目是爲專網客戶進行網絡服務管理的Saas應用，旨在爲客戶提供便捷快速的網絡服務支撐與展現，其中的可視化大屏做爲客戶端數據直觀呈現的重要入口，產品側但願給予用戶側必定的私人自定義功能，於是本文簡單介紹了下相關實現的一些思路以及代碼實現過程當中一些比較有意義的bug回顧分析

項目方案

拿到產品需求的第一反應是low/no code實現方案，但業界較爲常見的是H5頁面的定製（ps：開源的大屏low code方案能夠看一下小夕大佬的從零開發可視化大屏製做平臺），而且其數據量不具備特殊性，基於產品的需求，這裏只借鑑了其schema統一設定的方案（ps：這個很重要，大部分low code的自定義schema其實最後是先後端同構的，這樣能夠無縫處理，但要考慮到各個技術團隊的不一樣技術側重，這種約定須要比較好的處理），對於其餘的拖拽及網格編輯器等的方案會根據後續產品相關迭代進行逐步擴展

通用schema方案

業界常見的schema方案是將用戶配置與自身配置進行分離，也就是對是否暴露給用戶進行區分，這裏選擇將暴露給用戶的schema定義爲:

{
   requestParams: {

   },
   figureParams: [

   ]
}

這裏的requresParams主要是向後端發送請求拿到對應數據的內容，而figureParams則是用戶自定義的一些配置信息，其中包含了圖形化的一些展現信息

響應式函數編程

可視化大屏每每和大數據分析與統計相關聯，對於數據流的處理，使用函數式編程將數據處理進行轉換，能夠更好的進行響應式編程方案，這裏參考了一些響應式RxJS的設計思想及函數式編程的鏈式處理、effect、pure Function等理念，對於後續大數據的處理也能夠更好的和Flink等相結合，對於想了解RxJS與Flink相關擴展的同窗能夠參考阿里同窗的這篇文章從 RxJS 到 Flink：如何處理數據流？

export const handleKpiGroupId = function(staticTypes) {
  const arr = staticTypes.map(staticType => staticType.split('-')[0]);
  return Array.from(new Set(arr));
}

export const handleKpiNameEns = function(staticTypes) {
  const arr = staticTypes.map(staticType => staticType.split('-')[1]);
  return Array.from(new Set(arr));
}

根據業務須要封裝一些map及filter處理，後續會依據數據流進行相關的發佈訂閱的響應式處理

踩坑案例

從數組中刪除位置數組中的元素

[bug描述] 在客戶指標圖表穿梭框組件中對已選擇圖形進行取消選擇操做，這裏是經過一個checked拿到對應左側push的棧結構數據的位置，在刪除過程當中使用了「佔位符」進行splice替換，致使圖形配置信息遺漏到大屏展現頁面

[bug分析] 使用splice操做進行佔位後再進行佔位符過濾操做，用戶快速點擊提交致使子組件向父組件emit數據未能同步到變已做出提交，致使髒數據遺漏到大屏展現頁面

[解決方案] 直接使用filter操做進行處理，避免splice的操做污染，須要注意filter會返回新數組，對原數組不作處理，於是vue監聽時須要對數組進行從新的地址修改

複雜數據類型地址引用問題

[bug描述] 穿梭組件中對於向父組件派發的數據經過一個stack棧存儲，而該棧中存儲了echarts的options等複雜數據類型，結果致使了數據共享問題

[bug分析] js中負載數據類型，如：對象、數組是存放在堆內存中的，在棧內存中存儲的僅僅是一個地址引用

[解決方案] 使用深克隆進行數據備份，從而實現數據的隔離

父組件異步數據經過props傳遞問題

[bug描述] 父組件異步請求獲取數據後傳遞給子組件時，子組件拿到的數據沒法當即在頁面上實時渲染

[bug分析] 這裏出現了兩次，一次是父組件給子組件傳遞數據沒有當即監聽到，而頁面須要當即渲染致使的bug，此時對傳遞的props進行了監聽處理；另外一次是父組件中和子組件中都調用了一個接口，只是需求不一樣，我但願可以減小請求次數，結果致使了父組件傳遞的數據並未同步傳遞給子組件，props會受到上一次值的影響

[解決方案] vue的數據監聽並不是同步渲染到dom上，這裏會出現一個tick的延時，若是須要父組件中數據實時傳遞給子組件能夠考慮在子組件中監聽，以及使用$nextTick等

Object.keys返回數據排序問題

[bug描述] 大屏展現橫座標是時間維度，這裏會從服務端拿到時間粒度的數據，而存儲的key值爲時間，於是須要對數據進行過濾整合處理，使用Object.keys對時間粒度返回的過程當中出現了時間粒度的亂序

[bug分析] js中的Object.keys會對不一樣狀況進行不一樣的策略排序，更深層次的探索能夠看騰訊IMWeb同窗分享的關於Object.keys排序的深層探究關於 JavaScript Object.keys() 排序問題的探索
[解決方案] 使用sort對排序規則進行肯定

總結

大屏可視化定製看似簡單，但在實際開發過程當中仍是會出現不少的問題，尤爲是涉及到了數據的分析與處理，整個定製的核心在於schema的肯定，需求的不一樣也會致使schema的變更，於是對於大數據相關的開發與展現可能會是可視化方向的另外一個擴展方面，這裏能夠着重看一下響應式函數編程與大數據相關的結合，可能能碰撞出一些火花；另外就是對於bug進行不一樣層次的深度剖析，在每次開發功能過程當中產生的bug，總有那麼幾個值得回味反補的閃光點存在，就像「錯題本」同樣，總會出現那麼一兩個值得咱們反覆玩味的bug，從而讓咱們對基本原理能有一個更深層次的理解，人都對不常見的問題印象深入，真正踩過幾回坑，才能印象深入，所謂「痛則通，不痛則不通」，每一次的bug流的淚都是當初腦子進的水，但願你們能在不斷實踐的過程當中反補本身技術基礎的不足，從而把本身的技術打造的更爲精湛與過硬，高手過招總在細節中體現功夫的深淺，共勉！！！

參考

• 從零開發可視化大屏製做平臺
• 從 RxJS 到 Flink：如何處理數據流？
• 關於 JavaScript Object.keys() 排序問題的探索
• vue父組件異步獲取數據傳給子組件