React.js on Last Stand

JSX

Tue, 17 Dec 2024 00:00:00 +0800

时下虽然接入 JSX 语法的框架越来越多，但与之缘分最深的毫无疑问仍然是 React。

2013 年，当 React 带着 JSX 横空出世时，社区曾对 JSX 有过不少的争议，但如今，越来越多的人面对 JSX 都要说上一句“真香”！我们就来一起认识下这个“真香”的 JSX，聊一聊“JSX 代码是如何‘摇身一变’成为 DOM 的”。

开始之前请先思考几个问题：

JSX 的本质是什么，它和 JS 之间到底是什么关系？
为什么要用 JSX？不用会有什么后果？
JSX 背后的功能模块是什么，这个功能模块都做了哪些事情？

面对以上问题，如果无法形成清晰且系统的思路，那么很可能是把 JSX 想得过于简单了。大多数人只是简单地把它理解为模板语法的一种，但事实上，JSX 作为 React 框架的一大特色，它与 React 本身的运作机制之间存在着千丝万缕的联系，上述 3 个问题的答案，就恰恰隐藏在这层“联系”中。

JSX 的本质：JavaScript 的语法扩展

JSX 到底是什么?看看 React 官网给出的一段定义：

JSX 是 JavaScript 的一种语法扩展，它和模板语言很接近，但是它充分具备 JavaScript 的能力。

“语法扩展”这一点在理解上几乎不会产生歧义，不过“它充分具备 JavaScript 的能力”这句，却总让人摸不着头脑，JSX 和 JS 怎么看也不像是“一路人”啊？这就引出了“JSX 语法是如何在 JavaScript 中生效的”这个问题。

JSX 语法是如何在 JavaScript 中生效的：认识 Babel

Facebook 公司给 JSX 的定位是 JavaScript 的“扩展”，而非 JavaScript 的“某个版本”，这就直接决定了浏览器并不会像天然支持 JavaScript 一样地支持 JSX。那么，JSX 的语法是如何在 JavaScript 中生效的呢？React 官网其实早已给过我们线索：

元素、组件、实例和节点

Tue, 17 Dec 2024 00:00:00 +0800

React 中的元素、组件、实例和节点，是React中关系密切的4个概念，也是很容易让React 初学者迷惑的4个概念。现在，老干部就来详细地介绍这4个概念，以及它们之间的联系和区别，满足喜欢咬文嚼字、刨根问底的同学（老干部就是其中一员）的好奇心。

元素 (Element)

React 元素其实就是一个简单JavaScript对象，一个React 元素和界面上的一部分DOM对应，描述了这部分DOM的结构及渲染效果。一般我们通过JSX语法创建React 元素，例如：

const element = <h1 className='greeting'>Hello, world</h1>;

element是一个React 元素。在编译环节，JSX 语法会被编译成对React.createElement()的调用，从这个函数名上也可以看出，JSX语法返回的是一个React 元素。上面的例子编译后的结果为：

const element = React.createElement(
 'h1',
 {className: 'greeting'},
 'Hello, world!'
);

最终，element的值是类似下面的一个简单JavaScript对象：

const element = {
 type: 'h1',
 props: {
 className: 'greeting',
 children: 'Hello, world'
 }
}

React 元素可以分为两类：DOM类型的元素和组件类型的元素。DOM类型的元素使用像h1、div、p等DOM节点创建React 元素，前面的例子就是一个DOM类型的元素；组件类型的元素使用React 组件创建React 元素，例如：

const buttonElement = <Button color='red'>OK</Button>;

buttonElement就是一个组件类型的元素，它的值是：

const buttonElement = {
 type: 'Button',
 props: {
 color: 'red',
 children: 'OK'
 }
}

对于DOM类型的元素，因为和页面的DOM节点直接对应，所以React知道如何进行渲染。但是对于组件类型的元素，如buttonElement，React是无法直接知道应该把buttonElement渲染成哪种结构的页面DOM，这时就需要组件自身提供React能够识别的DOM节点信息，具体实现方式在介绍组件时会详细介绍。

有了React 元素，我们应该如何使用它呢？其实，绝大多数情况下，我们都不会直接使用React 元素，React 内部会自动根据React 元素，渲染出最终的页面DOM。更确切地说，React元素描述的是React虚拟DOM的结构，React会根据虚拟DOM渲染出页面的真实DOM。

组件 (Component)

React 组件，应该是大家最熟悉的React中的概念。React通过组件的思想，将界面拆分成一个个可以复用的模块，每一个模块就是一个React 组件。一个React 应用由若干组件组合而成，一个复杂组件也可以由若干简单组件组合而成。

React组件和React元素关系密切，React组件最核心的作用是返回React元素。这里你也许会有疑问：React元素不应该是由React.createElement() 返回的吗？但React.createElement()的调用本身也是需要有“人”负责的，React组件正是这个“责任人”。React组件负责调用React.createElement()，返回React元素，供React内部将其渲染成最终的页面DOM。

既然组件的核心作用是返回React元素，那么最简单的组件就是一个返回React元素的函数：

function Welcome(props) {
 return <h1>Hello, {props.name}</h1>;
}

Welcome是一个用函数定义的组件。如果使用类（class）定义组件，返回React元素的工作具体就由组件的render方法承担，例如：

state 与 props

Tue, 17 Dec 2024 00:00:00 +0800

state

基本定义

state是组件内部的状态（数据），不能够直接修改，必须要通过setState来改变值的状态，从而达到更新组件内部数据的作用。

props

基本定义

props是指组件间传递的一种方式，props自然也可以传递state。由于React的数据流是自上而下的，所以是从父组件向子组件进行传递；另外组件内部的this.props属性是只读的不可修改。

代码示例

// 父组件
import stateJj from './stateJj.js'; // 引入子组件
class stateJjFather extends React.Component {
 constructor(props) {
 super(props);
 // 设置state的默认值 且只能在constructor中设置
 this.state = {
 mes: '给子组件的信息',
 obj： {

 },
 arr: []
 }
 }
 fun(e) {

 }
 render() {
 const {mes, obj, arr} = this.state;
 return (
 <div>
 // 不写箭头函数 this指向会发生错误 也可以使用bind的方式绑定this
 <stateJj name={'给子组件的信息'} name1={mes} fun={(e) => this.fun(e)} obj={obj} arr={arr} />
 </div>
 );
 }
}
// 子组件
class stateJj extends React.Component {
 constructor(props) {
 super(props);
 this.props; // 这里面就有父组件传的值
 // 设置 默认state
 this.state = {
 text: props.initialValue || 'placeholder'
 };

 // ES6 类中函数必须手动绑定
 this.handleChange = this.handleChange.bind(this);
 }

