我们就来模拟一下一个电商网站如果用 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/cn.aspx?n=bbs/Soft_Job/M.1535961618.A.787.html