React Native面向未来架构
既然面向未来，那么项目的架构设计采用React/React native的新特性，并且为即将来到的新特性预留位置；对核心依赖库保持最小代码侵略性和最底依赖；且满足以下这几点。
高性能
高效率
易拓展
低耦合
易测试
少bug
协作开发
我们先从项目最小的一个点开始讲：组件
这里有一个性能关键点, 举个例子
A组件:
const A = ({count}) => {
React.useEffect(() => {
console.log('render A')
});
return <Text >{count}</Text>}B组件
const B = () => {
React.useEffect(() => {
console.log('render B')
});
return <View />}把这两个组件拼在一起,每次点击A组件的时候都会让count+1
const App = () = > {
const [count, setCount] = React.useState(0);
React.useEffect(() => {
console.log('render App')
});
return (
<>
<Pressable onPress={()=>setCount(count+1)} >
<A count={count} />
<Pressable>
<B />
</>
)}想象中的打印结果
render App render A
真实的打印结果:
render App render A render B
我第一次发现的时候，竟然是这样的打印结果，我懵了都，难道不会帮我控制性能吗？ React 就这？
打印结果表明：每一次父组件的state更新，都会导致所有子组件重新渲染。那这样性能岂不是太差了！
其实这不并不是真正意义上的渲染，
react底层会有diff算法，会帮你更新“真正需要更新的组件”。
所以我们要手动控制，赶在diff算法之前不让它“渲染”；其实很简单，React.memo(组件)，就这样套住组件就可以了，就可以得到我们想象中的打印结果了；React.memo和React.PureComponent类似，作用：检查Props是不是变了，如果变了才会真正的去更新，但得记住这是一个浅比较。
这是我们实现最小粒度更新的关键
Ok，正文开始，设计组件。
我们先看一个页面的组成是这个样子的
BDze0S.md.png
所以大多数项目的目录结构都会有一个components目录，顾名思义这个目录用来存放公用组件
都知道React是组件化思想。那你真的理解了什么是组件化吗？开发的时候，觉得这个组件是可以抽出来的，就丢到components目录下去了？
这是一个非常糟糕的做法。公用组件意味着无副作用，大胆用放心用。如果只是你觉得可以抽出来做一个组件，放到
components目录下，那这个组件如果包含业务代码怎么办？开发人员还要阅读你的这个组件，确保没有副作用，才能使用，降低了效率，严重的话还会产生bug。
React官方建议：多写无状态组件；组件最小粒度化；组件只是数据的管道工！
组件其实是分为两种组件：
无状态组件（用函数式编程理解：相同输入，相同输出，毫无副作用；这种组件才该放入components目录下）有状态组件（用函数式编程理解：相同输入，不一定相同输出，还可能修改外部的值）
在React 16.8版本之前，也就是还没有推出hooks之前，可以这样设计组件，就可以非常好的区分
无状态组件：使用function来写组件有状态组件：使用class来写组件
我们的架构是围绕React/React native新特性，当然得用hook+函数，无class该如何设计组件？
一个页面的视图组成部分应该是这样的
BrpbWj.md.png
所以我们需要为组件分两个目录
components无状态组件存放目录container有状态组件存放目录
components目录下的无状态组件
核心：组件最小粒度化；组件只是数据的管道工
component必须使用React.memo来控制component内部不允许改变外部的值（可以这么理解：大多数项目都会使用状态管理，例如redux，mobx等，统称为store，也就是说，不允许引入store和使用store的方法和变量，也就是不允许有业务代码）props必须或尽量是基本类型（例如：string，number，组件保持最小粒度化了开发，所以满足props是基本类型这一点非常简单；其次，基本类型的props，才能发挥React.memo真正的作用）允许有自己的
state，生命周期，也就是hook
component伪代码像这样
const ComponentDemo = React.memo((props)=>{
// --------------------------------
// state 部分
// --------------------------------
// --------------------------------
// 生命周期 部分
// --------------------------------
return (
// 视图
)})container目录下的有状态组件
核心：一个container，渲染部分应该尽量使用component进行拼接组成
container同样使用React.memo来控制container内部允许改变外部的值（允许引入store和使用store的方法和变量）props尽量是基本类型允许有自己的
state，生命周期，也就是hook
container伪代码如下
const ContainerDemo = React.memo((props)=>{
// --------------------------------
// store 部分
// --------------------------------
// --------------------------------
// state 部分
// --------------------------------
// --------------------------------
// 生命周期 部分
// --------------------------------
// --------------------------------
// 业务逻辑 部分
// --------------------------------
return (
// --------------------------------
// component 1
// --------------------------------
// --------------------------------
// component 2
// ......
// --------------------------------
// --------------------------------
// 拼接的代码例如像View
// --------------------------------
)})区别显而易见，结论:
component和container的唯一区别就是有无store最大程度的复用，而且没有副作用。复用也是间接减少bug的，因为你复用的代码是上个版本的，上个版本是经过测试的，我们可以默认它是无bug，稳定的代码。
实现最小粒度更新，完美控制性能
说完组件设计，接下来是逻辑的复用
component和container描述和伪代码，我们可以看到有相同部分
state生命周期业务逻辑
依靠hook的特性，只要你觉得抽出去有价值那就抽！这样不光是container还是component都可以复用逻辑，又提高效率了！所以又多出了一个新目录：hooks目录
所以视图部分架构就诞生了！
BrkdQH.md.png
ok，到现在为止就有3个目录了
components无状态组件container有状态组件hooks存放可复用hook
说完视图部分，接下就是状态管理了
不用多说，先多一个store目录
mobx和redux大家应该都很熟悉了，这里就不介绍了；这两个都有为hook，提供了新的状态管理库（但是看下来都比较重，且代码侵略性比较高，对于hook来说有一种没有必要抽象的感觉），所以我们采用全新的状态管理工具hox
hox优点
只有一个api，简单，上手快，足够轻
非常易于复用
状态按模块分，清晰更好控制
完美支持
typescript对代码侵略性非常底，它不会成为我们支持未来的新特性，三方库的升级，甚至重构的负担
简单介绍下用法，大家肯定都有用过mobx/redux，为了更好理解，所以持久化的状态，就称之为store。
import { useState } from "react";import { createModel } from "hox";// -------------------创建一个持久化store------------------------const useCounter =() => {
// count这个state 持久化
const [count, setCount] = useState(0);
const decrement = () => setCount(count - 1);
const increment = () => setCount(count + 1);
// ----------------------------------------------
// 根据需要，这里可以使用自定义hook
// ----------------------------------------------
return {
count,
decrement,
increment };}export default createModel(useCounter);// 或者干脆整个store，直接用自定义hook// export default createModel(hook);// -------------------使用这个store------------------------------import useCounterModel from "../store/counter";const App=React.memo((props)=> {
const {count,decrement,increment} = useCounterModel();
return (
<View>
<Text>{count}</Text>
<Pressable onPress={increment}>
Increment </Pressable>
<Pressable onPress={decrement}>
decrement </Pressable>
</View>
);})ok,介绍完毕。就是这么简单！
再仔细看useCounter就是一个自定义hook，别忘了还有个hook目录，这个目录可全是自定义hook，这就意味着store里可以根据需求直接使用我们自定义hook，或者用自定义hook + 自己的业务代码拼接成一个全新的store！大大提高效率！so cool!
归结下优点：
核心：state最小粒度，是React的最佳实践
store也可以通过hook进行复用，相同业务代码不需要写多次，复用hook就完事了一个业务通过模块拆分多个
store，这个模块的store还可以继续拆分成更多store。所以各个store，会变得更加独立，降低耦合。不会出现动一发牵全身
状态管理的构建设计就出来了
Brlxnf.md.png
最后一步，处理复合类型数据，保证最小粒度更新
举个例子，请求一个api，获得结果后更新state，然后视图更新。
******** 请求 ************ 更新 ************** Api * <===== * store * =========> * state ********* =====> ************ ************* 结果
第一次api返回的结果
res={
A : {
a:1,
b:2
},
B : {
a:1,
b:2
}
}那这个时候直接setState(res)，没问题，视图也会正常更新
那么接下来第二次访问api返回结果
res={
A : {
a:1,
b:2
},
B : {
a:1,
b:3
}
}setState(res) state.B.b=3
以上两种操作，视图是都不会更新的，这里涉及到一个深浅拷贝的问题；
React对于复合类型判断是否更新是一个
浅比较也就是只比较内存地址。
所以为了让视图更新，我们需要进行深拷贝，拷贝到一个新对象中，这个新对象会分配一个新的内存地址
对这个对象进行遍历，把值全部拷贝到一个新的对象，
setState(新对象)。（如果是个复杂对象，想想就头疼）将这个对象转换成json，然后再从json转换成一个新的对象，然后
setState(新对象)。（这性能就不用我多说了吧，一个字，差！）
现在有一个复杂的对象
state = {
A : {
a:1,
obj1: {
obj100：{
o:1
}
array:[0,1,2]
}
obj2:{
o:1
obj100：{
o:1
}
array:[0,1,2]
}
},
...}// 现在需要让state.A.obj1.obj100.o = 100ok，就算你凑合凑合的使用类型上述的办法（毕竟换汤不换药嘛），但是会发生一个问题就是，用到这个
state，或者只是用到这个state里的某个变量，都会导致这些组件重新渲染。还记得我们前面我们组件的设计是，尽量使用基本类型的props和memo来控制，所以大部分视图是不会被重新渲染的，只有小部分组件会被渲染，因为那一部分组件用的是对象，即使这个对象里的变量并没有改变。为什么会这样呢？
// 深拷贝让state.A.obj1.obj100.o = 100state <地址被改变> = {
A <地址被改变>: {
a:1,
obj1 <地址被改变>: {
obj100 <地址被改变>：{
o:100 <值被改变>
}
array <地址被改变>:[0,1,2]
}
obj2 <地址被改变>:{
o:1
obj100 <地址被改变>：{
o:1
}
array <地址被改变>:[0,1,2]
}
},
...}以上的结果就可以清楚的知道，所以为什么发生不必要的渲染了，因为不需要更新对象却被更新了
所以这个时候得用一个库叫immer，基于immutable不可变数据结构。我就不细说了什么是不可变数据结构了，只讲结果。
使用
import produce from "immer";setState(
produce(state, draft => {
draft.A.obj1.obj100.o = 100
})
)state被改变后的结构
state <地址被改变> = {
A : {
a:1,
obj1: {
obj100 <地址被改变>：{
o:100 <值被改变>
}
array:[0,1,2]
}
obj2:{
o:1
obj100：{
o:1
}
array:[0,1,2]
}
},
...}就这样就可以渲染“真正需要更新的组件”；简单的用法，改值最佳性能，实现最小粒度更新；
到这里就该结束了，现在再梳理一下整体的设计，完美！
BrwHNq.md.png
重要的是思想
顺带推荐一个自己写的react-native UI库，完美契合这套架构，sparrowcool；
我是否有必要为这套架构写一个脚手架？
作者：BJoe
链接：https://www.jianshu.com/p/cde6771155df
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。