 handleChange(event) {
 this.setState({
 text: event.target.value
 });
 }

 render() {
 return (
 <div>
 {mes}
 </div>
 );
 }
}
// 设置props值的类型
stateJj.propTypes = {
 optionalArray: PropTypes.array,
 optionalBool: PropTypes.bool,
 optionalFunc: PropTypes.func,
 optionalNumber: PropTypes.number,
 optionalObject: PropTypes.object,
 optionalString: PropTypes.string,
 optionalSymbol: PropTypes.symbol, // 目前可以声明的所有变量类型
};
// 设置默认的props值
stateJj.defaultProps = {
};

props的特性

只读性

props经常被用作渲染组件和初始化状态，当一个组件被实例化之后，它的props是只读的，不可改变的。如果props在渲染过程中可以被改变，会导致这个组件显示的形态变得不可预测。只有通过父组件重新渲染的方式才可以把新的props传入组件中。

React 生命周期

Tue, 17 Dec 2024 00:00:00 +0800

简介

React从v16.3的版本开始，对生命周期的钩子进行了渐进式的调整，分别废弃和新增了一些生命周期的钩子函数，本文会从以下四点开始讲解：

新旧生命周期函数的对比
分析为什么要废弃旧的钩子函数
详解新的生命周期使用场景
实例代码演示并进行总结

新旧生命周期对比

一个完整的React组件生命周期会依次调用如下钩子：

old lifecycle

挂载

constructor
componentWillMount
render
componentDidMount

更新

componentWillReceiveProps
shouldComponentUpdate
componentWillUpdate
render
componentDidUpdate

卸载

componentWillUnmount

new lifecycle

挂载
- constructor
- getDerivedStateFromProps
- render
- componentDidMount
更新
- getDerivedStateFromProps
- shouldComponentUpdate
- render
- getSnapshotBeforeUpdate
- componentDidUpdate
卸载
- componentWillUnmount

从以上生命周期的对比，我们不难看出，React从v16.3开始废弃 componentWillMount componentWillReceiveProps componentWillUpdate 三个钩子函数

分析废弃原因

Facebook花了两年多的时间搞出了React Fiber, 因为在v15的版本，更新过程是同步的，往往一个主线程长时间被占用，会导致页面性能问题

而 React Fiber的机制: 利用浏览器 requestIdleCallback 将可中断的任务进行分片处理，每一个小片的运行时间很短，这样唯一的线程就不会被独占

需要详细了解可以点下面链接 Morgan大佬 - 知乎

那么React Fiber会对生命周期带来什么影响吗？

因为React Fiber Reconciliation 这个过程有可能暂停然后继续执行，所以挂载和更新之前的生命周期钩子就有可能不执行或者多次执行；

目前React为这几个生命周期钩子提供了别名，分别是：

UNSAFE_componentWillMount
UNSAFE_componentWillReceiveProps
UNSAFE_componentWillUpdate

React17将只提供别名，取个别名的目的就是恶心你，不让你使用。

react hooks

Tue, 17 Dec 2024 00:00:00 +0800

一前言

React hooks是react16.8 以后，react新增的钩子API，目的是增加代码的可复用性，逻辑性，弥补无状态组件没有生命周期，没有数据管理状态state的缺陷。

本章节将介绍目前 React 提供的所有 hooks ，介绍其功能类型和基本使用方法。

1.1 技术背景

react hooks 解决了什么问题？

先设想一下，如果没有 Hooks，函数组件能够做的只是接受 Props、渲染 UI ，以及触发父组件传过来的事件。所有的处理逻辑都要在类组件中写，这样会使 class 类组件内部错综复杂，每一个类组件都有一套独特的状态，相互之间不能复用，即便是 React 之前出现过 mixin 等复用方式，但是伴随出 mixin 模式下隐式依赖，代码冲突覆盖等问题，也不能成为 React 的中流砥柱的逻辑复用方案。所以 React 放弃 mixin 这种方式。

类组件是一种面向对象思想的体现，类组件之间的状态会随着功能增强而变得越来越臃肿，代码维护成本也比较高，而且不利于后期 tree shaking。所以有必要做出一套函数组件代替类组件的方案，于是 Hooks 也就理所当然的诞生了。

所以 Hooks 出现本质上原因是：

让函数组件也能做类组件的事，有自己的状态，可以处理一些副作用，能获取 ref ，也能做数据缓存。
解决逻辑复用难的问题。
放弃面向对象编程，拥抱函数式编程。

为什么要使用自定义 Hooks ？

自定义 hooks 是在 React Hooks 基础上的一个拓展，可以根据业务需求制定满足业务需要的组合 hooks ，更注重的是逻辑单元。通过业务场景不同，到底需要React Hooks 做什么，怎么样把一段逻辑封装起来，做到复用，这是自定义 hooks 产生的初衷。

自定义 hooks 也可以说是 React Hooks 聚合产物，其内部有一个或者多个 React Hooks 组成，用于解决一些复杂逻辑。

Context API

Tue, 17 Dec 2024 00:00:00 +0800

先看看React官网对于Context的介绍

Context 提供了一个无需为每层组件手动添加 props，就能在组件树间进行数据传递的方法。在一个典型的 React 应用中，数据是通过 props 属性自上而下（由父及子）进行传递的，但这种做法对于某些类型的属性而言是极其繁琐的（例如：地区偏好，UI 主题），这些属性是应用程序中许多组件都需要的。Context 提供了一种在组件之间共享此类值的方式，而不必显式地通过组件树的逐层传递 props。

个人理解转成大白话：Context提供了一个局部的全局作用域，使用Context则无需再手动的逐层传递props。

本文主要介绍3种Context的使用方式：

React.createContext提供的Provider和Consumer
函数组件：React.createContext提供的Provider和useContext钩子
Class组件：React.createContext提供的Provider和class的contextType属性

第一种：React.createContext提供的Provider和Consumer

