前言

react函数组件写法非常灵便，数据传递也十分不便，但如果对react的了解不够深刻，就会遇到很多问题，比方数据变了视图没变，父组件状态变了子组件状态没有及时更新等等，对于简单的组件来说，可能产生的问题会更多，凌乱的代码也更容易呈现。

随着本人踩的坑多了，就越来越意识到数据状态的正当设计对于React组件的重要性，大部分常见问题都是因为数据传递和批改凌乱导致的。

按照开发教训和官网文档，我对react组件状态设计做了一些些总结，心愿能帮大家理理思路。

组件的数据与状态

在聊组件状态设计之前，先聊聊组件的状态与数据，因为重点是组件状态设计，对局部前置常识只会做简略介绍，如果想具体理解，我在文中也有举荐文章，感兴趣的同学能够本人浏览哈。

组件中的数据状态起源有state和props，state由组件本身保护的，能够调用setState进行批改。而props是内部传入的，是只读的，要想批改只能由props传入批改的办法。

组件的state

当咱们调用setState批改state时，会触发组件的从新渲染，同步数据和视图。在这个过程中，咱们能够思考几个问题：

  1. 数据是怎么同步到视图的？
  2. state的状态是怎么保留的？
  3. why重渲染后state没有被重置为初始值？

一、数据是怎么同步到视图的？

先理解一下fiber

在react16之前，react的虚构dom树是树结构的，算法以深度优先准则，递归遍历这棵树，找出变动了的节点，针对变动的局部操作原生dom。因为是递归遍历，毛病就是这个过程同步不可中断，并且因为js是单线程的，大量的逻辑解决会占用主线程过久，浏览器没有工夫进行重绘重排，就会有渲染卡顿的问题。

React16呈现之后优化了框架，推出了工夫片与任务调度的机制，js逻辑解决只占用规定的工夫，当工夫完结后，不论逻辑有没有解决完，都要把主线程的控制权交还给浏览器渲染过程，进行重绘和重排。

而异步可中断的更新须要肯定的数据结构在内存中来保留工作单元的信息，这个数据结构就是Fiber。[1] (援用文章链接在文末，举荐)

fiber树以链表构造保留了元素节点的信息，每个fiber节点保留了足够的信息，树比照过程能够被中断，以后的fiber树为current fiber，在renderer阶段生成的fiber树称为workInProgress fiber，两棵树之间对应的节点由alternate指针相连，react会diff比照这两颗树，最终再进行节点的复用、减少、删除和挪动。

调用setState之后产生了什么？
  1. 首先生成调用函数生成一个更新对象，这个更新对象带有工作的优先级、fiber实例等。
  2. 再把这个对象放入更新队列中，期待协调。
  3. react会以优先级高下先后调用办法，创立Fiber树以及生成副作用列表。
  4. 在这个阶段会先判断主线程是否有工夫，有的话学生成workInProgress tree并遍历之。
  5. 之后进入调教阶段，将workInProgress tree与current Fiber比照，并操作更新实在dom。

二、state的状态是怎么保留的？

在fiber节点上，保留了memoizedState，即以后组件的hooks依照执行程序造成的链表，这个链表上存着hooks的信息，每种类型的hooks值并不相同，对于useState而言，值为以后state。

（小贴士: 深刻了解react hooks原理，举荐浏览《React Hooks 原理》）

函数组件每次state变动重渲染，都是新的函数，领有本身惟一不变的state值，即memoizedState上保留的对应的state值。（capture value个性）。

这也是为什么明明曾经setState却拿不到最新的state的起因，渲染产生在state更新之前，所以state是当次函数执行时的值，能够通过setState的回调或ref的个性来解决这个问题。

二、why重渲染后state没有被重置为初始值？

为什么组件都重渲染了，数据不会从新初始化？

能够先从业务上了解，比方两个select组件，初始值都是未选中，select_A选中选项后，select_B再选中，select_A不会重置为未选，只有刷新页面组件重载时，数据状态才会初始化为未选。

晓得state状态是怎么保留的之后，其实就很好了解了。

来划重点了——重渲染≠重载，组件并没有被卸载，state值依然存在在fiber节点中。并且useState只会在组件首次加载时初始化state的值。

常有小伙伴遇到组件没失常更新的场景就纳闷，父组件重渲染子组件也会重渲染，但为什么子组件的状态值不更新？就是因为rerender只是rerender，不是重载，你不人为更新它的state，它怎么会重置/更新呢？

ps：面对有些非受控组件不更新状态的状况，咱们能够通过扭转组件的key值，使之重载来解决。

组件的props

当组件的props变动时，也会产生重渲染，同时其子组件也会重渲染。


[图1-1]

