我們就來模擬一下一個電商網站如果用 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 -- 能讓男人成為男人的，不是武器或女人，也不是魔法，更不是任何力量。 只能由他自己。 恬娜(地海孤雛) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.13.192.210 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1535961618.A.787.html