关于react.js:重学-react

重学 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 大佬用心写的文档，让小编重新认识了 本人的无知。

最初欢送关注一波：

以上。