如图1-1所示，组件A的state和props.data作为子组件1的props传入，当组件A的props发生变化时，子组件1的props也发生变化，会重渲染，然而子组件2是非受控组件，父组件A重渲染后它也会重渲染，然而数据状态没有变动的它，原本不须要从新渲染的，这就造成了节约。针对这样不须要反复渲染的组件或状态，优化组件的形式也有很多，比方官网提供的React.Memo，pureComponent，useMemo，useCallback等等。

react组件状态设计

数据与视图相互影响，简单组件中往往有props也有state，怎么规定组件应用的数据应该是组件本身状态，还是由内部传入props，怎么布局组件的状态，是编写优雅的代码的要害。

如何设计数据类型？props？state？常量？

先来看react官网文档中的段落：

通过问本人以下三个问题，你能够一一查看相应数据是否属于 state：

  1. 该数据是否是由父组件通过 props 传递而来的？如果是，那它应该不是 state。
  2. 你是否依据其余 state 或 props 计算出该数据的值？如果是，那它也不是 state。
  3. 该数据是否随工夫的推移而放弃不变？如果是，那它应该也不是 state。[2]

咱们一一把这些规定用代码具象化，聊聊不遵循规定写出的代码可能会产生的陷阱。

1.该数据是否是由父组件通过 props 传递而来的？如果是，那它应该不是 state。

// 组件Testimport React, {useState} from 'React'export default (props: {    something: string // *是父组件保护的状态，会被批改}) => {    const [stateOne, setStateOne] = useState(props.something)    return (        <>            <span>{stateOne}</span>        </>    )}

这段代码中useState的应用形式预计是很多老手小伙伴会写进去的，把something作为props传入，又从新将something作为初始值赋给了组件Test的状态stateOne。

这么做会存在什么问题？

  • 前文咱们说过，props变动会引发组件及其子组件的重渲染，然而，重渲染不等于重载，useState的初始值只有在组件首次加载的时候才会赋给state，重渲染时，是不能从新赋值的，并且以后fiber树上依然保留了hooks的数据，即以后的state状态值， 所以无论props.something怎么扭转，页面上展现的stateOne值不会随之扭转，始终是组件Test以后stateOne的值。

也就是说something从受控变成失控了。违反了咱们传值的本意。

那有什么解决办法呢？——能够在组件Test里，通过useEffect监听props.something的变动，从新setState。

// 组件Testimport React, {useState} from 'React'export default (props: {    something: string}) => {    const [stateOne, setStateOne] = useState()        useEffect(() => {        setStateOne(props.something) // 如果没有别的副作用，加一层state是不是看起来很多余    }, [props.something])    return (        <>            <span>{stateOne}</span>        </>    )}

可能有小伙伴会说，“我不是拿了props的值间接用呀，props的数据须要做一些批改后再应用，这不是须要一个两头变量去接管吗？用state难道不对吗？”

这里咱们引入第二个规定 —— “你是否依据其余 state 或 props 计算出该数据的值？如果是，那它也不是 state。”

2.你是否依据其余 state 或 props 计算出该数据的值？如果是，那它也不是 state。

state相较props最大的不同，就是state是可批改的，props是只读的，所以咱们想要对props的数据做些批改后再应用的时候，可能自然而然会想到用state作为两头变量去缓存，然而，这种场景应用useState却显得大材小用了，因为只在props变动的时候，你须要用到setState去重置state值，没有其余操作须要setState，这个时候咱们就不须要用到state。

所以这个场景能够间接应用变量去接收数据从新计算后的后果，或者，更好的方法是应用useMemo，用新的变量去接管props.something计算后的值。

// 组件Testimport React, {useState} from 'React'export default (props: {    something: number[]}) => {    // 形式一 每次重渲染都会从新计算    // const newSome = props.something.map((num) => (num + 1))    // 形式二 props.something变动时会从新计算    const newSome = useMemo(() = {        return props.something.map((num) => (num + 1))    }, [props.something])    return (        <>            <span>                {newSome.map((num) => num)}            </span>        </>    )}

还有一种状况，props传递的数据作为单纯的常量，而非父组件保护的状态，也就是说不会再次更新，子组件渲染须要这些数据，并且会操作这些数据，这时候是能够用state去接管的。

// 组件Testimport React, {useState} from 'React'export default (props: {    something: string // 在父组件中体现为不会扭转的常量}) => {    const [stateOne, setStateOne] = useState()    return (        <>            <span>{stateOne}</span>        </>    )}

还有一种更简单一些的状况，子组件须要父组件的状态A，依据A进行数据的重组，并且又须要改变这些新的数据，父组件的对状态A也有它本人的作用，不能间接被子组件扭转为子组件须要的数据。这种状况也是能够用state去接管的，因为子组件是须要去批改state的，并不是仅仅依赖props的值得到新的值。

