越陌度阡

这一讲我们将针对 React 中的设计模式进行探讨。与性能优化的视角相似，当我们谈论 React 设计模式时，实际上是在谈论“React 组件的设计模式”。在 React 设计模式中，最重要、也是最为大家所津津乐道的几个模式分别是：1. 高阶组件；2. Render Props；3. 剥离有状态组件与无状态组件

React 应用也是前端应用，如果之前你知道一些前端项目普适的性能优化手段，比如资源加载过程中的优化、减少重绘与回流、服务端渲染、启用 CDN 等，那么这些手段对于 React 来说也是同样奏效的。不过对于 React 项目来说，它有一个区别于传统前端项目的重要特点，就是以 React 组件的形式来组织逻辑：组件允许我们将 UI 拆分为独立可复用的代码片段，并对每个片段进行独立构思。

React-Router 是 React 场景下的路由解决方案，本讲我们将学习 React-Router 的实现机制，并基于此提取和探讨通用的前端路由解决方案。本着尽快进入主题的原则，这里我用一个尽可能简单的 Demo 作为引子，帮助你快速地把握 React-Router 的核心功能。

在这一讲，我们首先以 redux-thunk 中间件为例，从“异步工作流”场景切入，认识了 Redux 中间件的工作模式。随后，结合 applyMiddleware 源码，对 Redux 中间件的整个执行机制进行了细致深入的分析，并在文末引入了对“面向切面”这一编程思想的介绍。行文至此，整个由 Redux 所牵出的核心知识体系也已经一览无余地呈现在你面前，相信你对 Redux 的理解又上了一个台阶。

在上一讲，我们尝试对 Redux 源码进行拆解，认识了 Redux 源码的基本构成与主要模块，并深入了解了 createStore 这个核心模块的工作逻辑。这一讲，我们将更进一步，针对 dispatch 和 subscribe 这两个具体的方法进行分析，分别认识 Redux 工作流中最为核心的dispatch 动作，以及 Redux 自身独特的 “发布-订阅”模式。

在本讲，我们首先学习了 Redux 的架构思想，梳理了“单向数据流”这一核心特征的来龙去脉，真正理解了 Redux 定义中“可预测”这 3 个字背后的深意。随后，在复习 Redux 关键要素与工作流程的基础上，我们尝试对其源码进行拆解，认识了 Redux 源码的基本构成与主要模块，并选取了 createStore 这个核心模块作为发力点，提取出了 Redux 源码中值得我们格外深入的两个方法ubscribe 和 dispatch。

相信不少小伙伴在进阶 React 的过程中都会或多或少地了解到这样一件事情：React 有着自成一派的事件系统，它和 DOM 原生事件系统不一样。但到底哪里不一样，却很少有人能够一五一十地说清楚。开篇我们曾经说过，对于不同的知识，需要采取不同的学习策略。就 React 事件系统来说，它涉及的源码量不算小，相关逻辑也不够内聚，整体的理解成本相对较高，可能不少人都被劝退过。

双缓冲”模式其实是一种在游戏领域由来已久的经典设计模式。为了帮助你快速理解它，这里我先举一个生活中的例子：假如你去看一场总时长只有 1 个小时的话剧，这场话剧中场不休息，需要不间断地演出。按照剧情的需求，半个小时处需要一次转场。所谓转场，就是说话剧舞台的灯光、布景、氛围等全部要切换到另一种风格里去。在不中断演出的情况下，想要实现转场，怎么办呢？场务工作做得再快，也要十几二十分钟，这对一场时长 1 小时的话剧来说，实在太漫长了。观众也无法接受这样的剧情“卡顿”体验。

在上一讲我们从 beginWork 切入，摸索出了 Fiber 节点的创建链路与 Fiber 树的构建链路。本讲我们将以 completeWork 为线索，去寻觅 Fiber 树和 DOM 树之间的关联，将整个 render 阶段讲透。在此基础上，结合 commit 阶段工作流，你将会对 ReactDOM.render 所触发的渲染链路有一个完整、通透的理解。