先写好使用Context的基础环境条件，后续的代码都是基于此环境

//创建一个文件，暂且命名为context.js，导出createContext()的返回值
import { createContext } from "react";

export default createContext();

在根组件App.jsx中，导入上面写的context，并使用context提供的Provider组件进行包裹，圈定局部的全局作用域，传值后可以提供给子组件进行消费

当 Provider 的 value 值发生变化时，它内部的所有消费组件都会重新渲染。Provider 及其内部 consumer 组件都不受制于 shouldComponentUpdate 函数，因此当 consumer 组件在其祖先组件退出更新的情况下也能更新。

import React, { createContext } from "react";
import MyContext from "./context";

import GeneralC from "./GeneralC";
import FnC from "./FnC";
import ClassC from "./ClassC";

export default function App() {
 return (
 //Provider组件接收一个value属性，此处传入一个带有name属性的对象
 <MyContext.Provider value={{ name: `context's value is string!` }}>
 {/*这里写后面要进行包裹的子组件,此处先行导入后续需要消费context的3个组件*/}
 <GeneralC/>
 <hr/>
 <FnC/>
 <hr/>
 <ClassC/>
 </MyContext.Provider>
 );
}

在GeneralC组件中,导入context,使用其提供的Consumer组件来订阅Context的变更,需要一个函数作为子元素,函数的第一个形参便是Provider组件提供的value值

import React, { useReducer } from "react";
import MyContext from "./context";

const GeneralC = () => {
 return (
 //
 <MyContext.Consumer>
 {(value) => {
 return (
 <div>
 第一种使用Context方式获取的值：{JSON.stringify(value)}
 </div>
 );
 }}
 </MyContext.Consumer>
 );
};

export default GeneralC;

此时页面中应该出现json格式的value值

条件渲染的常见方法和注意事项

Tue, 17 Dec 2024 00:00:00 +0800

条件渲染方式

1. if 语句

先从 React 最基本的条件类型来看。如果有数据就显示组件，如果没有数据就不显示任何内容。posts 为需要渲染的列表：

export default function App() {
  const { posts } = usePosts();

  if (!posts) return null;

  return (
    <div>
      <PostList posts={posts} />
    </div>
  );
}

这种形式会生效的原因就是我们会提前返回，如果满足条件（posts 值不存在），就通过return null 在组件中不显示任何内容。

如果有多个要检查的条件时，也可以使用 if 语句。例如，在显示数据之前检查加载和错误状态：

export default function App() {
  const { isLoading, isError, posts } = usePosts();
   
  if (isLoading) return <div>Loading...</div>;
  if (isError) return <div>Error!</div>;

  return (
    <div>
      <PostList posts={posts} />
    </div>
  );
}

这里我们可以多次使用 if 语句，不需要再使用 else 或者 if-eles 语句，这样就减少了需要编写的代码，并且可读性更强。

2. 三元运算符

当我们想提前退出或者什么都不显示时，if 语句会很有用。但是，如果我们不想写一个与返回的 JSX 分开的条件，而是直接在其中写呢？那就可以使用三元表达式来编写条件。

在 React 中，我们必须在 JSX 中包含表达式，而不是语句。这就是为什么我们在 JSX 中只能使用三元表达式，而不是 if 语句来编写条件。

列表和key

Tue, 17 Dec 2024 00:00:00 +0800

当我们在 React 要渲染一个列表时，如果没有在每一个被渲染的元件加上 key 这个 prop，就会跳出 Warning: Each child in a list should have a unique “key” prop. 这个错误讯息。直到开发者把 key 加上后，这个警告讯息才会消失。为什么要加上 key? 以及 key 有什么原则需要遵守? 这是在开发 React 时需要有的重要概念，也是面试经常会问的基础题。

为什么需要 key？

key 就像一个独特身份，让 React 可以去分辨哪些子元件被新增、移除，或是修改。 (编按：若要进一步说明此概念，推荐在面试时画下 Dan Abramov 的这个系列推文例子)

从上面的例子可以看到，当今天红黄蓝三个圈，变成红蓝黄；这会有两个可能性。可能性一第二个圈跟第三个圈的位置互换；可能性二是位置没互换，但第二个圈变蓝色、第三个圈变黄色。如果没有一个独特辨识的机制，我们会没办法知道，究竟是哪一个可能性。

如果没办法有效辨识，将可能出现 bug。举例来说，假如今天的圈圈是有状态的，例如里面有勾选方块，然后第个二圈有被勾选。假如今天换颜色是因为第二个圈被交换到第三个位置，这时表示新一次的渲染时，第三个圈要是被勾选的。不过假如我们没有一个辨识机制，要是 React 误以为换颜色不是因为换位置，而是单纯的第二个圈换颜色，那么将会渲染出仍是第二个圈是被勾选的；那么这就会是一个 bug。

然而，有了 key 这个辨识机制，React 就会知道在新的一次渲染时，原本的状态应该被保留在列表中的哪一个元件中。因此，React 之所以需要 key，正是因为 key 可以让 React 知道，哪些子元件被新增、移除，或是修改。

除此之外，看到下面这段 React 官方文件的例子 (编按：面试时也推荐直接举这例子)。原本有个列表，我们在最上方新增一个 <li>Connecticut</li> ，如果没有 key，对 React 来说将会是，Duke 变成 Connecticut、Villanova 变成 Duke，而最后新增一个 Villanova。换句话说，整个列表都改变了，所以 React 会打掉旧的，重建一个新的列表。当列表变大时，就会很消耗效能。

react 事件机制

Tue, 17 Dec 2024 00:00:00 +0800

一前言

我们来一起探讨一下React事件原理，这篇文章，我尽量用通俗简洁的方式，把React事件系统讲的明明白白。

我们讲的react版本是16.13.1 , v17之后react对于事件系统会有相关的改版，文章后半部分会提及。

老规矩，在正式讲解react之前，我们先想想这几个问题(如果我是面试官，你会怎么回答?)：

我们写的事件是绑定在dom上么，如果不是绑定在哪里？
为什么我们的事件不能绑定给组件？
为什么我们的事件手动绑定this(不是箭头函数的情况)
为什么不能用 return false 来阻止事件的默认行为？
react怎么通过dom元素，找到与之对应的 fiber对象的？
onClick是在冒泡阶段绑定的？那么onClickCapture就是在事件捕获阶段绑定的吗？

