一分钟了解react

一分钟了解react

1. 以前我们没有jquery的时候，我们⼤概的流程是从后端通过ajax获取到数据然后使⽤jquery ⽣成dom结果然后更新到⻚⾯当中，但是随着业务发展，我们的项⽬可能会越来越复杂， 我们每次请求到数据，或则数据有更改的时候，我们⼜需要重新组装⼀次dom结构，然后 更新⻚⾯，这样我们⼿动同步dom和数据的成本就越来越⾼，⽽且频繁的操作dom，也使
   我我们⻚⾯的性能慢慢的降低。
2. 这个时候mvvm出现了，mvvm的双向数据绑定可以让我们在数据修改的同时同步dom的更新，dom的更新也可以直接同步我们数据的更改，这个特定可以⼤⼤降低我们⼿动去维护 dom更新的成本，mvvm为react的特性之⼀，虽然react属于单项数据流，需要我们⼿动实 现双向数据绑定。
3. 有了mvvm还不够，因为如果每次有数据做了更改，然后我们都全量更新dom结构的话，也没办法解决我们频繁操作dom结构(降低了⻚⾯性能)的问题，为了解决这个问题，react内部实现了⼀套虚拟dom结构，也就是⽤js实现的⼀套dom结构，他的作⽤是讲真实dom在js 中做⼀套缓存，每次有数据更改的时候，react内部先使⽤算法，也就是鼎鼎有名的diff算 法对dom结构进⾏对⽐，找到那些我们需要新增、更新、删除的dom节点，然后⼀次性对 真实DOM进⾏更新，这样就⼤⼤降低了操作dom的次数。 那么diff算法是怎么运作的呢， ⾸先，diff针对类型不同的节点，会直接判定原来节点需要卸载并且⽤新的节点来装载卸载 的节点的位置；针对于节点类型相同的节点，会对⽐这个节点的所有属性，如果节点的所 有属性相同，那么判定这个节点不需要更新，如果节点属性不相同，那么会判定这个节点 需要更新，react会更新并重渲染这个节点。
4. react设计之初是主要负责UI层的渲染，虽然每个组件有⾃⼰的state，state表示组件的状 态，当状态需要变化的时候，需要使⽤setState更新我们的组件，但是，我们想通过⼀个组 件重渲染它的兄弟组件，我们就需要将组件的状态提升到⽗组件当中，让⽗组件的状态来控制这两个组件的重渲染，当我们组件的层次越来越深的时候，状态需要⼀直往下传，⽆ 疑加⼤了我们代码的复杂度，我们需要⼀个状态管理中⼼，来帮我们管理我们状态state。
5. 这个时候，redux出现了，我们可以将所有的state交给redux去管理，当我们的某⼀个state 有变化的时候，依赖到这个state的组件就会进⾏⼀次重渲染，这样就解决了我们的我们需 要⼀直把state往下传的问题。redux有action、reducer的概念，action为唯⼀修改state的 来源，reducer为唯⼀确定state如何变化的⼊⼝，这使得redux的数据流⾮常规范，同时也 暴露出了redux代码的复杂，本来那么简单的功能，却需要完成那么多的代码。
6. 后来，社区就出现了另外⼀套解决⽅案，也就是mobx，它推崇代码简约易懂，只需要定义⼀个可观测的对象，然后哪个组价使⽤到这个可观测的对象，并且这个对象的数据有更改，那么这个组件就会重渲染，⽽且mobx内部也做好了是否重渲染组件的⽣命周期 shouldUpdateComponent，不建议开发者进⾏更改，这使得我们使⽤mobx开发项⽬的时 候可以简单快速的完成很多功能，连redux的作者也推荐使⽤mobx进⾏项⽬开发。但是， 随着项⽬的不断变⼤，mobx也不断暴露出了它的缺点，就是数据流太随意，出了bug之后 不好追溯数据的流向，这个缺点正好体现出了redux的优点所在，所以针对于⼩项⽬来说， 社区推荐使⽤mobx，对⼤项⽬推荐使⽤redux
   好了，基本上就这样了，可以多看看redux哦。

每天一句外语

俄语

Вас благодарю!(感谢您,多亏您!)
瓦斯布拉格大刘——-娃死不能赶大流