前两天，用React把之前的基于树莓派3B,DHT11/DHT22,LCD1602的一个实时温度湿度检测系统的Web部分重构了一下。

这个项目之前是用Semantic UI + eCharts + JQuery Datapicker写的，由于这个项目的实现过程比较经典，几乎把所有的感觉React的基础思想都实现了一遍。

无疑，React给前端带来了各种新的想法与思想，声明式、虚拟Dom、单向数据流、JSX、组件化、Flux、以JavaScript为中心、React Native。

虚拟Dom

React是以JS为中心的，而非HTML，虚拟Dom是一个至关重要的概念。

在jQuery出现之前，我们一般都是直接操作Dom，方法“暴力、简单”，也存在兼容性的问题。在jQuery出现之后，jQuery的选择器帮助我们简单、高效的操作Dom，也就是在jQuery出现之后，前端就开始大爆发了。

但是随着发展，这种简单暴力的操作Dom的方法对于很多大型系统性工程来说，从软件工程的角度上讲，是杂乱、无序的，一旦时间久远，项目越来越大，维护成本就变大。于是，我们有了各种前端MVC、MVVM框架，典型的有Angular、React、vue.js，MVVM给我们带来一种全新的思想，数据绑定。

不过，与此同时，React给我们带来了一种全新的思想，虚拟Dom，从此，我们再也不用直接操作Dom了，而是用虚拟Dom更新Dom。

你可能会问，这样做，效率岂不是更低了？

是的，也不是。其实没有那么明显，一般来讲，操作Dom树的Diff算法应该是O(n^3)，而React把效率降低到了O(n)。

简单来讲，如图所示，React只会比较相同层级的Dom，从而简化了Dom Diff的复杂度，虽然有所舍弃，但是全局比较是没有必要的。

通过在JSX文件中写虚拟Dom，React在内存中会自动拿现在的虚拟Dom和旧的虚拟Dom进行Diff操作，如果发现有Diff的部分，就拿出来形成新的Patch部分，加入到现在的Dom树上。

也就是因为这个原因，虚拟Dom使得在操作Dom上更加高效，每次更新数据不会进行O(n^3)复杂的操作。

你可能会问，什么是JSX？

JSX

其实JSX只是一种未编译的JavaScript，可以方便的对HTML进行书写，先上代码：

import React from 'react';
import { Button } from 'semantic-ui-react';
class ButtonComponent extends React.Component {
    render() {
        return(
            
            分钟
            小时
            
        );
    }
}
export default ButtonComponent;

代码部分用ES6书写，你可能会问什么是ES6？其实还有ES7(ECMAScript 2016)呢~

那么，你可能看到了很变态的写法，就是HTML和JS混写，没错，这就是EJS，但请注意，这不是HTML，写着写着很有可能会掉入JSX陷阱。

经过babel等工具的编译后，JSX在运行的时候会被编译为真实的JavaScript语言，之所以这样写，只是为了方便程序员更方便的写代码。

比如上面的代码“HTML部分”会被编译为：

React.createElement('button', {class: 'ui blue button'}, '分钟');
React.createElement('button', {class: 'ui violet button'}, '小时');

当然，JSX也有很多坑，比如：

Module build failed: SyntaxError: Adjacent JSX elements must be wrapped in an enclosing tag

作为新手，这个问题，我经常遇到，因为你在写每一个JSX模块的时候，你需要用类似于<div></div>作为开始与结尾，不规范的代码不会被编译成功。

ECMAScript(ES)

ES无疑是这几年最火的前端语言，没错，他是JavaScript的改进版，我知道，其实还有很多其他类似的比如CoffeeScript，但是ES会被各大浏览器所兼容支持，但是你可能会问到兼容性问题，没事，我们有babel工具。

ECMAScript：一个由 ECMA International 进行标准化，TC39 委员会进行监督的语言。通常用于指代标准本身。
JavaScript：ECMAScript 标准的各种实现的最常用称呼。这个术语并不局限于某个特定版本的 ECMAScript 规范，并且可能被用于任何不同程度的任意版本的 ECMAScript 的实现。
ECMAScript 5 (ES5)：ECMAScript 的第五版修订，于 2009 年完成标准化。这个规范在所有现代浏览器中都相当完全的实现了。
ECMAScript 6 (ES6) / ECMAScript 2015 (ES2015)：ECMAScript 的第六版修订，于 2015 年完成标准化。这个标准被部分实现于大部分现代浏览器。可以查阅这张兼容性表来查看不同浏览器和工具的实现情况。
ECMAScript Proposals：被考虑加入未来版本 ECMAScript 标准的特性与语法提案，他们需要经历五个阶段：Strawman（稻草人），Proposal（提议），Draft（草案），Candidate（候选）以及 Finished （完成）。
ECMAScript 2016：第七版 ECMAScript 修订，增加了两个新特性。

以上，都是我们常说的ES，在网上看到的代码目前以ES5和ES6居多，写法各异，我建议用最新版的写法写代码。

说白了，就是Javascript并不是一个优秀的语言，但是经过不断的填补，修正，已经让Javascript支持了很多新特性，新的语法，更多的书写方式，以及拥有了更严谨的编程思想。比如let,arrow function(就是这个：(i) => i + 1 )在ES中的运用等。

所以，在认识React之前，最好学习ES的新特性以及常用的新特性。

