为啥需要状态管理？因为框架们往往需要单例的“仓库”来共享数据，这是最本质的。（数据不可变/历史版本回溯不是重点，只是附加值；单向数据流是在最初目的之下的设计实现而已，所以也不是本质）
可是angular有一大堆默认就是单例的服务，是service，而且天然分模块。所以数据可以放service中不违和，组件通信也能直接借助被设置为单例的service，也算分而治之。angular本身的zone配合脏检测机制，使得所有的数据都是自动响应更新。不需要像react去调api去通知视图更新，也不需要像vuex那样还要借用vue实例来获得响应能力。
为啥vue很少provide/inject呢，实际上连官网也不推荐，但实际上provide/inject并没有什么不好。人家不推荐，其实是怕你乱用，别到时候用得不舒服，又来口诛笔伐，人家真的很怕这个。react也怕。
虽然angular不用状态管理，也能把状态管理的不错。但是，但是来了，在开发过程中，发现如果真的有一些公共的变量，可能会被大量使用，那么，至少为这样的变量提供唯一的set入口方法，千万不要直接修改值！懂得都懂。简单一时爽，维护会哭的。当然，ng也有正统的状态管理，就是ngrx，为什么有个rx呢？因为rxjs啊。
=======20211122更新：
再回头来看看这个问题，其实我有点新的理解，发觉状态管理实际上是在通过一个架构/范式，强制你对自己的代码进行分层、封装。我觉得这个意义，比起时间回溯什么的大得多。但前端对状态管理的争论不休，实际上出自很多人不加考虑就把数据放到redux中，于是reducer和action无可避免发生膨胀，所以混乱又回来了。因此才有mobx这种库，消除reducer和action层。但复杂度实际上没有消失，只不过被平摊回到了原来零散的组件之中。因为不再强制你抽取逻辑到所谓的action中了。
总之，如果考虑得合理的话，一个应用的全局共享的数据，理论上并不会很多，所以redux还算普适的。但如果你的应用真的会发生全局数据层出不穷的情况，那可能还是考虑考虑mobx吧。而且吧，我觉得，总会有不适合抽到action里的情况出现的。所以强制搞action/reducer的方式，还是先保留意见，即使这已经是范式之一了。
除了把数据放到redux或context这种顶层的上下文中，我们还能怎么做呢？还有ref转发。但事实上，官网永远会强调又强调，希望你在使用redux、context、ref来管理数据时，要三思而后行。其实就是害怕混乱再次发生膨胀。为什么？因为前端的基因就是这样。前端永远都是巨量事件驱动的程序，变化丰富，而不同的项目之间也更是千差万别，这是前端必然面对的问题/挑战，我们很难获得一个范式能达到完美平衡。唯一的可能性，也许是有点像react这样，把最终决定权交还给开发者，而自身设计趋于透明化。最佳实践仍在探索和升级。
但其实从心理学去想想的话，其实人多少都是这样的：要么你就定下规则，让大家都这么做，写action/reducer，于是人们会一股脑地都这么做；要么你不定规则，那大家就干脆啥都不做。即使你说，高水平的人会处理好的，但问题是，统计概率上，这种问题永远会是处理不好的。好吧，我觉得很难提供一个普适的东西出来，除非把两种方式都兼容，引导你去思考和选择，而不是完全砍掉其中一种。
