ReactNative

RND，可以简单看做是 ReactNative 在桌面系统上的实现，Native 部分采用C++开发。RND 的 JS Framework 基于 RN 0.57.8，node.js 运行时 8.1.2。

一、开发环境

安装nodejs：v12.10.0
安装vscode：v1.46.0

初始化工程：

npm install -g react-native-cli
react-native init demo --version 0.57.8
npm install --save @suhao/react-node-desktop
react-native clone-demo

调试
```
react-native run-demo
```
打包
```
react-native package
```

二、重要概念

1. Flexbox布局

在 flex 容器中默认存在两条轴，水平主轴(main axis) 和垂直的交叉轴(cross axis)，这是默认的设置，当然你可以通过修改使垂直方向变为主轴，水平方向变为交叉轴，这个我们后面再说。

在容器中的每个单元块被称之为 flex item，每个项目占据的主轴空间为 (main size), 占据的交叉轴的空间为 (cross size)。

这里需要强调，不能先入为主认为宽度就是 main size，高度就是 cross size，这个还要取决于你主轴的方向，如果你垂直方向是主轴，那么项目的高度就是 main size。

实现 flex 布局需要先指定一个容器，任何一个容器都可以被置顶为 flex 布局，这样容器内部的元素就可以使用 flex 来进行布局。简单说来，如果你使用块元素如 div，你就可以使用 flex，而如果你使用行内元素，你可以使用 inline-flex。

需要注意的是：当时设置 flex 布局之后，子元素的 float、clear、vertical-align 的属性将会失效。

2. Style样式定义

<View style={{width:50,height:50,backgroundColor:'red'}}></View>

在React Native中，您并不需要学习什么特殊的语法来定义样式。仍然是使用JavaScript来写样式。所有的核心组件都接受名为style的属性。这些样式名基本上是遵循了web上的CSS的命名，只是按照JS的语法要求使用了驼峰命名法，例如将background-color改为backgroundColor。

style属性可以是一个普通的JavaScript对象。这是最简单的用法，因而在示例代码中很常见。你还可以传入一个数组——在数组中位置居后的样式对象比居前的优先级更高，这样你可以间接实现样式的继承。比如：

<Text style={[styles.welcome,{fontSize:30}]}>
    Hello,RN
</Text>

实际开发中组件的样式会越来越复杂，我们建议使用StyleSheet.create来集中定义组件的样式。比如像下面这样：

const styles = StyleSheet.create({
    container: {
        flex: 1,
        justifyContent: 'center',
        alignItems: 'center',
        backgroundColor: '#F5FCFF',
    },
    welcome: {
        fontSize: 20,
        textAlign: 'center',
        margin: 10,
    },
    instructions: {
        textAlign: 'center',
        color: '#333333',
        marginBottom: 5,
    },
    button: {
        backgroundColor:'black'
    }
});

常见的做法是按顺序声明和使用style属性，以借鉴CSS中的“层叠”做法（即后声明的属性会覆盖先声明的同名属性）。

3. Props参数传递

大多数组件在创建时就可以使用各种参数来进行定制。用于定制的这些参数就称为props（属性）。

以常见的基础组件Image为例，在创建一个图片时，可以传入一个名为source的prop来指定要显示的图片的地址，以及使用名为style的prop来控制其尺寸。

自定义的组件也可以使用props。通过在不同的场景使用不同的属性定制，可以尽量提高自定义组件的复用范畴。只需在render函数中引用this.props，然后按需处理即可。

4. State状态控制

我们使用两种数据来控制一个组件：props和state。props是在父组件中指定，而且一经指定，在被指定的组件的生命周期中则不再改变。对于需要改变的数据，我们需要使用state。

一般来说，你需要在constructor中初始化state（译注：这是ES6的写法，早期的很多ES5的例子使用的是getInitialState方法来初始化state，这一做法会逐渐被淘汰），然后在需要修改时调用setState方法。

大多数组件在创建时就可以使用各种参数来进行定制。用于定制的这些参数就称为props（属性）。

假如我们需要制作一段不停闪烁的文字。文字内容本身在组件创建时就已经指定好了，所以文字内容应该是一个prop而文字的显示或隐藏的状态（快速的显隐切换就产生了闪烁的效果）则是随着时间变化的，因此这一状态应该写到state中。

典型的场景是在接收到服务器返回的新数据，或者在用户输入数据之后。你也可以使用一些“状态容器”比如Redux来统一管理数据流（译注：但我们不建议新手过早去学习redux）。

5. Props和State比较

props是properties的缩写，您可以把任意类型的数据传递给子组件，如此子组件的默认数据源就是props。在使用中可以通过this.props.data调用props属性，但是切记不能用this.props.xxx修改属性,这会导致props错乱。可以把props当做const类型来看待。

state是组件的内部状态属性，主要用来存储组件自身需要的数据。除了初始化时可能由props来决定，之后就完全由组件自身去维护。组件中由系统定义了setState方法，每次调用setState时都会更新组件的状态，触发render方法重新渲染界面。需要注意的是render方法是被异步调用的，这可以保证同步的多个setState方法只会触发一次render，这样做是有利于提高性能的。

6. 组件生命周期

