这是我参与[第四届青训营]笔记创作活动的第7天。此笔记用于记录课上所讲内容。

一、React的历史与应用

1、应用场景：

①、前端应用开发，如Facebook，Instagram等网页版

②、移动原生应用开发

③、结合Electron，进行桌面应用开发

2、发展历史

2010年，Facebook在其PHP生态中，引入了xhp框架，首次引入了组合式组件的思想，启发了后来的React的设计。 2011年，Jordan Walke创造了FaxJS，也就是后来React的原型。 2012年，Facebook收购Instagram后，FaxJS项目在内部得到使用。 2013年，React正式开源。

二、React的设计思路

听了老师讲的课，我觉得收获最大的就是在学习一个新框架之前，要先理清它的设计思路，要明白它为什么这么设计？这么设计是为了解决什么问题？以下是我在听了老师所讲内容对React设计思路的一个个人总结。

我们在浏览网页，或者在使用APP的进行购物的时候，会遇到要选择产品参数这样的情况。页面根据使用者选择的参数的不同，对价格进行相应的变化。

从开发者角度来看，如果使用原生的JS来开发，那我们就需要对每一个按钮进行点击事件的绑定，并且要写根据参数改变而变化的函数，这样一看代码势必不会很少，同时也暴露了原生JS的编程痛点：

①状态更新，UI不会自动更新，需要手动调用DOM进行更新。

②欠缺基本的代码层面的封装和隔离，代码层面没有组件化。

③UI之间的数据依赖关系(可简单理解为牵一发而动全身），需要手动维护，如果依赖链路长，则会遇到“Callback Hell”。

在了解了原生JS的UI编程痛点后，我们还要考虑一个方面：响应式系统与转换式系统。在编写前端代码的时候，代码运行的本质就是一个响应式系统，那么什么是响应式系统？

响应式系统：事情发生之后执行既定的回调，然后进行状态的变更，即监听事件，消息驱动。例如监控系统，UI界面。

转换式系统：将源代码作为输入，进行复杂的转换后产生输出。即给一个输入，求解输出的过程。例如编译器，数值计算。

但是一旦我们需要变更的UI变得越来越多的时候，代码就会变得更加复杂，因此产生了解决原生JS的UI编程通电的想法：

即状态更新，UI自动更新；前端代码组件化，可复用，可封装；状态之间的互相依赖关系，只需声明即可。

在考虑了上述两个问题的前提下，可以使用组件化的思想来试图解决这个问题。 在编写页面布局时，我们常常将页面划分为几个部分，每一个部分包含特定的内容，那么我们就可以将页面布局的部分划分，看作一棵树。整个页面看做根节点，包含的部分看作是叶子节点，这些节点就是一个个组件，拼成一个完整的界面。同时，我们要注意，这棵树不是DOM树，仅仅是一棵方便理解页面结构的树。 那么接下来我们来了解组件化：

①组件是组件的组合/原子组件

②组件内拥有状态，外部不可见

③父组件可将状态传入组件内部，即父组件可以控制子组件

这里就会产生一个问题，结构树的最底层的叶子节点的归属属于哪个节点？也就是网页购物中的价格的状态，归属于哪个节点。

状态归属属于两个节点向上寻找到最近的祖宗节点。那么价格就属于根结点Root。 当前价格该如何进行改变呢？我们可以通过onChangeValue()方法从根结点向下传递给价格节点。

依据以上条件，可以得出组件设计：

①组件声明了状态和UI的映射。

②组件有Props/State两种状态。

③“组件”可由其他组件拼装而成。

那么就可以开始考虑组件代码会是什么样子？

①组件内部拥有私有状态State。

②组件接受外部的Props状态提供复用性。

③根据当前的State/Props，返回一个UI。

那么我们就可以根据上述的思路，想象一下，得到这样一段代码：

functino Component(props){
//props是父组件传入的状态
const {url} = props;
this.text = '点击我';//状态

//返回一个UI
return (<div>
      <SubComponent props = {{color : 'red' }}></SubComponent>
      <img src = {url}></img>
      <button>text</button>
</div>)
}

这一段代码不一定正确，但是我们可以按照这个思路进行React的学习了。