現在的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。
方案三在某些場景下，也能更簡單解決我們的問題，某些表格中確實也有使用重新整理按鈕的場景。最近在使用企業微信中發現，收藏頁面在每次開啟會請求資料，如果這時再新增一個收藏，收藏列表不會重新整理，而需要關閉收藏再開啟，這時就能看到最新增加的那條收藏。這種體驗不好嗎？可能不夠優雅，但使用者第一次使用時，應該也是知道關閉再開啟這個邏輯的，更重要的是我們開啟收藏一般是去查詢以前的一些東西，而很少立馬檢視剛才的那個收藏。考慮業務場景，考慮使用者的使用習慣，能更好的幫助我們開發出簡單易用穩定的產品。