必要的知识概念

在弄清楚react事件之前，有几个概念我们必须弄清楚，因为只有弄明白这几个概念，在事件触发阶段，我们才能更好的理解react处理事件本质。

我们写在JSX事件终将变成什么？

我们先写一段含有点击事件的react JSX语法，看一下它最终会变成什么样子？

class Index extends React.Component{
 handerClick= (value) => console.log(value)
 render(){
 return <div>
 <button onClick={ this.handerClick } > 按钮点击 </button>
 </div>
 }
}

经过babel转换成React.createElement形式，如下：

最终转成fiber对象形式如下：

fiber对象上的memoizedProps 和 pendingProps保存了我们的事件。

什么是合成事件？

通过上一步我们看到了，我们声明事件保存的位置。但是事件有没有被真正的注册呢？我们接下来看一下：

我们看一下当前这个元素<button>上有没有绑定这个事件监听器呢？

button上绑定的事件

我们可以看到，button上绑定了两个事件，一个是document上的事件监听器，另外一个是button，但是事件处理函数handle，并不是我们的handerClick事件，而是noop。

noop是什么呢？我们接着来看。

原来noop就指向一个空函数。

然后我们看document绑定的事件

可以看到click事件被绑定在document上了。

接下来我们再搞搞事情😂😂😂，在demo项目中加上一个input输入框，并绑定一个onChange事件。睁大眼睛看看接下来会发生什么？

class Index extends React.Component{
 componentDidMount(){
 console.log(this)
 }
 handerClick= (value) => console.log(value)
 handerChange=(value) => console.log(value)
 render(){
 return <div style={{ marginTop:'50px' }} >
 <button onClick={ this.handerClick } > 按钮点击 </button>
 <input placeholder="请输入内容" onChange={ this.handerChange } />
 </div>
 }
}

我们先看一下input dom元素上绑定的事件

受控组件和非受控组件

Tue, 17 Dec 2024 00:00:00 +0800

前端开发经常会涉及表单的处理，或者其他一些用于输入的组件，比如日历组件。

涉及到输入，就绕不开受控模式和非受控模式的概念。

什么是受控，什么是非受控呢？

想一下，改变表单值只有两种情况：

用户去改变 value 或者代码去改变 value。

如果不能通过代码改表单值 value，那就是非受控，也就是不受我们控制。

但是代码可以给表单设置初始值 defaultValue。

代码设置表单的初始 value，但是能改变 value 的只有用户，代码通过监听 onChange 来拿到最新的值，或者通过 ref 拿到 dom 之后读取 value。

这种就是非受控模式。

反过来，代码可以改变表单的 value，就是受控模式。

注意，value 和 defaultValue 不一样：

defaultValue 会作为 value 的初始值，后面用户改变的是 value。

而一旦你给 input 设置了 value，那用户就不能修改它了，可以输入触发 onChange 事件，但是表单的值不会变。

用户输入之后在 onChange 事件里拿到输入，然后通过代码去设置 value。

这就是受控模式。

其实绝大多数情况下，非受控就可以了，因为我们只是要拿到用户的输入，不需要手动去修改表单值。

但有的时候，你需要根据用户的输入做一些处理，然后设置为表单的值，这种就需要受控模式。

或者你想同步表单的值到另一个地方的时候，类似 Form 组件，也可以用受控模式。

value 由用户控制就是非受控模式，由代码控制就是受控模式。

我们写代码试一下：

npx create-vite

创建 vite + react 的项目。

去掉 main.tsx 的 index.css 和 StrictMode：

高阶组件

Tue, 17 Dec 2024 00:00:00 +0800

一前言

React高阶组件(HOC)，对于很多react开发者来说并不陌生，它是灵活使用react组件的一种技巧，高阶组件本身不是组件，它是一个参数为组件，返回值也是一个组件的函数。

高阶作用用于强化组件，复用逻辑，提升渲染性能等作用。高阶组件也并不是很难理解，其实接触过后还是蛮简单的，接下来将按照，高阶组件理解？，高阶组件具体怎么使用？应用场景， 高阶组件实践(源码级别) 为突破口，带大家详细了解一下高阶组件。

我们带着问题去开始今天的讨论：

1 什么是高阶组件，它解决了什么问题？
2 有几种高阶组件，它们优缺点是什么？
3 如何写一个优秀高阶组件？
4 hoc怎么处理静态属性，跨层级ref等问题？
5 高阶组件怎么控制渲染，隔离渲染？
6 高阶组件怎么监控原始组件的状态？
…

高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分，它是一种基于 React 的组合特性而形成的设计模式。

二全方位看高阶组件

1 几种包装强化组件的方式

① mixin模式

原型图

老版本的`react-mixins`

在react初期提供一种组合方法。通过React.createClass,加入mixins属性，具体用法和vue 中mixins相似。具体实现如下。

const customMixin = {
 componentDidMount(){
 console.log( '------componentDidMount------' )
 },
 say(){
 console.log(this.state.name)
 }
}

const APP = React.createClass({
 mixins: [ customMixin ],
 getInitialState(){
 return {
 name:'alien'
 }
 },
 render(){
 const { name } = this.state
 return <div> hello ,world , my name is { name } </div>
 }
})

这种mixins只能存在createClass中，后来React.createClass连同mixins这种模式被废弃了。mixins会带来一些负面的影响。

Fragment 和 Portals

Tue, 17 Dec 2024 00:00:00 +0800

一、Portals

某些情况下，我们希望渲染的内容独立于父组件，甚至独立于当前挂在的DOM元素（默认都是挂载到id为root的DOM元素上的）

Portal提供了一种将子节点渲染到存在于父组件以外的DOM节点的优秀的方案：

ReactDOM.createPortal(child, container)

第一个参数：是任何可渲染的React子元素，例如一个元素、字符串或fragment 第二个参数：是一个DOM元素

通常来讲，当你从组件的 render 方法返回一个元素时，该元素将被挂载到 DOM 节点中离其最近的父节点：

render() {
 // React 挂载了一个新的 div，并且把子元素渲染其中
 return (
 <div>
 {this.props.children}
 </div>
 );
}

然而，有时候将子元素插入到 DOM 节点中的不同位置也是有好处的：

