Qualitis作爲大數據生態中重要的一環，由於歷史維護等原因，在功能和體驗上有比較多的優化空間，改版迫在眉睫。
功能要點
Qualitis主要由工作概覽、我的項目、指標管理、規則管理、數據源管理、任務查詢、系統設置、引擎設置八大功能組成，在邏輯上有以下關鍵點：
1、複製規則組件僅在工作流項目中有效；
2、執行任務是全局組件並需要支持差異化調用；
3、普通項目和工作流項目支持的規則類型相同，包含單表校驗、跨表校驗、文件校驗、跨庫校驗、單指標校驗、多指標校驗；
4、每種規則由基礎信息、數據源、校驗方式、執行參數四部分組成，其中數據源和校驗方式的差異較大；
5、單表規則需要支持多種校驗模板，並根據校驗模板差異化數據源模塊的展示；
6、工作流項目僅在被嵌入DSS的時候可以修改；
7、列表頁的數據很多，並且點擊可以跳轉到詳情頁，再從詳情頁返回的時候需要根據進入詳情頁前的參數（頁面、搜索參數）加載列表數據。
項目現狀
現有項目使用的是vue2（該技術棧在應對大型項目時，會面臨公共邏輯抽離組合方法有限的問題，比如有A、B兩個mixins，A、B有部分邏輯相同，並且相互有數據依賴，就需要想辦法保證A、B兩個mixins按預期時許執行），主要存在以下問題：
1、項目文件
文件放置凌亂，沒有體現系統功能層級。
2、缺少註釋
功能邏輯缺少文檔以及註釋只能通過代碼閱讀、測試環境debug、詢問後臺確認邏輯的設計原理，比如FPS和上游表功能不能同時開啓、是不是每個規則選擇MYSQL的時候都需要顯示連接輸入框、單表規則在選擇不同校驗模板的時候數據源中的字段是怎麼動態差異化展示的。
3、功能複用
功能複用嚴重不足，在規則項目編輯功能中尤爲明顯，每種規則對應的頁面代碼行數都達到了1000行以上，閱讀非常消耗精力和時間。
4、邏輯未完成
存在未完成的功能代碼，以下文件的測試環境數據竟然在生產上一直跑。
5、界面不合理
操作邏輯不清晰，樣式兼容性差，不同部分結構產生重疊。
由於功能的交互經過重新設計，某些功能在原有功能上進行了優化，加上上面說幾個問題，讓改版的工作在最開始設計邏輯和review的時候非常消耗精力。
改造目的
1、重新設計界面交互，重新梳理代碼層面的功能組合，提升用戶操作效率和體驗，並實現和優化原有的全部功能；
2、提升項目代碼的維護性、閱讀性、拓展性，解決之前vue2遺留的比如mixins的問題。
改造關鍵點
1、不同類型規則的功能設計
在規則功能模塊劃分方面力求做到，該複用的複用，該拆分的拆分。
儘管每個規則的數據源模塊都不同，但是相同的操作，比如選擇FPS需要創建數據表的操作，也單獨抽離成了組件。
體現到代碼目錄則是如下圖，該獨自管理的放在對應的空間內，公共部分則放在儘量靠近的地方，讓目錄組織更加明朗。
2、規則詳情輕量化設計
在詳情頁中，屬於同一個組的所有類型的規則都會放在一起，簡單說同一個組可能會有幾十個規則，如果每個規則都是for循環渲染一遍，那整個詳情頁渲染的DOM結構無疑是巨大的，可能會出現卡頓的情況。
每次用戶進入詳情頁面，不管這個組下面有多少個規則，都只能一個個看，所以在tab切換的時候，使用v-if控制不同規則的展示，這樣做詳情頁面頂多渲染一個類型的規則的詳情，DOM結構數量呈量級減少，核心代碼如下：
<div v-if="rules.length > 0" class="wd-content-body"><!-- 單表對比 --><SingleTableCheck v-if="currentRuleType === '1-1'"/><!-- 跨表對比 --><CrossTableCheck v-else-if="currentRuleType === '3-1'"/><!-- 跨庫對比 --><CrossDbCheck v-else-if="currentRuleType === '3-2'"/><!-- 單指標 --><CustomCheck v-else-if="currentRuleType === '2-1'"/><!-- 多指標 --><SqlVerification v-else-if="currentRuleType === '2-2'"/><!-- 文件校驗 --><FileCheck v-else-if="currentRuleType === '4-1'"/></div>
核心邏輯是如果當前組存在規則，根據當前tab選定的規則設置currentRuleType字段的值，決定渲染具體類型的規則頁面。
這個邏輯沒有考慮到，當這個組下存在多個同類型規則時，預期是這個類型規則的組件可以在tab切換的時候多次渲染呈現不同的數據。但實際情況是，在vue中，如果一個組件已經成功渲染，再次使用這個組件的時候則默認不會重新執行初始化的操作，這就導致用戶在同類型規則之間相互切換到時候，看到的始終是第一個規則的數據。
根據vue設計的邏輯，爲了達到使用相同組件也可以重新初始化的邏輯，必須在組件引入的地方動態改變組件對應的key值，當key發生變化時，組件則重新渲染。
在規則詳情頁中，由於每個規則的id都不同，自然就可以用作每個組件唯一的key，至此同一個組件和不同組件的渲染問題都達到了預期效果。
<div v-if="rules.length > 0" class="wd-content-body"><!-- 單表對比 --><SingleTableCheck v-if="currentRuleType === '1-1'" :key="currentRule.rule_id + '1'" /><!-- 跨表對比 --><CrossTableCheck v-else-if="currentRuleType === '3-1'" :key="currentRule.rule_id + '2'" /><!-- 跨庫對比 --><CrossDbCheck v-else-if="currentRuleType === '3-2'" :key="currentRule.rule_id + '3'" /><!-- 單指標 --><CustomCheck v-else-if="currentRuleType === '2-1'" :key="currentRule.rule_id + '4'" /><!-- 多指標 --><SqlVerification v-else-if="currentRuleType === '2-2'" :key="currentRule.rule_id + '5'" /><!-- 文件校驗 --><FileCheck v-else-if="currentRuleType === '4-1'" :key="currentRule.rule_id + '6'" /></div>
3、編輯規則取消時回填原有數據
用戶在規則詳情頁點擊編輯，編輯一些數據之後點擊取消，需要把修改的數據復原，這種場景通常有兩種做法：
A. 進入編輯狀態時，使用內存數據保存當前組件的所有數據（組件快照），在點擊取消時，將緩存的數據重新入組件；
B.進入編輯狀態時不做任何操作，點擊取消時重新執行組件的初始化函數。
方案A在重新數據時是毫秒級別操作，延時低，坑在於緩存的數據是否完整，方案B可以準確重新渲染最新的數據，重新初始化如果接口數據沒有緩存的話還需要考慮網絡請求消耗的時間，因此相對方案A延時沒有過多優勢，但是最簡單有效。由於開發時間緊張，目前採用的是方案B，實際操作數據覆蓋的延遲比預想中的要好。
4、組件的數據傳遞
在上訴第1點中我們對組件進行了抽離，在規範維護的同時，也要面臨組件嵌套層級的問題，加上組件可能會相同的數據。比如在單表規則的數據源組件，已經嵌套在了第三層，需要使用到ruleId、集羣列表、代理用戶列表、規則類型等公共數據，其中集羣列表、代理用戶列表是所有規則通用的數據，如果這些數據都只通過props傳遞，那整個數據鏈路會非常複雜。
理論上這些公共數據應該由他們的上層組件“詳情頁”進行渲染，他們統一去詳情頁拿數據，這樣能節省很多重複請求。
在vue3中提供了provide和inject的數據注入方式，因此可以簡單實現數據的傳遞。
// 父組件provide('key', value);// 自組件const injectData = inject('key');
當然，這個場景也可以使用vuex實現，不過規則場景中的數據共享只侷限於本模塊，而且公共數據只需要做到單向傳遞，所以也沒有使用vuex。
5、組件的拓展性
系統中有多個組件基本功能相同，但需要同時具備很多差異化的使用模式，比如執行參數模塊，需要支持詳情頁編輯模式、詳情頁預覽模式、列表頁modal編輯模式、列表頁和詳情頁的選擇以及動態編輯模式、單頁面維護模式，另在在每個模式下，整個模塊對應的數據字段也不相同。
因此我們在實現該組件基礎編輯和預覽功能之後，向外界暴露了info、mode、manual三個關鍵屬性
// ExecutionParams.vue/*** mode 可選枚舉 preview、edit* manual 決定基礎數據的加載方式，一旦設置爲true，公共數據比如集羣列表等則需要自主獲取，主要爲了解決某些使用這個組件的地方缺少ganging數據的問題* info 綁定外部組件需要修改的字段，點擊確定時通過update事件將數據回吐**/const props = defineProps({mode: {type: String,default: 'preivew',},manual: {type: Boolean,default: false,},info: {type: Object,default: {},},});
到這一步，該組件可以支持詳情頁編輯模式、詳情頁預覽模式、modal編輯模式。
爲了滿足抽屜方式和單頁模式的拓展使用，在此基礎上，新建了template組件。
// template.vue<template><!-- 新增 --><ExecutionParams v-model:info="data" mode="edit" /><!-- 列表和編輯><div v-for="d in list" :key="d.id"><ExecutionParams v-model:info="d" :mode="d.edit" /></div></tempalte>
另外，選擇的模式只能在抽屜展示的時候，因此在template組件增加了enableSelect以及@select回調，當enableSelect=true開啓選擇模式，並通過@select綁定的函數完成具體的業務操作，即滿足單頁面編輯模式和抽屜編輯模式。
<template :enableSelect="true" @select="confirm" />執行參數作爲一個基礎組件，衍生另一個組件，滿足了4種使用場景，最終核心的修改也只聚焦在這個基礎組件，提供拓展性的同時，降低了代碼維護的難度。
改造總結
新版本項目針對之前的問題和不足，很有針對性的提供瞭解決方案，以上只是舉例了幾個核心點，還有非常多的細節，因爲篇幅問題不在一一描述，後面還會持續進行優化
如何成爲社區貢獻者
1 ► 官方文檔貢獻。發現文檔的不足、優化文檔，持續更新文檔等方式參與社區貢獻。通過文檔貢獻，讓開發者熟悉如何提交PR和真正參與到社區的建設。參考攻略：保姆級教程：如何成爲Apache Linkis文檔貢獻者
2 ► 代碼貢獻。我們梳理了社區中簡單並且容易入門的的任務，非常適合新人做代碼貢獻。請查閱新手任務列表：https://github.com/apache/incubator-linkis/issues/1161
3 ► 內容貢獻：發佈WeDataSphere開源組件相關的內容，包括但不限於安裝部署教程、使用經驗、案例實踐等，形式不限，請投稿給小助手。例如：
4 ► 社區答疑：積極在社區中進行答疑、分享技術、幫助開發者解決問題等；
5 ► 其他：積極參與社區活動、成爲社區志願者、幫助社區宣傳、爲社區發展提供有效建議等；
本文分享自微信公衆號 - WeDataSphere（gh_273e85fce73b）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。