创建阶段：该阶段主要发生在创建组件类的时候，在这个阶段中会初始化组件的属性类型和默认属性
实例化阶段：该阶段主要发生在组件类被调用(实例化)的时候。
- constructor是对控件的一些状态进行初始化，由于该函数不同于defaultProps，在以后的过程中，会再次调用，所以可以将控制控件的状态的一些变量放在这里初始化。切记，在此处不要使用setState。
- componentWillMount准备加载组件。这个调用时机是在组件创建，并初始化了状态之后，在第一次绘制 render() 之前。可以在这里做一些业务初始化操作，也可以设置组件状态。这个函数在整个生命周期中只被调用一次。如果在这个函数里面调用setState，本次的render函数可以看到更新后的state，并且只渲染一次。
- render是一个组件必须有的方法，形式为一个函数，渲染界面，并返回JSX或其他组件来构成DOM，和Android的XML布局、WPF的XAML布局类似，只能返回一个顶级元素。
- componentDidMount()调用了render方法后，组件加载成功并被成功渲染出来以后所执行的hook函数，一般会将网络请求等加载数据的操作，放在这个函数里进行，来保证不会出现UI上的错误。
运行(更新)阶段：
- componentWillReceiveProps(nextProps)：当组件接收到新的props时，会触发该函数。在该函数中，通常可以调用setState()来完成对state的修改。输入参数 nextProps 是即将被设置的属性，旧的属性还是可以通过 this.props 来获取。在这个回调函数里面，你可以根据属性的变化，通过调用 this.setState() 来更新你的组件状态，这里调用更新状态是安全的，并不会触发额外的 render() 调用
- shouldComponentUpdate(nextProps, nextState): 返回布尔值（决定是否需要更新组件）。输入参数 nextProps 和上面的 componentWillReceiveProps 函数一样，nextState 表示组件即将更新的状态值。这个函数的返回值决定是否需要更新组件，如果 true 表示需要更新，继续走后面的更新流程。否者，则不更新，直接进入等待状态。默认情况下，这个函数永远返回 true 用来保证数据变化的时候 UI 能够同步更新。在大型项目中，你可以自己重载这个函数，通过检查变化前后属性和状态，来决定 UI 是否需要更新，能有效提高应用性能。
- componentWillUpdate(nextProps, nextState)：shouldComponentUpdate返回true或者调用forceUpdate之后，就会开始准更新组件，并调用 componentWillUpdate()。输入参数与 shouldComponentUpdate 一样，在这个回调中，可以做一些在更新界面之前要做的事情。需要特别注意的是，在这个函数里面，你就不能使用 this.setState 来修改状态。这个函数调用之后，就会把 nextProps 和 nextState 分别设置到 this.props 和 this.state 中。紧接着这个函数，就会调用 render() 来更新界面了。
- render()：再确定需要更新组件时，调用render，根据diff算法，渲染界面，生成需要更新的虚拟DOM数据。
- componentDidUpdate()：虚拟DOM同步到DOM中后，执行该方法，可以在这个方法中做DOM操作。除了首次render之后调用componentDidMount，其它render结束之后都是调用componentDidUpdate。
- componentWillMount、componentDidMount和componentWillUpdate、componentDidUpdate可以对应起来。区别在于，前者只有在挂载的时候会被调用；而后者在以后的每次更新渲染之后都会被调用。 ps：绝对不要在componentWillUpdate和componentDidUpdate中调用this.setState方法，否则将导致无限循环调用。
销毁阶段: 该阶段主要发生组件销亡的时候，触发componentWillUnmount。当组件需要从DOM中移除的时候，通常需要做一些取消事件绑定，移除虚拟DOM中对应的组件数据结构，销毁一些无效的定时器等工作，都可以在这个方法中处理。
- componentWillUnmount: 当组件要被从界面上移除的时候，就会调用 componentWillUnmount。在这个函数中，可以做一些组件相关的清理工作，例如取消计时器、网络请求等。

7. 生命周期调用和setState

8. 原生组件

React Native 的一个很大的技术特点就是它虽然用JavaScript语言开发，但是界面用原生端控件来渲染，从而获得平台上的组件本来就具备的所有特性和原生开发出来的界面一致的体验。

RN 中的原生组件通常包含原生端实现（用i平台原生语言开发）和JS端的载体（将原生控件的属性和方法暴露给JS端）两个部分。

原生组件使得RN具备很大的灵活性，RN官方自带的组件库不能满足需求的时候，可以随时将用原生语言开发的控件（包括开源的）封装成JS端可以使用的组件，这也使得RN 开源社区蓬勃发展，催生了各种开源RN组件，封装了各种高级组件，是RN官方组件的有益补充，降低了使用门槛，提高了开发效率。

9. 原生模块

React Native官方封装了一些API用来调用原生端能力，但是毕竟无法满足各种各样的需求。RN提供的原生模块特性为你提供了一种便捷的途径来将原生端的所有能力暴露给JS端调用。当RN官方还不支持某个你需要的原生特性时，你就可以用原生模块来自己实现该特性的封装。

RN原生模块的实现一般只需要编写原生端代码，暴露一些方法（支持回调，不支持直接返回值，因为跨语言通信是异步的）给JS端，JS端简单调用这些方法就可以了。有时为了使用方便，我们也可以将某个原生模块在JS端对应的实现一个类，封装里面的方法，这样调用方法的时候就可以利用IDE的代码自动补全功能，提高便利性，也可以同时封装一些额外的逻辑，比如参数校验等等。

常见错误

1. SyntaxError: Invalid regular expression: Unterminated character class at new RegExp ()

命令：react-native init App_RND --template typescript --version 0.57.8 && node App_RND/setup.js
参考：https://stackoverflow.com/questions/58120990/how-to-resolve-the-error-on-react-native-start
修复：nvm install 12.10.0 & nvm use 12.10.0

2. yarn与npm混合使用的依赖验证

参考：https://github.com/yarnpkg/yarn/issues/5240
npm5要求在安装完成后的package.json中增加一些元数据，yarn不会产生这些元数据。所以之后运行npm install其他package的时候，npm5会认为之前由yarn安装的一些包是未经验证的（缺少元数据），因此会删除它们
修复：使用yarn，或者再次执行npm install

worldsite / blog.sc

ReactNative #29