render() {
 // React 并没有创建一个新的 div。它只是把子元素渲染到 `domNode` 中。
 // `domNode` 是一个可以在任何位置的有效 DOM 节点。
 return ReactDOM.createPortal(
 this.props.children,
 domNode
 );
}

一个 portal 的典型用例是当父组件有 overflow: hidden 或 z-index 样式时，但你需要子组件能够在视觉上“跳出”其容器。例如，对话框、悬浮卡以及提示框

案例

比如将h2挂在到id为zs的节点下

index.html

<!DOCTYPE html>
<html lang="en">
 <head>
 <meta charset="utf-8" />
 <link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
 <meta name="viewport" content="width=device-width, initial-scale=1" />
 <meta name="theme-color" content="#000000" />
 <meta
 name="description"
 content="Web site created using create-react-app"
 />
 <link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
 <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
 <title>React App</title>
 </head>
 <body>
 <noscript>You need to enable JavaScript to run this app.</noscript>
 <div id="root"></div>
 <div id="zs"></div>
 </body>
</html>

App.jsx

性能优化

Tue, 17 Dec 2024 00:00:00 +0800

本文篇幅较长，将从 编译阶段 -> 路由阶段 -> 渲染阶段 -> 细节优化 -> 状态管理 -> 海量数据源，长列表渲染 方向分别加以探讨。

一不能输在起跑线上，优化babel配置,webpack配置为项

1 真实项目中痛点

当我们用create-react-app或者webpack构建react工程的时候，有没有想过一个问题，我们的配置能否让我们的项目更快的构建速度，更小的项目体积，更简洁清晰的项目结构。随着我们的项目越做越大，项目依赖越来越多，项目结构越来越来复杂，项目体积就会越来越大，构建时间越来越长，久而久之就会成了一个又大又重的项目，所以说我们要学会适当的为项目‘减负’，让项目不能输在起跑线上。

2 一个老项目

拿我们之前接触过的一个react老项目为例。我们没有用dva,umi快速搭建react，而是用react老版本脚手架构建的，这对这种老的react项目，上述的问题都会存在，下面让我们一起来看看。

我们首先看一下项目结构。

再看看构建时间。

为了方便大家看构建时间，我简单写了一个webpack，plugin ConsolePlugin ,记录了webpack在一次compilation所用的时间。

const chalk = require('chalk') /* console 颜色 */
var slog = require('single-line-log'); /* 单行打印 console */

class ConsolePlugin {
 constructor(options){
 this.options = options
 }
 apply(compiler){
 /**
 * Monitor file change 记录当前改动文件
 */
 compiler.hooks.watchRun.tap('ConsolePlugin', (watching) => {
 const changeFiles = watching.watchFileSystem.watcher.mtimes
 for(let file in changeFiles){
 console.log(chalk.green('当前改动文件：'+ file))
 }
 })
 /**
 * before a new compilation is created. 开始 compilation 编译 。
 */
 compiler.hooks.compile.tap('ConsolePlugin',()=>{
 this.beginCompile()
 })
 /**
 * Executed when the compilation has completed. 一次 compilation 完成。
 */
 compiler.hooks.done.tap('ConsolePlugin',()=>{
 this.timer && clearInterval( this.timer )
 const endTime = new Date().getTime()
 const time = (endTime - this.starTime) / 1000
 console.log( chalk.yellow(' 编译完成') )
 console.log( chalk.yellow('编译用时：' + time + '秒' ) )
 })
 }
 beginCompile(){
 const lineSlog = slog.stdout
 let text = '开始编译：'
 /* 记录开始时间 */
 this.starTime = new Date().getTime()
 this.timer = setInterval(()=>{
 text += '█'
 lineSlog( chalk.green(text))
 },50)
 }
}

构建时间如下：

代码分割

Tue, 17 Dec 2024 00:00:00 +0800

什么是代码分割

代码分割是一种将代码分割成多个小块的方式，然后按需加载或并行加载所需的块的技术。代码分割可以用于减少应用程序的初始加载时间或将代码切割成可按需加载的块，从而减少应用程序所需的总体代码量。

为什么要使用代码分割

在大型应用程序中，将所有代码放在一个文件中会导致应用程序加载时间过长，影响用户体验。为了解决这个问题，我们需要将代码分割成小块，然后按需加载或并行加载所需的块。

代码分割的方式

1. 动态导入 import

import()是 JavaScript 中的一个动态导入语法，它允许在运行时异步加载模块。它返回一个 Promise，该 Promise 在模块加载完成后被解析为一个包含导出内容的模块对象。使用 import()的语法如下：

import(modulePath)
 .then((module) => {
 // 使用导入的模块
 })
 .catch((error) => {
 // 处理错误
 });

在这个语法中，modulePath 是一个字符串，用于指定要加载的模块路径。它可以是相对路径或绝对路径，也可以是一个包名。当调用 import(modulePath)时，它会返回一个 Promise。这个 Promise 会在模块加载完成后被解析为一个包含导出内容的模块对象。你可以使用.then()方法来处理解析后的模块对象，并在其中使用导入的模块。如果模块加载失败，Promise 会被拒绝，并触发.catch()方法中的错误处理逻辑。

注意事项 import()只能在模块的顶层作用域中使用，不能在函数内部或条件语句中使用。这是因为 import()是静态解析的，它在代码加载时就会执行，而不是在运行时。

另外，import()可以与其他语法结合使用，例如动态模块路径和对象解构。动态模块路径：

const modulePath = "./myModule";

import(modulePath)
 .then((module) => {
 // 使用导入的模块
 })
 .catch((error) => {
 // 处理错误
 });

在这个示例中，modulePath 是一个变量，它的值在运行时确定。这样可以根据需要动态加载不同的模块。

对象解构：

import("./myModule")
 .then(({ myFunction, myVariable }) => {
 // 使用导入的函数和变量
 myFunction();
 console.log(myVariable);
 })
 .catch((error) => {
 // 处理错误
 });

2. React.lazy

React.lazy 是 React 16.6 版本引入的一个特性，它可以让你以动态的方式进行代码拆分（code splitting）。通过 React.lazy，你可以延迟加载（lazy load）一个组件，只有在需要时才会加载该组件，从而提高应用程序的性能。 React.lazy 的用法如下：

