我们就来模拟一下一个电商网站如果用 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