// 父组件 export default (props) => {    const [staffList, setStaffList] = useState([])    // 异步申请后setStaffList(申请后果)    return (       <div>           {/* <div>{staffList相干的展现}</div> */}           <Comp staffList={[{name: '小李'}, {name: '小刘'}, {name: '小明'}]} />       </div>    )}// 子组件const Comp = ({staffList}) => {    const [list, setList] = useState(staffList)    useEffect(() => {        const newStaffList = staffList.map((item) => ({            ...item,            isShow: true        }))        setList()    }, [staffList])    const onHide = useCallBack((index) => {        // ... 为 克隆list暗藏下标为index项后的数据        setList(...)    }, []) // 写的时候别忘记填入依赖    return (        <div>            {                list.map((staff, index) => (                    staff.isShow && <div onClick={() => onHide(index)}>{staff.name}</div>                ))            }        </div>    )}

3.该数据是否随工夫的推移而放弃不变？如果是，那它应该也不是 state。

这条就十分好了解了，随工夫的推移而放弃不变，就是指从组件加载的时候起，到组件卸载，都是一样的值，对于这样的数据，咱们用一个常量去申明就好了，放在组件外组件内都问题不大，组件内用useMemo包裹。

// 组件Testimport React, {useState} from 'React'const writer = '蔚蓝C'export default () => {    // const writer = useMemo(() => '蔚蓝C', [])    return (        <>            <span>                {writer}            </span>        </>    )}

补充一点，用react的小伙伴应该多少对受控组件这个概念有理解（不理解的快去看文档），从我的了解简而言之就是，当组件中有数据受父级组件的管制（数据的起源和批改的形式都由父级组件提供，作为props传入），就是受控组件，反之当组件的数据齐全由本身保护，父级组件即没有提供数据也影响不了数据的变动，这样的组件是非受控组件。

这是一个十分好的概念，我感觉从了解上来说，“受控对象”的颗粒度能够细分到单个变量会更好了解，因为简单组件的状态类型往往不止一种，有从父级传递的也有本身保护的。有时候思考组件状态的时候，往往脑子里会思考这个状态是否应该受控。

react的数据传递是单向的，即从上至下传递，绝对父子组件来说，只有子组件能够是受控的，子组件须要批改父组件的数据，肯定是父组件提供给它批改数据的办法。

顺便举荐一个能够让父组件和子组件都能够管制同一个状态的hooks，阿里的hooks库——ahooks，外面的useControllableValue。

状态应该放在哪一级组件？组件本身？父组件？先人组件？

对于state状态应该放在哪一级组件，在react官网文档中，有上面两段话：

在 React 中，将多个组件中须要共享的 state 向上挪动到它们的最近独特父组件中，便可实现共享 state。这就是所谓的“状态晋升”。[3]

对于利用中的每一个 state：

  • 找到依据这个 state 进行渲染的所有组件。
  • 找到他们的独特所有者（common owner）组件（在组件层级上高于所有须要该 state 的组件）。
  • 该独特所有者组件或者比它层级更高的组件应该领有该 state。
  • 如果你找不到一个适合的地位来寄存该 state，就能够间接创立一个新的组件来寄存该 state，并将这一新组件置于高于独特所有者组件层级的地位。[2]

形容十分具体，也很好了解。因为react数据流向是单向的，兄弟组件的通信肯定是要借助父组件作为“中间层”，当兄弟组件须要用到同一个状态时，比起各自保护状态再通过父级相互告诉这样，麻烦切舍本逐末的办法当然是把组件独特状态提到最近的独特父组件中，由父组件去治理状态。

react的Context，就是层级较多的简单组件的状态治理计划，把状态提到最顶层，使每一级组件都能获取到顶层传递的数据和办法。

对于这个小标题，强烈推荐浏览React官网文档-React哲学，十分老手敌对，也适宜温习和整顿思路，我就不再赘述啦。

后记

以前我看同组大佬共事的代码，总是产生我好菜的感觉（当初也是，手动狗头），感觉我怎么就没想到代码要这么布局呢。但其实写代码的时候咱们往往不能一步到位，都是边写边思考，边随着需要改良的，比方一个简单的组件初期，是一个简略的组件，状态的传递可能也就一两层，随着封装的组件增多，层级增多，咱们又自然而然会思考应用Context... 即使是大佬也是一样哒。

文章中很多坑都是我本人亲自踩过的，我本人也有做笔记，这次整顿的内容，其实重点还是在讲述react函数组件的状态治理，怎么写代码是较为标准的，能肯定水平防止性能的节约，防止可能的隐患，像是一个申请反复执行了两次、数据交互弄得极其简单、难以保护之类的。

都是教训的分享，如果感觉有帮忙的话，心愿大家看完多点赞珍藏转发~

that's all，thank u~ 下篇文章见~

援用

[1]react源码解析7.Fiber架构

[2]React官网文档-React哲学

[2]React官网文档-React状态晋升