react 状态提升

Tue, 17 Dec 2024 00:00:00 +0800

在开始介绍状态提升之前，我想先介绍一下 Prop Drilling（属性钻取）的概念。

什么是Prop Drilling ？

那么，什么是状态提升呢？我们都知道 React 中的prop drilling（属性钻取）。prop drilling意味着从父组件向子组件传递一些 props。通过这种方式，我们可以在不同的组件之间共享数据或函数。可以使用 prop 传递任何类型的数据。

在上面的示例代码中，你可以看到，Home 组件具有一个名为 name 的状态，并且她与子组件共用 name 变量。在 React 中，只能将数据从父组件传递到子组件。

什么是 State Lifting

一般来说，状态提升允许你将数据从子组件移动到父组件，与Props Drilling不同，你可以在父组件使用子组件的状态值。这是不是很疯狂？

在 React 生态中，我们知道数据只能从父组件流向子组件，但现在将学习如何让数据反过来流动。

但是，为什么要这么做？

我们可以在父组件中定义状态并将其以 prop 的方式传递给子组件，但是这么做有可能会导致性能损失和代码复杂度提升。在我之前的博客中有提到：保持状态本地化很重要。因为当状态更新时，组件以及该组件的子组件都会重新渲染。

此外对于代码复杂性，对于如 Modal 这样的组件，选择在子组件中声明状态而不是在父组件中声明状态，将能够使代码更易于阅读。使用这种方法，你不必在每个父组件中声明状态。

通常对应用程序中的大多数组件来说，这是不必要的。但是，对于某些类型的组件，特别是可重用组件，会有这种需求。下面描述一下最通用的场景。

多说无用，上代码：

例如，我们有一个常见的 Modal 组件，我们想要在 Modal 中保留可见性状态。当一些组件想要使用这个 Modal 时，通常会定义自己的可见状态，但是通过 State Lifting，这个步骤将不再必要。

在上面的 Modal 组件中，做了如下操作：

首先，使用forwardRef执行 ref 转发，ref 转发是一种自动将 ref 通过组件传递给子组件的技术。
使用 useState 声明状态以控制Modal组件的展示或隐藏。
使用 React 内置的 useImperativeHandle hook 将属性或者方法暴露出去，这里我们添加了一些数据和函数供父组件使用。现在父组件可以直接调用子组件的show、hide、isVisble这些方法和属性。

forwardRef 该怎么用？

Tue, 17 Dec 2024 00:00:00 +0800

React.forwardRef

对于ref转发，官网是这样描述的

Ref 转发是一项将 ref 自动地通过组件传递到其一子组件的技巧。对于大多数应用中的组件来说，这通常不是必需的。但其对某些组件，尤其是可重用的组件库是很有用的。

想详细了解的可以去看官方文档 Refs 转发 – React (docschina.org)

现在让我们直奔主题吧！

React.forwardRef(render)的返回值是react组件，接收的参数是一个 render函数，函数签名为render(props, ref)，第二个参数将其接受的 ref 属性转发到render返回的组件中。

这项技术并不常见，但在以下两种场景中特别有用:

转发 ref 到组件内部的DOM 节点上
在高阶组件中转发ref

转发 `ref`到组件内部的`DOM`节点

比如我们想要将一个组件内部的某个元素暴露出去, 就可以这么做

// App.js
import React from 'react';
import Foo from './component/Foo';

export default class App extends React.Component {
 constructor(props) {
 super(props);
 this.state = {};
 this.input = React.createRef(); // 1
 // ↑5
 }

 handleClick = (e) => {
 const input = this.input.current;
 // 6
 console.log(input);
 console.log(input.value);
 input.focus();
 }

 render() {
 return (
 <>
 <button onClick={this.handleClick}>click to get value</button>
 {/*2*/}
 <Foo ref={this.input}/>
 </>
 )
 }
}

// Foo.jsx
import React from 'react';
 // 3
const Foo = React.forwardRef((props, myRef) => {
 return (
 <div>
 <p>....一些其他节点</p> {/*4*/}
 <input type="text" defaultValue='ref 成功转发到 Foo 组件内部的 input节点上' ref={myRef}/>
 <p>....一些其他节点</p>
 <p>....一些其他节点</p>
 </div>
 );
});

export default Foo;

仔细看代码中标记的数字，这是ref转发的流程:

错误边界

Tue, 17 Dec 2024 00:00:00 +0800

人无完人，代码总会出错，出错并不可怕，关键是怎么处理。

我就想问问大家react的应用的错误怎么捕捉呢？这个时候：

小白+++：怎么处理？
小白++： ErrorBoundary
小白+： ErrorBoundary, try catch
小黑#: ErrorBoundary, try catch, window.onerror
小黑##: 这个是个严肃的问题，我知道N种处理方式，你有什么更好的方案?

ErrorBoundary

EerrorBoundary是16版本出来的，有人问那我的15版本呢，我不听我不听，反正我用16，当然15有unstable_handleError。

关于ErrorBoundary官网介绍比较详细，这个不是重点，重点是他能捕捉哪些异常。

子组件的渲染
生命周期函数
构造函数

class ErrorBoundary extends React.Component {
 constructor(props) {
 super(props);
 this.state = { hasError: false };
 }

 componentDidCatch(error, info) {
 // Display fallback UI
 this.setState({ hasError: true });
 // You can also log the error to an error reporting service
 logErrorToMyService(error, info);
 }

 render() {
 if (this.state.hasError) {
 // You can render any custom fallback UI
 return <h1>Something went wrong.</h1>;
 }
 return this.props.children;
 }
}

<ErrorBoundary>
 <MyWidget />
</ErrorBoundary>

开源世界就是好，早有大神封装了react-error-boundary 这种优秀的库。
你只需要关心出现错误后需要关心什么，还以来个 Reset, 完美。

react-router

Tue, 17 Dec 2024 00:00:00 +0800

写在前面：为什么要学习react-router底层源码? 为什么要弄明白整个路由流程？

学习react-router，有助于我们学习单页面应用(spa)路由跳转原理，让我们理解从history.push，到组件页面切换的全套流程，使我们在面试的时候不再为路由相关的问题发怵，废话不说，让我们开启深入react-router源码之旅吧。

一正确理解react-router

1 理解单页面应用