上一讲我们对 ReactDOM.render 的调用链路、包括其对应的初始化阶段的工作内容都有了学习和掌握。这一讲我们在此基础上，学习后续的 render 阶段和 commit 阶段。这其中，render 阶段可以认为是整个渲染链路中最为核心的一环，因为我们反复强调“找不同”的过程，恰恰就是在这个阶段发生的。render 阶段做的事情有很多，这一讲我们将以 beginWork 为线索，着重探讨 Fiber 树的构建过程。拆解 ReactDOM.render 调用栈——render 阶段首先，我们

由于 ReactDOM.render 的内容比较多，所以这里拆分了上中下三讲来讲解。在上一讲，我们站在宏观角度对 Fiber 的架构分层和迭代动机有了充分的把握。从本讲开始，我们将以首次渲染为切入点，拆解 Fiber 架构下 ReactDOM.render 所触发的渲染链路，结合源码理解整个链路中所涉及的初始化、render 和 commit 等过程。ReactDOM.render 调用栈的逻辑分层开篇先给到你一个简单的 React AppDemo：import React from "r

在理解 Fiber 架构之前，我们先来看看 React 团队在“React 哲学”中对 React 的定位：我们认为，React 是用 JavaScript 构建快速响应的大型 Web 应用程序的首选方式。它在 Facebook 和 Instagram 上表现优秀。这段话里有 4 个字值得我们细细品味，那就是“快速响应”，这 4 个字可以说是 React 团队在用户体验方面最为要紧的一个追求。关于这点，在 React 15 时代已经可见一斑：正是出于对“快速响应”的执着，React 才会想方设法

setState 对于许多的 React 开发者来说，像是一个“最熟悉的陌生人”：1.当你入门 React 的时候，接触的第一波 API 里一定有 setState——数据驱动视图，没它就没法创造变化；2.当你项目的数据流乱作一团的时候，层层排查到最后，始作俑者也往往是 setState——工作机制太复杂，文档又不说清楚，只能先“摸着石头过河”。久而久之，setState 的工作机制渐渐与 React 调和算法并驾齐驱，成了 React 核心原理中区分度最高的知识模块之一。本讲我们就紧贴 R..

时下 React 16 乃至 React 17 都是业界公认的“当红炸子鸡”，相比之下 React 15 似乎已经是一副黯淡无光垂垂老矣的囧相了。在这样的时代背景下，愿意自动自发地了解 React 15 的人越来越少，这是一个令人心碎的现象。毕竟有位伟人曾经说过，“以史为镜，可以知兴替”；还有另一位伟人曾经说过，“学习知识需要建立必要且完整的上下文”——如果我们不清楚 React 15 的运作机制，就无从把握它的局限性；如果我们不能确切地把握 React 15 的局限性，就无法从根本上理解 React

在过去的十年里，前端技术日新月异。从最早的纯静态页面，到 jQuery 一统江湖，再到近几年大火的 MVVM 框架——研发模式升级这件事情对于前端来说，好像成了某种常态。其实研发模式不断演进的背后，恰恰蕴含着前端人对 “DOM 操作” 这一核心动作的持续思考和改进。而虚拟 DOM，正是先驱们在这个过程中孕育出的一颗明珠。在 MVVM 框架这个领域分支，有一道至今仍然非常经典的面试题：“为什么我们需要虚拟 DOM？”。这个问题比较常见的回答思路是：“DOM 操作是很慢的，而 JS 却可以很快，直接操作

React 团队面向开发者给出了两条 React-Hooks 的使用原则，原则的内容如下：1.只在 React 函数中调用 Hook；2.不要在循环、条件或嵌套函数中调用 Hook。原则 1 无须多言，React-Hooks 本身就是 React 组件的“钩子”，在普通函数里引入意义不大。我相信更多的人在原则 2 上栽过跟头，或者说至今仍然对它半信半疑。其实，原则 2 中强调的所有“不要”，都是在指向同一个目的，那就是要确保 Hooks 在每次渲染时都保持同样的执行顺序。为什么顺序如此重..