组件化

我觉得这是React的重量级思想，组件化前端，从此，前端再也不是东拼西凑，而是像积木一样，拼起来。

React把单一的用户界面，拆成了各种各样的组件，形成“组件树”，采用分而治之的思想，有一个好处，就是维护起来极其方便，对于组件的修改也显得很容易。

数据绑定

众所周知，Angular是双向数据绑定的，并且引以为豪，因为更容易维护与理解。

但是双向数据绑定也带来了许多问题，会在些其他功能的时候莫名其妙出现很多bug。

React是单向数据绑定的，是非常稳定的做法，但是也存在一些问题，就是在操作其他组件的时候，对于数据流的处理，显得异常困难。

在React中，数据绑定仅仅需要在render中写{数据绑定}，而非像Angular一样，两边都要设置，一定情况下讲，这是比较方便的。

数据模型

state

话说回来，React的每一个组件的实质是什么？状态机（State Machines），在React的每一个组件里，通过更新this.state，再通过render()进行渲染，React会自动把最新的状态渲染到网页上。

举个栗子🌰

class DateSelectorComponent extends Component {
    constructor(props) {
    super(props);
    let todaydate = this.showLocale(new Date());
     this.state = {
         timenow: todaydate,
         showCalendar: false
    }
            return(
            
            
            
            {CalendarComponent}
            
        )
}

通过这样的方式，我就设置了state的默认初始值，默认日历选择器是不出现的，而今天的日期是今天日期，这很正常。然后在将所谓的值渲染到Dom上。

props

React的数据流是单向的，是自上向下的层级传递的，props可以对固定的数据进行传递。

class HelloMessage extends Component {
  render( 
    return Hello {this.props.name};
    )
}
class MainPage extends Component {
render(){
 return(
  
  )
 }
}

在这种情况下，子组件会自动读取出父组件传递过来的props值John，并快速的渲染在页面上。

到底谁是谁

state和props看起来很相似，其实是完全不同的东西。

问题	props	state
可以从父组件得到初始值吗？	可以	可以
可以被父组件改变值吗？	可以	不可以
可以设置组件内部的初始值吗？	可以	可以
可以改变组件内部的初始值吗？	不可以	可以
可以设置子组件的初始值吗？	可以	可以
可以改变子组件的初始值吗？	可以	不可以

按照我的个人理解，props是静态的，存入不变量，比如购物车里的商品名称、价格；state是动态的，存入随时变化的量，比如用户购买商品的总价，购买数目。

从操作的角度上讲，props是单向传递的，会一直被传递到子组件，而state更倾向于自身，只能改变自身的值。

获取Dom

this.refs是react的重要组成之一，通过该方法可以快速高效的获取Dom。

例如，在JSX代码中这样写道

<input ref="myInput" />

便可以通过

this.refs.myInput.value

命令获取该Input下的dom属性的value值，非常方便。

生命周期

组件都是有生命周期的，生命周期内，props和state改变会导致React自动用Diff算法重新渲染页面。那么生命周期到底都有哪些呢？

大体上分为三类：

挂载：组件被插入到DOM中。
更新：组件被重新渲染，查明DOM是否应该刷新。
移除：组件从DOM中移除。

从流程上讲，是这样的：

挂载期：

getInitialState() –>> componentWillMount() –>> render() –>> componentDidMount()

更新期：

componentWillReceiveProps() –>> shouldComponentUpdate() –>> componentWillUpdate render() –>> componentDidUpdate()

移除期：

componentWillUnmount()

挂载

componentWillMount()：在初次渲染之前执行一次，最早的执行点

componentDidMount()：在初次渲染之后执行，比较常用，比如持续执行某事件：

componentDidMount(){
 setInterval(this.loadData(this.state.date),1000);
}

更新

componentWillReceiveProps()：在组件接收到新的 props 的时候调用。在初始化渲染的时候，该方法不会调用。

shouldComponentUpdate()：在接收到新的 props 或者 state，将要渲染之前调用。

componentWillUpdate()：在接收到新的 props 或者 state 之前立刻调用。

componentDidUpdate()：在组件的更新已经同步到 DOM 中之后立刻被调用。

移除

componentWillUnmount()：在组件从 DOM 中移除的时候立刻被调用。

Flux

React是MVC中V的一部分，而Flux则是M和C的部分，Flux是单向数据流，符合React的核心思想，不过，Flux并不完善，是一个很松散的架构。

Dispatcher：处理动作分发，维护 Store 之间的依赖关系
Store：数据和逻辑部分
View： React 组件，这一层可以看作 controller-views，作为视图同时响应用户交互
Action：提供给 Dispatcher 传递数据给 Store

Redux

Flux把总架构都搭好了，可是实现起来并不容易，因为Flux并没有强大的API，只是一种纯粹的思想实现，而Redux是Flux的“升级版”，把各个部分更加方便的实现起来。

此部分未完待续

总结

我觉得React给前端开发带来了一种全新的思想，那就是以JS为中心，一种全新的世界。

网页不再是网页，而是像工程一样，一块块搭建起来的，拆下来，搬上去都很容易，似的前端再也不是那个凌乱拼凑的年代。

我想任何一种编程语言，无论是解释性、脚本、编译语言都逃离不了这个全新的年代，就是组件化，大家似乎都在不同方向发展，但实际上，确实一样的。

我眼中的 React