共计 2960 个字符，预计需要花费 8 分钟才能阅读完成。
重学 react
简介
换工作后，从 vue 转react曾经一年半了，代码写的不多，幸运认为对 react 有点相熟了。但看了「beta.reactjs.org」后仍然有被震撼到，对react，本人之前的了解，原来始终都错的离谱。
明天，小编就讲讲了解 react 组件的 心路历程 ，以及清空本身固有认知，尝试为将来的应用，构建一个 不容易但简略的 心智模型：
- 构建
react组件的根本心智模型 - 构建
useEffect的根本心智模型 - 自我反思
申明：本文是集体的官网文档「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指的是组件被提交到渲染之后，能够自定义的行为，比方你想要组件一旦渲染后：
- 发送一个申请。
- 上报一个日志。
- 注册一个零碎事件。
总之，只有在 渲染后 的这个机会内，须要一个「主动」解决「官网用词是 同步 」一下以后react 组件和 组件内部资源 的危险的 副作用的机制的时候，才不得不应用。大部分时候，你须要的被动解决逻辑都应该放在 event callback 中，当初，是否感觉本人 滥用 了呢？
- 因为每个
useEffect的性能、依赖的更新频率、设计目标都不雷同，必须拆分 大的useEffect为繁多性能的多个小useEffect，能力避免更多的凌乱。 - 而「歹意」触发两次
useEffect，是为了凸显遗记设置cleanup返回函数的危险性。
one more thing还有一个暗藏特地深的陷阱不得不提。你是否常常遇到，因为要实现某些性能，不得不给他增加 设计之初以外的依赖，否则lint 规定就又无奈通过了。
「lint 只会 主动 疏忽 组件内部的 上下文变量、不可变的 函数等，」手动疏忽 lint 显著是一个走向 失控 的不负责的解决形式。那么，不突破 设计用意 还有哪些 可控的 解决办法呢？
- 把状态移出组件，或者移入
useImmutableReactiveAfterEveryRenderDangerEffect外部。 - 利用
setState(v => ...)的形式传入函数，以去除依赖数组中的reactive变量。 - 抽离一个
non-reactive effectFn函数「最新的useEvent api正是来自于此」，由这个函数去上下文从新捕捉reactive变量，也能够去除依赖数组中的reactive变量。 - 「文档正告」
non-reactive effectFn函数是useImmutableReactiveAfterEveryRenderDangerEffect独有的作用域透露补丁计划，也请不要滥用。只能由对应的useImmutableReactiveAfterEveryRenderDangerEffect在外部调用，也不许传递给其余的hooks！
自我反思
原本还想写写 re-render 的心智模型，然而发现 re-render 的实践，其实业界聊得挺透彻，没啥新货色可说了，只是做的还不够好「共勉」。
小编发现以 喷子 的角色去吐槽 FE 的生态 破绽 ，播种的只有 失落感 ，因为尽管意识到痛点和有余，却只能口嗨，无奈去正确形容、正视并解决问题。这次读新文档，让人有一种解惑后的 满足感 ，再感激dan 大佬用心写的文档，让小编重新认识了 本人的无知。
最初欢送关注一波：
以上。
