针对与大部分前端，都是业务，前端，但我并不觉得，写业务的就没有做架构的难，很多业务开发，工期紧张的情况下 业务写的，难以理解，难以复用，对于开发自己也没有成长
初期学前端，没有太多对于框架思想的理解，会习惯的把业务逻辑，全部都杂糅到业务组件内部，但是随着业务逐步变的复杂，发现这种把，数据层，模型层，视图层，混乱在一起，是不对的。
从设计模式上来讲，就是MVC ,无论是基础组件也好，业务组件也罢，对于展示类的，始终是只做数据承接，而不应该把数据层相关逻辑，杂糅到视图层里面。
正交和解耦
所谓正交就是一个模块的变化，并不会去影响到其他模块的变化，是相互独立的， 对于前端，常见解耦方式就是分层 通过将业务逻辑拆分，为视图层，模型层，数据层。 视图层用来去纯展示页面 ，模型层用来操作数据，进行状态变化，数据层，就只是去获取你需要的数据，彼此之间，不要相互影响，否则各种状态混乱导致的bug
MVVM 分层模式
- 一般业务组件，很多时候，都图省事，都直接在V视图层，写入业务逻辑，这个就是把视图层和模型层，之间的逻辑耦合，最直接导致的问题，就是定位BUG 极其困难，一个bug 看几天都有可能对于比较复杂的模块
- 那么如何从根源来解决这个问题、
- react 框架本身具备MVVM设计理念，但是具体到咱们的代码中，是如何进行拆分解耦，和分层的呢。
- M 模型层，可以理解为 你再组件或者store 中定义的数据结构
- v 视图层，其实就是组件ui视图
- vm 视图模型层，主要是用来处理业务逻辑，以及数据格式化问题。
- 每层之间的逻辑都相互独立出去。
- 这样的好处在于，如果视图异常，那就看返回的数据，如果数据对，那就找vm里面如何去处理渲染逻辑的，如果数据不对，就找处理数据的逻辑，做到，避免耦合定位问题困难
react 实践点
- 避免增加全局数据，最开始，我为了能把所有的数据状态，进行统一管理，最后发现,有两个问题，一个是对于单个模块，过多的全局状态，其实并未复用，难以维护和扩展，其次是数据流，在渲染情况较复杂的时候，反而更加不清晰，我每个单独的模块，在设置状态后， 还要再从全局状态中再去获取，这就导致一个问题，在useEffect依赖管理中，依赖过多时，无法保障状态变更顺序，导致调试困难。
- 所以，全局状态确实解决了，状态复用问题，但不代表可以滥用
