419 lines
15 KiB
Markdown
419 lines
15 KiB
Markdown
---
|
||
tags: [React, Components, Props, Frontend]
|
||
create time: 2026-04-29 22:02
|
||
---
|
||
|
||
# 组件与 Props
|
||
|
||
## 概述
|
||
|
||
React 应用由一组可复用的组件构成。理解组件的拆分粒度、Props 的类型安全传递，以及组合优于继承的设计哲学，是写出高质量 React 代码的核心。本章从组件的基本形态讲起，深入到 Props 的校验与传递模式，最后介绍组件组合的高级技巧。
|
||
|
||
> [!tip] 本节学习路线
|
||
> 1. 函数组件 vs 类组件 → 为什么函数组件成为主流
|
||
> 2. 组件拆分原则 → 如何找到合理的职责边界
|
||
> 3. Props 定义与校验 → TypeScript 方式（推荐）和 PropTypes 方式
|
||
> 4. Props 传递模式 → 基础透传、回调通信、children 插槽
|
||
> 5. Composition 高级模式 → React.memo、forwardRef、受控组件
|
||
> 6. Context 初探 → 轻量级跨层级通信
|
||
|
||
## 函数组件 vs 类组件
|
||
|
||
```tsx
|
||
// ✅ 函数组件（当前推荐写法）
|
||
// 输入 props，输出 JSX —— 纯函数的直观映射
|
||
function Greeting({ name }: { name: string }) {
|
||
return <h1>Hello, {name}</h1>;
|
||
}
|
||
|
||
// ⚠️ 类组件（遗留项目常见，新项目中应避免）
|
||
// this.props + render() —— 需要额外处理 this 绑定
|
||
class Greeting extends React.Component<{ name: string }> {
|
||
render() {
|
||
return <h1>Hello, {this.props.name}</h1>;
|
||
}
|
||
}
|
||
```
|
||
|
||
### 为什么推荐函数组件？
|
||
|
||
| 对比维度 | 函数组件 + Hooks | 类组件 |
|
||
|----------|------------------|--------|
|
||
| 心智模型 | 纯函数：输入 props → 输出 JSX | 实例方法 + this 绑定 |
|
||
| 逻辑复用 | Custom Hooks（声明式组合） | HOC / Render Props（嵌套地狱）|
|
||
| 类型推导 | TS 自动推断完善 | 需要手动泛型参数 |
|
||
| 性能开销 | 无实例创建成本 | new 实例 + bind overhead |
|
||
| Suspense | 完全支持 | 不支持 |
|
||
| Hooks 绑定 | 基于调用顺序 | 依赖 this 上下文 |
|
||
|
||
> [!note] Hooks 绑定的本质
|
||
> useState、useEffect 等 Hook 按调用顺序内部维护一个链表。这就是为什么 Hook **不能写在条件语句或循环中**——顺序一旦改变，状态就会错配。
|
||
|
||
## 组件拆分原则
|
||
|
||
> [!question] 思考：一个按钮算一个独立组件，还是把按钮和其外层容器一起写？
|
||
>
|
||
> 如果按钮只在这一处使用，合并更简洁；如果多个地方共用同一个按钮样式或交互逻辑，就应该拆出来。核心判断标准：**这个组件是否有独立的业务语义？**
|
||
|
||
好的拆分遵循 **"单一职责" + "合理抽象"**。下面用流程图展示不同层级的职责划分：
|
||
|
||
```mermaid
|
||
graph LR
|
||
subgraph P ["Page Level — 页面组装层"]
|
||
A["AboutPage<br/>拼接各功能模块"]
|
||
end
|
||
|
||
subgraph F ["Feature Level — 功能模块层"]
|
||
B["UserProfile<br/>头像 + 昵称 + 设置入口"]
|
||
C["Dashboard<br/>图表 + 数据表格"]
|
||
end
|
||
|
||
subgraph C2 ["Component Level — 通用 UI 层"]
|
||
D["Button<br/>按钮变体 & 尺寸"]
|
||
E["Modal<br/>弹窗外壳"]
|
||
end
|
||
|
||
subgraph PL ["Primitive Level — 原子层"]
|
||
F2["IconButton<br/>图标按钮"]
|
||
G["Avatar<br/>头像图片"]
|
||
end
|
||
|
||
A --> B
|
||
A --> C
|
||
B --> D
|
||
B --> G
|
||
C --> E
|
||
D --> F2
|
||
```
|
||
|
||
### 判断是否该拆分的标准
|
||
|
||
1. **可复用性** — 同一组 JSX 出现两次以上，考虑抽取为独立组件
|
||
2. **可读性** — 单个文件超过 300 行、单个组件超过 80 行，应考虑拆分
|
||
3. **测试粒度** — 难以单独测试的巨型组件应拆为小组件
|
||
4. **业务语义** — 每个组件应对应一个清晰的业务概念
|
||
|
||
```tsx
|
||
// ❌ 反例：巨型组件，混合了多个不相关的职责
|
||
function Dashboard() {
|
||
// 200+ 行，混合了 Header、Sidebar、DataTables、Chart...
|
||
// 改 Header 要遍历整文件，测试也要 mock 所有子模块
|
||
}
|
||
|
||
// ✅ 正例：拆分为功能块，每个组件职责单一
|
||
function Dashboard() {
|
||
return (
|
||
<>
|
||
<DashboardHeader /> {/* 专注头部信息 */}
|
||
<aside><Sidebar /></aside> {/* 专注侧边导航 */}
|
||
<main>
|
||
<DataTable data={tasks} /> {/* 专注数据表格 */}
|
||
<Chart data={stats} /> {/* 专注图表展示 */}
|
||
</main>
|
||
</>
|
||
);
|
||
}
|
||
```
|
||
|
||
## Props 定义与类型校验
|
||
|
||
### TypeScript 接口方式（推荐）
|
||
|
||
```tsx
|
||
interface ButtonProps {
|
||
label: string; // 必填：按钮文字
|
||
variant?: "primary" | "secondary" | "danger"; // 可选：视觉变体（联合类型约束）
|
||
size?: "sm" | "md" | "lg"; // 可选：尺寸档位
|
||
disabled?: boolean; // 可选：禁用态
|
||
onClick?: (e: React.MouseEvent<HTMLButtonElement>) => void; // 可选：点击回调
|
||
children?: React.ReactNode; // 可选：内容插槽
|
||
}
|
||
|
||
// 方式1：解构赋值设默认值（适合简单默认值）
|
||
function Button({ label, variant = "primary", onClick }: ButtonProps) {
|
||
return <button className={`btn btn-${variant}`} onClick={onClick}>{label}</button>;
|
||
}
|
||
|
||
// 方式2：全部字段显式声明默认值（适合需要覆盖全部可选字段时）
|
||
function Button({ label, variant = "primary", size = "md", disabled = false, children }: ButtonProps) {
|
||
return <button className={`btn btn-${variant} btn-${size}`} disabled={disabled}>{children}</button>;
|
||
}
|
||
```
|
||
|
||
> [!tip] 类型定义的位置建议
|
||
> - 小型组件：interface 与组件放在同一文件中
|
||
> - 大型组件库：type 导出到独立的 `types.ts`，便于跨文件引用和复用
|
||
|
||
### PropTypes 方式（JS 项目或过渡期）
|
||
|
||
```js
|
||
import PropTypes from 'prop-types';
|
||
|
||
Button.propTypes = {
|
||
label: PropTypes.string.isRequired, // 必填字符串
|
||
variant: PropTypes.oneOf(["primary", "secondary"]), // 枚举限制
|
||
onClick: PropTypes.func, // 可选函数
|
||
};
|
||
```
|
||
|
||
> [!warning] 不要混用两种校验方式
|
||
> TS 提供**编译时检查**，PropTypes 是**运行时兜底**。选其一即可，新项目统一用 TS。混用会导致维护和调试成本翻倍。
|
||
|
||
## Props 传递模式
|
||
|
||
### 基础传递
|
||
|
||
```tsx
|
||
// 1. 直接传递字面量值
|
||
<Button label="提交" disabled />
|
||
|
||
// 2. 传递变量或表达式
|
||
<Button label={submitText} onClick={handleSubmit} />
|
||
```
|
||
|
||
### 展开透传（Spread Props）
|
||
|
||
```tsx
|
||
// 当一层组件需要将自身 props 原样传给子组件时，避免逐个手写
|
||
const inputProps = { placeholder: "请输入", onChange: handleChange };
|
||
<Input {...inputProps} /> // ⚡ Spread Operator 将对象解包为独立的 props
|
||
|
||
// 局部覆盖：父 prop 优先级低于子 prop（后者覆盖前者）
|
||
<Input {...inputProps} autoFocus /> // autoFocus 额外传入，其余来自 inputProps
|
||
```
|
||
|
||
### 回调 Prop（子 → 父通信）
|
||
|
||
```tsx
|
||
// 子组件通过回调将数据或事件通知父组件
|
||
<Form onSubmit={(data) => console.log("收到表单数据:", data)} />
|
||
// 💡 父组件将处理函数作为 prop 传入，子组件在合适时机调用它
|
||
```
|
||
|
||
### Render Item Prop（列表渲染定制）
|
||
|
||
```tsx
|
||
// 父组件告诉子组件："每个 item 长什么样"
|
||
<List
|
||
items={items}
|
||
renderItem={(item) => <ListItem key={item.id} {...item} />}
|
||
/>
|
||
// 📌 比完整的 Render Props 模式更轻量的写法
|
||
```
|
||
|
||
## Children 与 Composition
|
||
|
||
```tsx
|
||
// Card 接收 children（任意 JSX 内容），灵活度远超固定 string prop
|
||
function Card({ children, header }: { children: React.ReactNode; header: string }) {
|
||
return (
|
||
<div className="card">
|
||
<h3>{header}</h3>
|
||
<div className="card-body">{children}</div>
|
||
</div>
|
||
);
|
||
}
|
||
|
||
// 使用示例：children 可以包含任意合法的 JSX
|
||
<Card header="用户信息">
|
||
<p>姓名：张三</p>
|
||
<p>年龄：25</p>
|
||
</Card>
|
||
|
||
// Fragment —— 不产生额外 DOM 节点，用于包裹兄弟元素
|
||
function ListItem({ text, icon }: { text: string; icon: React.ReactNode }) {
|
||
return (
|
||
<li>
|
||
<> {/* ⚡ Fragment 缩写语法 */}
|
||
<span className="icon">{icon}</span>
|
||
<span>{text}</span>
|
||
</>
|
||
</li>
|
||
);
|
||
}
|
||
```
|
||
|
||
> [!question] children 的类型为什么是 React.ReactNode 而不是 JSX.Element？
|
||
> - `JSX.Element` 只代表 React 元素（如 `<div />`、`<Comp />`）
|
||
> - `React.ReactNode` 范围更广：包含字符串、数字、Fragment、数组、甚至 null/undefined
|
||
> - 💡 如果用 `JSX.Element`，当子元素是纯文本或数组时会报错
|
||
|
||
## React.memo —— 减少不必要的重渲染
|
||
|
||
```tsx
|
||
// memo 对组件做了一层"浅比较"包装：只有 props 变化时才重新渲染
|
||
const UserItem = React.memo(function UserItem({ name, age }: { name: string; age: number }) {
|
||
// 即使父组件其他 state 变化，只要 name 和 age 不变，就不会重渲染
|
||
return <li>{name}，{age} 岁</li>;
|
||
});
|
||
|
||
// 自定义比较函数（仅在需要深比较时使用，一般不需要）
|
||
const compare = (prev: UserItemProps, next: UserItemProps) => prev.name === next.name && prev.age === next.age;
|
||
const UserItemDeep = React.memo(UserItem, compare);
|
||
```
|
||
|
||
> [!tip] memo 的性能权衡
|
||
> - 适用于**频繁重渲染但 props 稳定**的叶子组件
|
||
> - 过度使用会增加维护成本和内存开销——先用 Profile 工具定位瓶颈，再决定是否加 memo
|
||
|
||
## forwardRef —— 访问子组件 DOM 节点
|
||
|
||
```tsx
|
||
// 父组件需要通过 ref 操作子组件内部的 DOM（如聚焦输入框）
|
||
const FancyInput = forwardRef<HTMLInputElement, { placeholder: string }>(({ placeholder }, ref) => {
|
||
return <input ref={ref} placeholder={placeholder} />;
|
||
});
|
||
|
||
// 使用方可以拿到原生 input 的 ref
|
||
function Form() {
|
||
const inputRef = useRef<HTMLInputElement>(null);
|
||
|
||
useEffect(() => {
|
||
inputRef.current?.focus(); // 💡 挂载后自动聚焦
|
||
}, []);
|
||
|
||
return <FancyInput ref={inputRef} placeholder="请输入..." />;
|
||
}
|
||
```
|
||
|
||
> [!important] forwardRef 的使用场景
|
||
> 不是所有组件都需要 forwardRef。**优先通过 props 解决问题**（可控组件模式）。只在以下场景才需要：
|
||
> - 需要暴露 DOM API（聚焦、测量、滚动等）
|
||
> - 封装底层 UI 库组件时需要透传 ref
|
||
|
||
## 受控组件模式（Controlled Components）
|
||
|
||
```tsx
|
||
// 组件的内部 state 由外部 props 控制 —— 单一数据源原则
|
||
function ControlledInput({ value, onChange }: { value: string; onChange: (v: string) => void }) {
|
||
return (
|
||
<input
|
||
value={value} // 🔑 value 由外部决定
|
||
onChange={(e) => onChange(e.target.value)} // 🔑 变化时通知外部更新
|
||
placeholder="输入内容"
|
||
/>
|
||
);
|
||
}
|
||
|
||
// 父组件持有唯一真实状态
|
||
function SearchPage() {
|
||
const [query, setQuery] = useState("");
|
||
return (
|
||
<>
|
||
<ControlledInput value={query} onChange={setQuery} />
|
||
<p>搜索关键词：{query || "(空)"}</p>
|
||
</>
|
||
);
|
||
}
|
||
```
|
||
|
||
> [!note] 受控 vs 非受控
|
||
> - **受控**：state 在父组件中管理，数据流向清晰（✅ 推荐大多数场景）
|
||
> - **非受控**：state 在子组件内部管理，通过 ref 读取（⚡ 适合简单的表单快速实现）
|
||
|
||
## Context 初探（轻量级全局状态）
|
||
|
||
Context 是 React 内置的跨组件树通信机制，适合传递那些"多处用到但不应逐层透传"的数据。
|
||
|
||
```tsx
|
||
// 创建 Context，初始值通常设为占位值（实际值由 Provider 注入）
|
||
const ThemeContext = createContext<"light" | "dark">("light");
|
||
|
||
function App() {
|
||
const [theme, setTheme] = useState<"light" | "dark">("light");
|
||
|
||
return (
|
||
<ThemeContext.Provider value={theme}>
|
||
{/* 其下所有子组件（不限层级）都可以通过 useContext 消费 */}
|
||
<Toggle />
|
||
<Content />
|
||
</ThemeContext.Provider>
|
||
);
|
||
}
|
||
|
||
function Toggle() {
|
||
const theme = useContext(ThemeContext); // 无需中间层透传
|
||
return <button onClick={() => setTheme(t => t === "light" ? "dark" : "light")}>切换主题</button>;
|
||
}
|
||
```
|
||
|
||
> [!warning] Context 的性能陷阱
|
||
> - Provider value 如果是**新对象**，每次渲染都是不同的引用 → 所有消费者全部重渲染
|
||
> - ✅ 解决：用 `useReducer` 返回稳定的 `{state, dispatch}` 对象，保持引用一致
|
||
> - ✅ 解决：拆分 Context，避免一个大 Context 塞入过多数据
|
||
|
||
## 组件组合的进阶模式
|
||
|
||
### Compound Components（复合组件）
|
||
|
||
当一个组件的子项之间存在**隐式共享状态**时，使用复合组件模式：
|
||
|
||
```tsx
|
||
// 手风琴组件：Tab 之间共享 activeIndex，但父组件无需关心
|
||
function Accordion({ children }: { children: React.ReactNode }) {
|
||
const [activeIndex, setActiveIndex] = useState<number | null>(null);
|
||
|
||
return (
|
||
<AccordionContext.Provider value={{ activeIndex, setActiveIndex }}>
|
||
<div className="accordion">{children}</div>
|
||
</AccordionContext.Provider>
|
||
);
|
||
}
|
||
|
||
function AccordionTab({ title, children }: { title: string; children: React.ReactNode }) {
|
||
const ctx = useContext(AccordionContext);
|
||
// 💡 每个 Tab 自己从 Context 里拿状态，父组件不用逐一传递
|
||
const isActive = ctx.activeIndex !== null;
|
||
return (
|
||
<div onClick={() => ctx.setActiveIndex(ctx.activeIndex)}>
|
||
<h3>{title}</h3>
|
||
{isActive && <div>{children}</div>}
|
||
</div>
|
||
);
|
||
}
|
||
|
||
// 对外暴露子组件属性，方便用户使用
|
||
Accordion.Tab = AccordionTab;
|
||
|
||
// 使用：状态在 Tabs 间共享，父组件只需包裹
|
||
<Accordion>
|
||
<Accordion.Tab title="第一章">...</Accordion.Tab>
|
||
<Accordion.Tab title="第二章">...</Accordion.Tab>
|
||
</Accordion>
|
||
```
|
||
|
||
> [!question] 什么时候用 compound components？
|
||
> 当你的一组子组件需要**彼此感知对方的状态**，又不想让父组件来协调时。典型场景：Tabs/Accordion/SwitchGroup/Table。
|
||
|
||
### Composition Flow
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant Parent as 父组件
|
||
participant Child as 子组件
|
||
participant DOM as DOM
|
||
|
||
Parent->>Child: 传入 props + children（JSX 树）
|
||
Note over Parent,Child: Props 描述配置，Children 描述内容
|
||
Child->>DOM: 根据 props 渲染特定结构
|
||
Child->>Child: 插入 children 到指定位置
|
||
Note over Child: 组合 = 配置 + 内容的分离
|
||
```
|
||
|
||
> [!tip] 组合 vs 继承
|
||
> React 的设计哲学是 **组合优于继承**：
|
||
> - JS 的 class 继承会导致紧耦合和脆弱的基类依赖
|
||
> - React 组合让每个组件保持独立，行为通过 props/children/Callbacks 灵活拼装
|
||
> - 💡 如果想共享逻辑，优先考虑 Custom Hooks 而非继承
|
||
|
||
## 关联笔记
|
||
|
||
- [[REACT/1. 基础篇/01-环境搭建与项目结构]] — React 项目初始化与目录规范
|
||
- [[REACT/1. 基础篇/02-JSX 语法]] — JSX 表达式、事件绑定、条件渲染
|
||
- [[REACT/1. 基础篇/04-State 与不可变性]] — State 设计原则与更新模式
|
||
- [[REACT/2. Hooks 篇/05-核心 Hooks]] — useState/useEffect/useContext/useRef 原理
|
||
- [[REACT/2. Hooks 篇/07-自定义 Hooks]] — 逻辑复用与常见 Hook 封装
|
||
- [[REACT/4. 进阶篇/11-组件通信模式]] — Props Drill / Context / 状态管理库方案对比
|
||
- [[REACT/3. 生态工具篇/09-状态管理]] — Context API vs Zustand vs Redux Toolkit
|
||
- [[REACT/5. 工程实践篇/15-性能优化]] — React.memo / 虚拟列表 / Code Splitting
|