React Native面向未来架构

时间:2021-1-8 作者:admin

既然面向未来,那么项目的架构设计采用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.memoReact.PureComponent类似,作用:检查Props是不是变了,如果变了才会真正的去更新,但得记住这是一个浅比较。

这是我们实现最小粒度更新的关键

Ok,正文开始,设计组件。

我们先看一个页面的组成是这个样子的

所以大多数项目的目录结构都会有一个components目录,顾名思义这个目录用来存放公用组件

都知道React是组件化思想。那你真的理解了什么是组件化吗?开发的时候,觉得这个组件是可以抽出来的,就丢到components目录下去了?

这是一个非常糟糕的做法。公用组件意味着无副作用,大胆用放心用。如果只是你觉得可以抽出来做一个组件,放到components目录下,那这个组件如果包含业务代码怎么办?开发人员还要阅读你的这个组件,确保没有副作用,才能使用,降低了效率,严重的话还会产生bug。

React官方建议:多写无状态组件;组件最小粒度化;组件只是数据的管道工!

组件其实是分为两种组件

  • 无状态组件 (用函数式编程理解:相同输入,相同输出,毫无副作用;这种组件才该放入components目录下

  • 有状态组件(用函数式编程理解:相同输入,不一定相同输出,还可能修改外部的值)

在React 16.8版本之前,也就是还没有推出hooks之前,可以这样设计组件,就可以非常好的区分

  • 无状态组件:使用function来写组件

  • 有状态组件:使用class来写组件

我们的架构是围绕React/React native新特性,当然得用hook+函数,无class该如何设计组件?

一个页面的视图组成部分应该是这样的

所以我们需要为组件分两个目录

  • components 无状态组件存放目录

  • container 有状态组件存放目录

components目录下的无状态组件

核心:组件最小粒度化;组件只是数据的管道工

  • component必须使用React.memo来控制

  • component内部不允许改变外部的值(可以这么理解:大多数项目都会使用状态管理,例如reduxmobx等,统称为store,也就是说,不允许引入store和使用store的方法和变量,也就是不允许有业务代码)

  • props必须或尽量是基本类型(例如:stringnumber,组件保持最小粒度化了开发,所以满足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
        // --------------------------------
    )
})

区别显而易见,结论:

  • componentcontainer的唯一区别就是有无store

  • 最大程度的复用,而且没有副作用。复用也是间接减少bug的,因为你复用的代码是上个版本的,上个版本是经过测试的,我们可以默认它是无bug,稳定的代码。

  • 实现最小粒度更新,完美控制性能

说完组件设计,接下来是逻辑的复用

componentcontainer描述和伪代码,我们可以看到有相同部分

  • state
  • 生命周期
  • 业务逻辑

依靠hook的特性,只要你觉得抽出去有价值那就抽!这样不光是container还是component都可以复用逻辑,又提高效率了!所以又多出了一个新目录:hooks目录

所以视图部分架构就诞生了!

ok,到现在为止就有3个目录了

  • components 无状态组件

  • container 有状态组件

  • hooks 存放可复用hook

说完视图部分,接下就是状态管理了

不用多说,先多一个store目录

mobxredux大家应该都很熟悉了,这里就不介绍了;这两个都有为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,会变得更加独立,降低耦合。不会出现动一发牵全身

状态管理的构建设计就出来了

最后一步,处理复合类型数据,保证最小粒度更新

举个例子,请求一个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 = 100

ok,就算你凑合凑合的使用类型上述的办法(毕竟换汤不换药嘛),但是会发生一个问题就是,用到这个state,或者只是用到这个state里的某个变量,都会导致这些组件重新渲染。还记得我们前面我们组件的设计是,尽量使用基本类型的props和memo来控制,所以大部分视图是不会被重新渲染的,只有小部分组件会被渲染,因为那一部分组件用的是对象,即使这个对象里的变量并没有改变。为什么会这样呢?

// 深拷贝让state.A.obj1.obj100.o = 100

state <地址被改变> = {
     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]
        }
    },
    ...
}

就这样就可以渲染“真正需要更新的组件”;简单的用法,改值最佳性能,实现最小粒度更新;

到这里就该结束了,现在再梳理一下整体的设计,完美!

重要的是思想

顺带推荐一个自己写的react-native UI库,完美契合这套架构,sparrowcool

我是否有必要为这套架构写一个脚手架?

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。