什么是单页面应用？

个人理解，单页面应用是使用一个html下，一次性加载js, css等资源，所有页面都在一个容器页面下，页面切换实质是组件的切换。

2 react-router初探，揭露路由原理面纱

①`react-router-dom`和`react-router`和`history`库三者什么关系

**history** 可以理解为react-router的核心，也是整个路由原理的核心，里面集成了popState,history.pushState等底层路由实现的原理方法，接下来我们会一一解释。

**react-router**可以理解为是**react-router-dom**的核心，里面封装了Router，Route，Switch等核心组件,实现了从路由的改变到组件的更新的核心功能,在我们的项目中只要一次性引入react-router-dom就可以了。

**react-router-dom**,在react-router的核心基础上，添加了用于跳转的Link组件，和histoy模式下的BrowserRouter和hash模式下的HashRouter组件等。所谓**BrowserRouter和HashRouter，也只不过用了history库中createBrowserHistory和createHashHistory方法**

react-router-dom 我们不多说了，这里我们重点看一下react-router。

②来个小demo尝尝鲜?

import { BrowserRouter as Router, Switch, Route, Redirect,Link } from 'react-router-dom'

import Detail from '../src/page/detail'
import List from '../src/page/list'
import Index from '../src/page/home/index'

const menusList = [
 {
 name: '首页',
 path: '/index'
 },
 {
 name: '列表',
 path: '/list'
 },
 {
 name: '详情',
 path: '/detail'
 },
]
const index = () => {
 return <div >
 <div >

 <Router >
 <div>{
 /* link 路由跳转 */
 menusList.map(router=><Link key={router.path} to={ router.path } >
 <span className="routerLink" >{router.name}</span>
 </Link>)
 }</div>
 <Switch>
 <Route path={'/index'} component={Index} ></Route>
 <Route path={'/list'} component={List} ></Route>
 <Route path={'/detail'} component={Detail} ></Route>
 {/* 路由不匹配，重定向到/index */}
 <Redirect from='/*' to='/index' />
 </Switch>
 </Router>
 </div>
 </div>
}

效果如下

react 渲染机制

Tue, 17 Dec 2024 00:00:00 +0800

前言

文本分为两大部分讲解，一部分是首次挂载渲染原理，另一部分是更新和卸载原理，很多地方非常抽象，希望大家仔细阅读，不然容易脱节。废话不多话，开车！！

正文

在开始之前，需要一些前置知识才能帮助我们更好的理解整个渲染过程。首先就是生命周期(16版本之后)，为什么要讲一下生命周期？跟渲染原理有关系吗？当然有，如果你不理解渲染原理的话，更新一个嵌套很深的组件你甚至连父与子生命周期执行的先后顺序都不知道。本文直接对照16版本之后的新生命周期进行讲解，就不讲解老版本了。

初探-生命周期

顾名思义，跟人生一样，生命周期就是一个组件从诞生到销毁的过程。React在组件的生命周期中注册了一系列的钩子函数，支持开发者在其中注入代码，并在适当的时机运行。这里指的生命周期仅针对于类组件中的钩子函数。因为生命周期不是本文的重点，所以Hooks中的新增的钩子函数在本文中均不涉及，可以以后出个Hooks原理篇。

从图中可以看到，我把生命周期分为了挂载阶段、更新阶段、卸载阶段三个阶段。同时，在挂载阶段和更新阶段都会运行getDerivedStateFromProps和render，卸载阶段很好理解，只有一个componentWillUnMount，在卸载组件之前做一些事情，通常用来清除定时器等副作用操作。那么挂载阶段和更新阶段中的生命周期我们来逐一看下每个运行点及作用。

1. constructor

在同一个类组件对象只会运行一次。所以经常来做一些初始化的操作。同一个组件对象被多次创建，它们的construcotr互不干扰。

注意：在construcotr中要尽量避免（最好禁止）使用setState。 我们都知道使用setState会造成页面的重新渲染，但是在初始化阶段，页面都还没有将真实DOM挂载到页面上，那么重新渲染的又有什么意义呢。除异步的情况，比如setInterval中使用setState是没问题的，因为在执行的时候页面早已渲染完成。但也最好不要，容易一些引起奇怪的问题。

 constructor(props) {
 super(props);

 this.state = {
 num: 1
 };

 //不可以，直接Warning
 this.setState({
 num: this.state.num + 1
 });

 //可以使用，但不建议
 setInterval(()=>{
 this.setState({
 num: this.state.num + 1
 });
 }, 1000);
 }

2. 静态属性 static getDerivedStateFromProps

该方法是一个静态属性，在16版本之前不存在，在新版生命周期中主要用来取代componentWillMount和componentWillReceiveProps，因为这两个老生命周期方法在一些开发者不规范的使用下极容易产生一些反模式的bug。因为是静态方法，所以你在其中根本拿不到this，更不可能调用setState。

该方法在挂载阶段和更新阶段都会运行。它有两个参数props和state当前的属性值和状态。它的返回值会合并掉当前的状态（state）。如果返回了非Object的值，那么它啥都不会做，如果返回的是Object，那么它将会跟当前的状态合并，可以理解为Object.assign。通常情况下，几乎不怎么使用该方法。

 /**
 * 静态方法，首次挂载和更新渲染都会运行该方法
 * @param {*} props 当前属性
 * @param {*} state 当前状态
 */
 static getDerivedStateFromProps(props, state){
 // return 1; //没用
 return {
 num: 999, //合并到当前state对象
 };
 }

3. `render`

最重要的生命周期，没有之一。用来生成虚拟节点（vDom）树。该方法只要遇到需要重新渲染都会运行。同样的，在render中也严禁使用setState，因为会导致无限递归重新渲染导致爆栈。

React函数组件更新

Tue, 17 Dec 2024 00:00:00 +0800

React的函数组件（Function Components）自Hooks推出以来已成为React开发的主流方式。理解函数组件的更新原理对于编写高效、可维护的React应用至关重要。本文将深入探讨React函数组件的更新机制。

一、函数组件与类组件的本质区别

在深入更新原理前，我们需要明确函数组件与类组件的根本区别：

类组件：是类的实例，拥有实例属性和生命周期方法
函数组件：是纯函数，接收props作为参数，返回JSX

这种本质区别决定了它们的更新行为完全不同。