经过第 6 课时的学习，相信你已经清楚了 React-Hooks 的来头，并理解了其背后的“设计动机”。本课时我们的任务是构建对 React-Hooks 的整体认知。在本课时的主体部分，我将通过一系列的编码实例来帮助你认识 useState、useEffect 这两个有代表性的 Hook，这一步意在帮助初学者对 React-Hooks 可以快速上手。在此基础上，我们将重新理解“Why React-Hooks”这个问题。在课时的最后，我将结合自身的开发体验，和你分享当下这个阶段，我所认识到的 Hooks

从本课时开始，我们将逐步进入 React-Hooks 的世界。在动笔写 React-Hooks 之前，我发现许多人对这块的知识非常不自信，至少在面试场景下，几乎没有几个人在聊到 React-Hooks 的时候，能像聊 Diff 算法、Fiber 架构一样滔滔不绝、言之有物。后来我仔细反思了一下，认为问题应该出在学习姿势上。提起 React-Hooks，可能很多人的第一反应，都会是 useState、useEffect、useContext 这些琐碎且繁多的 API。似乎 React-Hooks 就是

在上个课时，我们掌握了 React 数据流方案中风格相对“朴素”的 Props 单向数据流方案，以及通用性较强的“发布-订阅”模式。在本课时，我们将一起认识 React 天然具备的全局通信方式“Context API”，并对 Redux 的设计思想和编码形态进行初步的探索。使用 Context API 维护全局状态Context API 是 React 官方提供的一种组件树全局通信的方式。在 React 16.3 之前，Context API 由于存在种种局限性，并不被 React 官方提倡使用

通过前面 3 个课时的学习，相信你已经对 React 生命周期相关的“Why”“What”和“How”有了系统的理解和掌握。当我们谈论生命周期时，其实谈论的是组件的“内心世界”。但组件和人是一样的，它不仅需要拥有丰富的内心世界，还应该建立健全的“人际关系”，要学会沟通和表达。从本课时开始，我们将一起探索蕴含在 React 组件中的“沟通与表达”的艺术。我们知道，React 的核心特征是“数据驱动视图”，这个特征在业内有一个非常有名的函数式来表达：这个表达式有很多的版本，一些版本会把入参里的 da

通过对上一个课时的学习，你已经对 React 15 的生命周期有了系统的掌握和理解。本课时，我将在此基础上，对 React 16 以来的生命周期进行剖析。在理解“是什么”的基础上，我将带你对比新旧两个版本生命周期之间的差异，并探寻变化背后的原因。通过本课时的学习，你将明白 React 团队“动作频频”背后的思量与野心，同时也将对时下大热的 Fiber 架构形成初步的认知。进化的生命周期方法：React 16 生命周期工作流详解关于 React 16 以来的生命周期，这个民间开源项目为我们提供了目

React 生命周期已经是一个老生常谈的话题了，几乎没有哪一门 React 入门教材会省略对组件生命周期的介绍。然而，入门教材在设计上往往追求的是“简单省事、迅速上手”，这就导致许多同学对于生命周期知识的刻板印象为“背就完了、别想太多”。“背就完了”这样简单粗暴的学习方式，或许可以帮助你理解“What to do”，到达“How to do”，但却不能帮助你去思考和认知“Why to do”。作为一个专业的 React 开发者，我们必须要求自己在知其然的基础上，知其所以然。在本课时和下一个课时，我将

时下虽然接入 JSX 语法的框架越来越多，但与之缘分最深的毫无疑问仍然是 React。2013 年，当 React 带着 JSX 横空出世时，社区曾对 JSX 有过不少的争议，但如今，越来越多的人面对 JSX 都要说上一句“真香”！本课时我们就来一起认识下这个“真香”的 JSX，聊一聊“JSX 代码是如何‘摇身一变’成为 DOM 的”。关于 JSX 的 3 个“大问题”在日常的 React 开发工作中，我们已经习惯了使用 JSX 来描述 React 的组件内容。关于 JSX 语法本身，相信每位 Re