項目開發中對前端數據管理的理解

如今的SPA開發中，提到數據（狀態）管理不得不提Redux和Vuex，它們都是基於Flux思想的前端狀態管理解決方案。但本文的重點不是介紹Redux或Vuex的技術細節，而是基於真實的業務場景談談在不一樣的場景下該如何管理數據。

上圖是一個簡化後的頁面，整個頁面是一個父組件，它包含3個子組件，子組件1是一個按鈕，子組件2是一個數據展現Bar，組件3是一個tab，子組件3中每一個tab的內容又是一個子組件（相對於頁面是孫組件）。關係以下圖所示。

數據：
子組件1是一個觸發打開表單填寫Dialog的按鈕，沒有數據
子組件2包含綁定客戶數
子組件3是一個tab組件，負責tab展現和切換，沒有數據
孫組件包含要展現的具體列表數據

事件和數據之間的關係：
點擊子組件1手動綁定客戶按鈕進行增長一個新客戶的操做後，子組件2的客戶數會+1，孫組件綁定客戶Table中的數據會增長一條；
點擊子組件1手動綁定客戶按鈕進行增長一個失效客戶的操做後，子組件2的客戶數會+1，孫組件綁定客戶Table中的數據會增長一條，孫組件失效客戶Table中的數據會減小一條；
點擊孫組件中解綁按鈕後，孫組件綁定客戶Table中的數據會減小一條，失效客戶Table中的數據會增長一條，子組件2中的客戶數會-1；

簡單看下組件之間的數據關係：
子組件2的數據受到子組件1和孫組件中的事件影響；
孫組件的數據受到子組件1和自身的事件影響；

這個頁面的數據管理具備必定的複雜性，不一樣層級的組件的數據存在互相影響。這裏咱們該如何管理數據呢？

方案一
把這個頁面的全部數據交給Redux/Vuex管理
優勢：全部組件從Redux/Vuex中拿數據，全部組件的事件觸發Redux/Vuex中的數據更新，不用關心組件的事件會觸發其餘哪些組件的數據更新

方案二
父組件管理全部數據（單向數據流思想），經過屬性將數據層層往下傳，子組件或孫組件經過事件觸發父組件中的數據更新
優勢：簡單，無需引入Redux/Vuex庫
缺點：組件層級比較深時，數據傳遞會比較繁瑣（這裏react和vue都有各自簡單處理方法）

方案三
從產品的維度考慮，咱們能夠在某些地方新增一個刷新按鈕，部分層級比較深或者不必立馬刷新的數據（好比綁定客戶列表中進行解綁操做，失效客戶列表這時並不可見，也能夠不立馬刷新數據，等用戶切換tab時再去請求數據或者讓用戶手動刷新一下列表）
優勢：不用考慮數據之間的影響
缺點：用戶體驗不夠好

這裏咱們從一個真實的業務場景看到數據之間存在相互影響關係，使用Redux/Vuex不是爲了用而用，在某些場景確實能解決咱們的問題，這時應該去使用它。有些簡單的父子數據共享，爲了減小複雜度，也能夠不使用Redux/Vuex。

方案三在某些場景下，也能更簡單解決咱們的問題，某些表格中確實也有使用刷新按鈕的場景。最近在使用企業微信中發現，收藏頁面在每次打開會請求數據，若是這時再新增一個收藏，收藏列表不會刷新，而須要關閉收藏再打開，這時就能看到最新增長的那條收藏。這種體驗很差嗎？可能不夠優雅，但用戶第一次使用時，應該也是知道關閉再打開這個邏輯的，更重要的是咱們打開收藏通常是去查找之前的一些東西，而不多立馬查看剛纔的那個收藏。考慮業務場景，考慮用戶的使用習慣，能更好的幫助咱們開發出簡單易用穩定的產品。