我們就來模擬一下一個電商網站如果用 global.js
這樣的方式去處理 state 可能會發生什麼事情
一開始，你的 global.js 可能會只有一點點資料，
只有一些 configuration 之類的資料，於是他可能只是一個單純的 object
頁面內所需的資料就用單純的 setState 方式去處理，
隨著時間過去，網站越來越大，功能越來越複雜，
你發現從父 componet 用 props 傳遞 state 的方式漸漸行不通，也讓你快起笑了
像是會員的資料，購物車的內容，訂單的狀況等等的，
於是你決定將這些資料提升到 global.js 的層級
一開始，你只是單純的對 global.js 做變更
(ex: global.member = { id: 1, name: nose })
一開始你覺得一切都很美好，直到有一天你在修 bug 的時候發現
有個工程師為了快速解票，在需要更改 state 的地方都直接蝦七八亂改一通
明明 global 裡面有許多重要的資料，但他卻天真的寫了
global = { member: { id: 1, name: nose } }
global 只剩下 member 的資料了，其他重要的資料都給毀了，
於是你決定重新 refactor
把 global.js 改寫成 singleton 的 class,
並寫了 setter 或是對應的 function 來修改 global 裡的 state
更嚴格的要求團隊的成員必須透過這些 function 來修改 state
現在感覺一切更美好了一點
不過隨著時間再次的過去，你發現 global.js 變得越來越肥大
好幾千行的 js 讓你難以維護，
於是你決定再次的 refactor,
將 global.js 裡同類型的 state 拆分出 member, product, shoppingCart 等等的子 js
於是你感覺一次又再次的美好了，
也發現這東西長得越來越像 flux 惹
大 guy 4 醬的感覺吧
Redux 的確是會增加一些複雜度，寫起 code 來可能會讓你覺得麻煩又綁手綁腳的
但當你仔細回頭來看時，或許你也會發現這些麻煩的東西其實是在幫你自己的忙
就像是明明是弱型別的 js , 為何有許多人想硬把他搞成強型別
寫起來更加的麻煩，甚至還要編譯
不過說到底還是要看團隊的組成以及專案的性質
來決定要怎麼樣 maintain 前端 SPA 的 state
然後因為你文章有提到 Container 的部分就特別再多說一下，
拆分出 Presentation component 其實差別蠻大的，
因為如果你的 component 要是牽扯到太多邏輯，做了太多 side effect 的事情
你的 component 就越難 reuse
想當年自己寫 Alt 瞎七八亂寫，想 reuse 個小小的 component 都搞得自己頭很大
估時間時信誓旦旦的跟 PM 說這個就搬前面的東西過來用就好，
結果最後還是決定重寫一個比較快 XDD