重学 react

简介

换工作后，从vue转react曾经一年半了，代码写的不多，幸运认为对react有点相熟了。但看了「beta.reactjs.org」后仍然有被震撼到，对react，本人之前的了解，原来始终都错的离谱。

明天，小编就讲讲了解react组件的心路历程，以及清空本身固有认知，尝试为将来的应用，构建一个不容易但简略的心智模型：

  1. 构建react组件的根本心智模型
  2. 构建useEffect的根本心智模型
  3. 自我反思
申明：本文是集体的官网文档「beta.reactjs.org」读后感，并不保障源码剖析级别的严谨性，将来仍然会一直调整，举荐大家有工夫本人去读一遍文档。「原文档略啰嗦，但整体还是晦涩易读的」。

构建react组件的根本心智模型

家喻户晓，react是围绕vdom和dom diff设计的，更新fiber架构后，也没有扭转。小编对react组件（为了简化，这里跳过曾经不值一提的class component，指的都是函数式组件）的了解始终是有许多疑难的：

初见，UI=f(state)简洁而柔美的近乎「零」api公式，优雅，太优雅了！看起来当前始终能够这么优雅的写代码了？

如果没有相似immer等库的帮忙，必须不厌其烦的手动开展Object和Array等常见援用类型，以达到给react组件投喂不可变数据的成果，「优雅的背地果然总少不了负重前行的实现」。

再见已翻看过dan经典的博文「overreacted.io/zh-hans/algebraic-effects-for-the-rest-of-us」，读后让人感到释怀，react组件留给小编的纳闷，果然并非是不是纯函数？这么简略。

react组件是用「屡次一直执行组件的关联函数」的形式，做到了以「同步代码的模式」实现「异步中断和复原的」的成果（被称之为代数效应）。有相似async函数的性能，却没有async函数传染性的毛病，不是异步，胜似异步！

回眸文档后，意识到react组件也不仅是代数效应这么简略，而是fiber树的地位和fiber树的diff后果紧密结合的产物。

即，react组件通过「屡次执行」的形式：

  • 实现了「零」api 形象，每次执行都被传递到其并不优雅的外部体系中，小编目前认为，这个纯函数带上各种束缚，其实是一个内置 DSL。
  • 实现了「纯」函数形象，所以得手动放弃不可变。
  • 实现了更多其余非凡能力形象，代数效应、状态治理、异步任务调度等
  • 实现了基于diff规定的主动状态治理，要认真考量状态是否还能放弃。
PS: 小编开始对用react来实现「所有皆组件的思维」产生了一丝丝狐疑，因为react组件曾经是一个深度定制的零碎的内置 DSL，要以一个根底单元的模式，再去撑持其余维度的形象零碎有点重了，这点从react-router六大版本的变迁能够看出端倪。

构建useEffect的根本心智模型

小编对hooks的了解同样经验了几个阶段：

开始也是被优雅、简洁给惊艳，以至于对「不能在if中应用」等顺当的规定，感觉十分能够了解。这时候小编仅认为他是一个更聚合的组织代码的形式。

起初有人说hooks实质是一种reactive，坚信了许久，于是小编去钻研了很多reactive库，在遇见了solidjs之后感慨万千，vdom的路子跟十年前爆火的reactive思维比起来，在形象水平、性能和包大小方面都没有什么劣势，然而react曾经无奈走回头路了，最终小编的论断是，hooks和reactive不是间接关系，不应强行关联。

react组件是通过一直反复执行以取得超能力非凡能力的。所以配合上hooks保留状态的个性，整个函数体内申明的、所有的自在变量自然而然的，都领有了reactive的个性了。

无论是否是useState包裹的变量，还是props，甚至一句一般的const b = a + 1，也人造成为了reactive，能够解读为a + 1的computed映射函数b的申明，所以不只是hooks才reactive。

最初，即然不是以reactive为目标设计，那么为啥useEffect要取这么一个名字呢？为啥dev阶段react非要「歹意」触发两次useEffect呢？

从新文档中小编取得了答案，useEffect本名其实应该是useImmutableReactiveAfterEveryRenderDangerEffect，解释为「用于不可变的、响应式的、危险的、react组件本身渲染前期的副作用」。小编取这样一个超级长的名字是符合官网，不激励多用、也避免大家滥用这个hooks。

Immutable和Reactive下面曾经解释过了，AfterEveryRenderDangerEffect指的是组件被提交到渲染之后，能够自定义的行为，比方你想要组件一旦渲染后：

  1. 发送一个申请。
  2. 上报一个日志。
  3. 注册一个零碎事件。

总之，只有在渲染后的这个机会内，须要一个「主动」解决「官网用词是同步」一下以后react组件和组件内部资源的危险的副作用的机制的时候，才不得不应用。大部分时候，你须要的被动解决逻辑都应该放在event callback中，当初，是否感觉本人滥用了呢？

  • 因为每个useEffect的性能、依赖的更新频率、设计目标都不雷同，必须拆分大的useEffect为繁多性能的多个小useEffect，能力避免更多的凌乱。
  • 而「歹意」触发两次useEffect，是为了凸显遗记设置cleanup返回函数的危险性。

one more thing还有一个暗藏特地深的陷阱不得不提。你是否常常遇到，因为要实现某些性能，不得不给他增加设计之初以外的依赖，否则lint 规定就又无奈通过了。

「lint 只会主动疏忽组件内部的上下文变量、不可变的函数等，」手动疏忽lint显著是一个走向失控的不负责的解决形式。那么，不突破设计用意还有哪些可控的解决办法呢？

  1. 把状态移出组件，或者移入useImmutableReactiveAfterEveryRenderDangerEffect外部。
  2. 利用setState(v => ...)的形式传入函数，以去除依赖数组中的reactive变量。
  3. 抽离一个non-reactive effectFn函数「最新的useEvent api正是来自于此」，由这个函数去上下文从新捕捉reactive变量，也能够去除依赖数组中的reactive变量。
  4. 「文档正告」non-reactive effectFn函数是useImmutableReactiveAfterEveryRenderDangerEffect独有的作用域透露补丁计划，也请不要滥用。只能由对应的useImmutableReactiveAfterEveryRenderDangerEffect在外部调用，也不许传递给其余的hooks！

自我反思

原本还想写写re-render的心智模型，然而发现re-render的实践，其实业界聊得挺透彻，没啥新货色可说了，只是做的还不够好「共勉」。

小编发现以喷子的角色去吐槽FE的生态破绽，播种的只有失落感，因为尽管意识到痛点和有余，却只能口嗨，无奈去正确形容、正视并解决问题。这次读新文档，让人有一种解惑后的满足感，再感激dan大佬用心写的文档，让小编重新认识了本人的无知。

最初欢送关注一波：

以上。