二、函数组件的执行机制

当React需要渲染一个函数组件时，它只是简单地调用这个函数：

function MyComponent(props) {
 return <div>{props.message}</div>;
}

// React内部大致这样处理
const element = MyComponent({ message: 'Hello' });

每次渲染都是全新的函数调用，所有局部变量和函数都会重新创建。这与类组件形成鲜明对比，类组件在更新时会复用同一个实例。

三、触发更新的场景

函数组件的更新主要由以下情况触发：

父组件重新渲染：即使props未变化，父组件渲染也会导致子组件重新渲染
props发生变化：当传入组件的props值改变时
状态更新：通过useState、useReducer等Hook更新状态
context变化：组件订阅的context值发生变化
Hooks依赖变化：useEffect、useMemo等Hook的依赖项发生变化

四、React的渲染流程

函数组件的更新遵循React的渲染流程：

触发更新：通过setState、父组件渲染等途径触发更新
协调阶段（Reconciliation）：

React调用函数组件获取新的JSX
与上一次渲染的JSX进行对比（Virtual DOM Diff）

提交阶段（Commit）：

将差异应用到真实DOM
执行useLayoutEffect的回调

浏览器绘制：浏览器重绘屏幕
副作用执行：执行useEffect的回调

五、Hooks与组件更新

Hooks是函数组件能够拥有状态和生命周期的关键。理解Hooks的工作机制对理解组件更新至关重要。

useState的工作原理

const [count, setCount] = useState(0);

React会在组件首次渲染时为每个useState调用分配一个"状态单元"
后续更新时，React会按照Hooks的调用顺序来提供对应的状态值
setCount调用会触发组件的重新渲染

useEffect与更新

useEffect(() => {
 // 副作用代码
 return () => {
 // 清理函数
 };
}, [dependencies]);

组件每次渲染后，React会比较依赖项数组
如果依赖项变化或没有提供依赖项数组，副作用会重新执行
清理函数会在副作用重新执行前或组件卸载时执行

六、优化更新性能

由于函数组件每次更新都会完整执行函数体，我们需要一些优化手段：

react 组件设计模式

Tue, 17 Dec 2024 00:00:00 +0800

首先我们想一个问题，那就是 为什么要学习设计模式？ 原因我总结有以下几个方面。

1. 功能复杂，逻辑复用问题。

首先 React 灵活多变性，就决定了 React 项目可以应用多种设计模式。但是这些设计模式的产生也确实办了实事:

场景一：

在一个项目中，全局有一个状态，可以称之为 theme （主题），那么有很多 UI 功能组件需要这个主题，而且这个主题是可以切换的，就像 github 切换暗黑模式一样，那么如何优雅的实现这个功能呢？

这个场景如果我们用 React 的提供者模式，就能轻松搞定了，通过 context 保存全局的主题，然后将 theme 通过 Provider 形式传递下去，需要 theme ，那么消费 context ，就可以了，这样的好处是，只要 theme 改变，消费 context 的组件就会重新更新，达到了切换主题的目的。

场景二：

表单设计场景也需要一定程度上的 React 的设计模式，首先对于表单状态的整体验证需要外层的 Form 绑定事件控制，调度表单的状态下发，验证功能。内层对于每一个表单控件还需要 FormItem 收集数据，让控件变成受控的。这样的 Form 和 FormItem 方式，就是通过组合模式实现的。

2. 培养设计能力，编程能力

熟练运用 React 的设计模式，可以培养开发者的设计能力，比如 HOC 的设计 ，公共组件的设计 ，自定义 hooks 的设计，一些开源的优秀的库就是通过 React 的灵活性和优秀的设计模式实现的。

例子：

比如在 React 状态管理工具中，无论是 react-redux ，还是 mobx-react，一方面想要把 state 和 dispatch 函数传递给组件，另一方面订阅 state 变化，来促使业务组件更新，那么整个流程中，需要一个或多个 HOC 来搞定。于是 react-redux 提供了 connect，mobx-react 提供了 inject ，observer 等优秀的 hoc。由此可见，学会 React 的设计模式，有助于开发者小到编写公共组件，大到开发开源项目。

React.js on Last Stand

JSX

JSX 的本质：JavaScript 的语法扩展

JSX 语法是如何在 JavaScript 中生效的：认识 Babel

元素、组件、实例和节点

元素 (Element)

组件 (Component)

state 与 props

state

基本定义

props

基本定义

代码示例

props的特性

React 生命周期

简介

新旧生命周期对比

old lifecycle

new lifecycle

分析废弃原因

react hooks

一 前言

1.1 技术背景

Context API

先看看React官网对于Context的介绍

第一种：React.createContext提供的Provider和Consumer

条件渲染的常见方法和注意事项

条件渲染方式

1. if 语句

2. 三元运算符

列表和key

为什么需要 key？

react 事件机制

一 前言

必要的知识概念

我们写在JSX事件终将变成什么？

什么是合成事件？

受控组件和非受控组件

高阶组件

一 前言

二 全方位看高阶组件

1 几种包装强化组件的方式

① mixin模式

老版本的react-mixins

Fragment 和 Portals

一、Portals

案例

性能优化

一 不能输在起跑线上，优化babel配置,webpack配置为项

1 真实项目中痛点

2 一个老项目

代码分割

什么是代码分割

为什么要使用代码分割

代码分割的方式

1. 动态导入 import

2. React.lazy

react 状态提升

什么是Prop Drilling ？

什么是 State Lifting

forwardRef 该怎么用？

React.forwardRef

转发 ref到组件内部的DOM节点

错误边界

ErrorBoundary

react-router

一 正确理解react-router

1 理解单页面应用

2 react-router初探，揭露路由原理面纱

①react-router-dom和react-router和history库三者什么关系

②来个小demo尝尝鲜?

react 渲染机制

前言

正文

初探-生命周期

1. constructor

2. 静态属性 static getDerivedStateFromProps

3. render

React函数组件更新

一、函数组件与类组件的本质区别

一前言

一前言

一前言

二全方位看高阶组件

老版本的`react-mixins`

一不能输在起跑线上，优化babel配置,webpack配置为项

转发 `ref`到组件内部的`DOM`节点

一正确理解react-router

①`react-router-dom`和`react-router`和`history`库三者什么关系

3. `render`