vault backup: 2026-04-29 23:36:32
This commit is contained in:
+205
-52
@@ -1,5 +1,5 @@
|
||||
---
|
||||
tags: [React, Component Communication, Props, Context, Frontend]
|
||||
tags: [React, Component Communication, Props, Context, State Lifting, Frontend]
|
||||
create time: 2026-04-29 22:10
|
||||
---
|
||||
|
||||
@@ -7,7 +7,12 @@ create time: 2026-04-29 22:10
|
||||
|
||||
## 概述
|
||||
|
||||
React 中父子组件之间的数据流动有多种方式。理解每种模式的适用场景和性能影响，能够避免过度设计或通信瓶颈。本文档从简单到复杂，梳理完整的通信方案谱系。
|
||||
React 的核心理念是 **"单向数据流"** ——数据从父组件流向子组件，事件从子组件冒泡回父组件。但在真实项目中，组件层级可以很深、结构可以很散，跨组件共享状态成为日常需求。
|
||||
|
||||
本文档梳理 React 中所有主流的组件通信方式，从最基础的 Props 到状态管理库，帮助你根据实际场景选择最合适方案。
|
||||
|
||||
> [!question] 思考题
|
||||
> 假设你有一个 6 层深的组件树，最顶层需要把 `theme` 传给第 6 层的按钮组件。你会怎么做？逐层透传 Props 似乎笨拙，但引入 Context 又可能引发不必要的重渲染——你怎么权衡？
|
||||
|
||||
## 通信方向全景图
|
||||
|
||||
@@ -16,14 +21,14 @@ graph TD
|
||||
A["父 → 子"] --> B["Props（最基础）"]
|
||||
A --> C["Context Provider（跨层级）"]
|
||||
A --> D["状态管理库（全局共享）"]
|
||||
|
||||
|
||||
E["子 → 父"] --> F["回调 Prop（事件驱动）"]
|
||||
E --> G["refs（imperative）"]
|
||||
|
||||
E --> G["Refs（imperative）"]
|
||||
|
||||
H["兄弟组件"] --> I["状态提升到共同父组件"]
|
||||
H --> J["通过共同祖先通信"]
|
||||
H --> K["状态管理库 / 发布订阅"]
|
||||
|
||||
|
||||
style B fill:#4FC08D,color:#fff
|
||||
style C fill:#F5A87D,color:#000
|
||||
style F fill:#61DAFB,color:#000
|
||||
@@ -36,30 +41,37 @@ graph TD
|
||||
```tsx
|
||||
function App() {
|
||||
const user = getUser();
|
||||
return <Header user={user} />; // Header 不需要 user，但深层的 Avatar 需要！
|
||||
return <Header user={user} />;
|
||||
// Header 不需要 user，但深层的 Avatar 需要！
|
||||
}
|
||||
|
||||
function Header({ user }) {
|
||||
return (
|
||||
<nav>
|
||||
<Logo /> {/* ❌ 无需 user，却接收了 */}
|
||||
<Avatar user={user} /> {/* ✅ 需要 */}
|
||||
<Logo />
|
||||
{/* ❌ 无需 user，却被迫接收 */}
|
||||
<Avatar user={user} />
|
||||
</nav>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
> [!tip] 何时该容忍 Props Drill？
|
||||
> 传递 2-3 层 Props 是完全合理的，甚至值得鼓励——它让数据流向清晰可见。只有超过 4 层时才考虑替代方案。
|
||||
|
||||
### 解决方案对比
|
||||
|
||||
| 方法 | 适合场景 | 额外依赖 |
|
||||
|------|----------|---------|
|
||||
| **Context** | 少量深层传递（主题、用户信息） | 无 |
|
||||
| **自定义 Hook + Props 重组织** | 中等深度（3-4 层） | 无 |
|
||||
| **状态管理库** | 频繁变化、多组件共享 | Zustand/Redux |
|
||||
| **Render Prop / HOC** | 复用逻辑而非传值 | 无 |
|
||||
| **Context** | 少量深层传递（主题、用户信息、语言设置） | 无 |
|
||||
| **自定义 Hook + Props 重组织** | 中等深度（3-4 层），只需中间层不暴露 | 无 |
|
||||
| **状态管理库** | 频繁变化、多组件共享 | Zustand / Redux Toolkit |
|
||||
| **Render Props / HOC** | 复用逻辑而非单纯传值 | 无 |
|
||||
|
||||
## Callback Prop（子 → 父）
|
||||
|
||||
这是 React 中最基础也最重要的反向通信方式：**父组件传递一个函数作为 Prop，子组件在适当时机调用它**。
|
||||
|
||||
```tsx
|
||||
interface FormProps {
|
||||
onSubmit: (data: FormValues) => Promise<void>;
|
||||
@@ -69,9 +81,9 @@ function LoginForm({ onSubmit }: FormProps) {
|
||||
const handleSubmit = (e: React.FormEvent) => {
|
||||
e.preventDefault();
|
||||
const data = collectFormData();
|
||||
onSubmit(data); // 通知父组件
|
||||
onSubmit(data); // ✅ 通知父组件
|
||||
};
|
||||
|
||||
|
||||
return <form onSubmit={handleSubmit}><Button type="submit">登录</Button></form>;
|
||||
}
|
||||
|
||||
@@ -81,75 +93,203 @@ function App() {
|
||||
await api.login(data);
|
||||
navigate("/dashboard");
|
||||
};
|
||||
|
||||
|
||||
return <LoginForm onSubmit={handleLogin} />;
|
||||
}
|
||||
```
|
||||
|
||||
> [!note] 为什么不用 props.children 做通信？
|
||||
> children 是 UI 内容插槽，不是通信机制。通信用 callback prop 保持关注点分离。
|
||||
> [!note] 为什么不用 children 做通信？
|
||||
> children 是 UI 内容插槽，不是通信机制。回调 Prop 保持关注点分离——子组件只关心"什么时候触发"，父组件决定"触发后做什么"。
|
||||
|
||||
> [!important] 性能提示：使用 useCallback
|
||||
> 如果子组件用 `React.memo` 包裹，每次父组件重新渲染都会创建新的函数引用，导致子组件无效重渲染。用 `useCallback` 缓存回调函数：
|
||||
> ```tsx
|
||||
> const handleLogin = useCallback(async (data: FormValues) => { ... }, []);
|
||||
> ```
|
||||
|
||||
## Context 跨层级通信
|
||||
|
||||
当 Props 穿透超过 3-4 层时，Context 是最轻量的替代方案。**它的本质是一个"隐式 Prop"——Provider 上方的任意后代都可以直接消费，无需经过中间组件。**
|
||||
|
||||
```tsx
|
||||
const UserContext = createContext<User | null>(null);
|
||||
|
||||
function UserProfile({ children }: { children: React.ReactNode }) {
|
||||
function UserProfileProvider({ children }: { children: React.ReactNode }) {
|
||||
const user = useDatabaseUser(userId);
|
||||
|
||||
|
||||
return (
|
||||
<UserContext.Provider value={user}>
|
||||
{/* Avatar、Settings、OrderHistory 任意深度都可消费 */}
|
||||
{children}
|
||||
{children} {/* Avatar、Settings 任意深度都可消费 */}
|
||||
</UserContext.Provider>
|
||||
);
|
||||
}
|
||||
|
||||
function OrderHistory() {
|
||||
const user = useContext(UserContext); // 直接获取，无需中间层透传
|
||||
return <div>{user?.orders?.map(...)}</div>;
|
||||
const user = useContext(UserContext); // ✅ 直接获取，跳过中间层
|
||||
return <div>{user?.orders?.map(order => <OrderItem key={order.id} order={order} />)}</div>;
|
||||
}
|
||||
```
|
||||
|
||||
> [!warning] Context 的性能陷阱
|
||||
> - Provider value 对象每次渲染都是新引用 → 所有消费者重渲染
|
||||
> - 解决：拆分 Context、或使用 `useReducer` 返回稳定的 `{state, dispatch}` 对象
|
||||
### Context 性能陷阱与最佳实践
|
||||
|
||||
```
|
||||
⚠️ 核心问题：
|
||||
Context value 改变 → Provider 下所有消费者重渲染，无论是否真的使用了这个值
|
||||
```
|
||||
|
||||
**陷阱一：value 对象每次都是新引用**
|
||||
|
||||
```tsx
|
||||
// ❌ 每次渲染都创建新对象，所有消费者必重渲染
|
||||
<UserContext.Provider value={{ user, theme }}>
|
||||
{children}
|
||||
</UserContext.Provider>
|
||||
```
|
||||
|
||||
**陷阱二：单个大 Context 包含多个独立状态**
|
||||
|
||||
```tsx
|
||||
// ❌ settings 变了，即使用户信息模块的组件也会重渲染
|
||||
<UserAndSettingsContext.Provider value={{ user, settings, locale }}>
|
||||
{children}
|
||||
</UserAndSettingsContext.Provider>
|
||||
```
|
||||
|
||||
**最佳实践：拆分成小 Context + useReducer 稳定引用**
|
||||
|
||||
```tsx
|
||||
// ✅ 拆分 Context，粒度更细
|
||||
const UserContext = createContext<User | null>(null);
|
||||
const SettingsContext = createContext<Settings>({ theme: "light" });
|
||||
|
||||
// ✅ 用 useReducer 返回稳定的 { state, dispatch } 对象
|
||||
function SettingsProvider({ children }: { children: React.ReactNode }) {
|
||||
const [settings, dispatch] = useReducer(settingsReducer, initialSettings);
|
||||
|
||||
return (
|
||||
<SettingsContext.Provider value={{ settings, dispatch }}>
|
||||
{children}
|
||||
</SettingsContext.Provider>
|
||||
);
|
||||
}
|
||||
|
||||
// 消费者只取需要的 slice
|
||||
function ThemeToggle() {
|
||||
const { settings, dispatch } = useContext(SettingsContext);
|
||||
return (
|
||||
<button onClick={() => dispatch({ type: "TOGGLE_THEME" })}>
|
||||
{settings.theme === "light" ? "☀️" : "🌙"}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## 兄弟组件通信
|
||||
|
||||
两个没有祖先后代关系的组件如何共享数据？答案是：**将状态提升到它们的共同父组件中**。
|
||||
|
||||
```tsx
|
||||
type ContactId = string;
|
||||
|
||||
function ChatApp() {
|
||||
const [contacts, setContacts] = useState<Contact[]>([]);
|
||||
const [selectedId, setSelectedId] = useState<ContactId | null>(null);
|
||||
const [messages, setMessages] = useState<Message[]>([]);
|
||||
|
||||
const selectedContact = useMemo(
|
||||
() => contacts.find(c => c.id === selectedId),
|
||||
[contacts, selectedId]
|
||||
);
|
||||
|
||||
return (
|
||||
<div className="chat-layout">
|
||||
{/* 左侧：联系人列表 */}
|
||||
<ContactList
|
||||
contacts={contacts}
|
||||
selectedId={selectedId}
|
||||
onSelect={setSelectedId}
|
||||
/>
|
||||
|
||||
{/* 右侧：聊天窗口 */}
|
||||
<ChatWindow
|
||||
contact={selectedContact}
|
||||
messages={messages.filter(m => m.contactId === selectedId)}
|
||||
onSend={(text) => setMessages(prev => [...prev, { text, contactId: selectedId!, timestamp: Date.now() }])}
|
||||
/>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
> [!diagram] 状态提升流程
|
||||
> ```mermaid
|
||||
> graph LR
|
||||
> A[ContactList] -- "onSelect(id)" --> P[ChatApp - State]
|
||||
> P -- "contact" --> B[ChatWindow]
|
||||
> P -- "onSend(text)" --> P
|
||||
> B -- "sendMessage(text)" --> P
|
||||
> style P fill:#4FC08D,color:#fff
|
||||
> ```
|
||||
|
||||
> [!tip] 何时应该使用状态提升？
|
||||
> 当兄弟组件数量少（≤ 3 个）、关系固定、状态不频繁变化时，状态提升比引入状态管理库更简单、更可维护。
|
||||
|
||||
## 状态管理库方案
|
||||
|
||||
当状态需要在整个应用中流转、涉及复杂操作逻辑或多条副作用时，Zustand / Redux Toolkit 等库提供了集中式状态容器。
|
||||
|
||||
```tsx
|
||||
// Zustand 方案：任意两个组件共享 state，无需祖先后代关系
|
||||
// Zustand：极简 API，按 slice 订阅避免全量重渲染
|
||||
import { create } from "zustand";
|
||||
|
||||
const useCartStore = create((set) => ({
|
||||
interface CartState {
|
||||
items: CartItem[];
|
||||
addItem: (item: CartItem) => void;
|
||||
removeItem: (id: string) => void;
|
||||
}
|
||||
|
||||
const useCartStore = create<CartState>((set) => ({
|
||||
items: [],
|
||||
addItem: (item) => set(state => ({ items: [...state.items, item] })),
|
||||
removeItem: (id) => set(state => ({ items: state.items.filter(i => i.id !== id) })),
|
||||
}));
|
||||
|
||||
function ProductCard() {
|
||||
const addItem = useCartStore(s => s.addItem);
|
||||
function ProductCard({ product }: { product: Product }) {
|
||||
const addItem = useCartStore(s => s.addItem); // 精确订阅，仅在 addItem 引用变化时重渲染
|
||||
return <button onClick={() => addItem(product)}>加入购物车</button>;
|
||||
}
|
||||
|
||||
function CartIcon() {
|
||||
const items = useCartStore(s => s.items);
|
||||
const items = useCartStore(s => s.items); // 仅 items 变化时重渲染
|
||||
return <Badge>{items.length}</Badge>;
|
||||
}
|
||||
// 两者毫无关联，但共享同一份状态
|
||||
```
|
||||
|
||||
> [!note] Zustand vs Redux Toolkit 选型建议
|
||||
> - **Zustand**：API 简洁、样板代码极少、支持 immer 中间件，适合中小型项目和个人项目
|
||||
> - **Redux Toolkit**：生态成熟、DevTools 体验好、middleware 体系完善（thunk/saga），适合大型团队协作项目
|
||||
> - 详见 [[hhs/REACT/3. 生态工具篇/09-状态管理.md]]
|
||||
|
||||
## Ref Imperative API（命令式通信）
|
||||
|
||||
大多数情况下 React 推崇声明式通信（Props + Callback），但在需要**直接操控子组件实例行为**时使用 refs。典型场景：触发自定义验证、聚焦输入框、播放动画。
|
||||
|
||||
```tsx
|
||||
const formRef = useRef<FormHandle>(null);
|
||||
|
||||
function Parent() {
|
||||
const handleSubmit = () => {
|
||||
formRef.current?.validate(); // 命令子组件执行方法
|
||||
formRef.current?.validate(); // 命令子组件执行
|
||||
formRef.current?.reset();
|
||||
};
|
||||
|
||||
return <><ChildForm ref={formRef} /><button onClick={handleSubmit}>提交</button></>;
|
||||
|
||||
return (
|
||||
<>
|
||||
<ChildForm ref={formRef} />
|
||||
<button onClick={handleSubmit}>提交</button>
|
||||
</>
|
||||
);
|
||||
}
|
||||
|
||||
const ChildForm = forwardRef<FormHandle>((props, ref) => {
|
||||
@@ -157,31 +297,44 @@ const ChildForm = forwardRef<FormHandle>((props, ref) => {
|
||||
validate: () => validator.validate(),
|
||||
reset: () => setFields(initialValues),
|
||||
}));
|
||||
|
||||
|
||||
return <form>...</form>;
|
||||
});
|
||||
```
|
||||
|
||||
> [!warning] 谨慎使用 Imperative Refs
|
||||
> Imperative API 打破了 React 的声明式范式。能用 declarative（状态驱动 UI）解决的问题，永远不要上 imperative（直接操控 DOM）。过度使用会导致：难以测试、时序 bug、调试困难。
|
||||
|
||||
## 决策树
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["需要通信？"] -->|"是"| B["通信范围？"]
|
||||
|
||||
B --> C["仅父子两层"]
|
||||
B --> D["多层级穿透"]
|
||||
B --> E["跨层级 + 兄弟之间"]
|
||||
B --> F["需命令式调用子组件方法"]
|
||||
|
||||
C --> G["Props + Callback ✅"]
|
||||
D --> H["Context ✅"]
|
||||
E --> I["Zustand / Redux ✅"]
|
||||
F --> J["forwardRef + useImperativeHandle ✅"]
|
||||
|
||||
style G fill:#4FC08D,color:#fff
|
||||
style H fill:#61DAFB,color:#000
|
||||
style I fill:#F5A87D,color:#000
|
||||
style J fill:#A0AEC0,color:#000
|
||||
START["需要组件通信？"] -->|"否"| DONE["无需处理 ✅"]
|
||||
START -->|"是"| RANGE["通信范围？"]
|
||||
|
||||
RANGE --> PARENT_CHILD["仅父子两层<br/>（1-2 级深度）"]
|
||||
RANGE --> DEEP["多层级穿透<br/>（≥ 3 级深度）"]
|
||||
RANGE --> SIBLING["兄弟组件 / 无关组件"]
|
||||
RANGE --> IMPERATIVE["需命令式调用子组件方法"]
|
||||
|
||||
PARENT_CHILD --> PROP["Props + Callback ✅<br/>简单、直观、可追踪"]
|
||||
DEEP --> CTX["Context ✅<br/>配合 useReducer 保证性能"]
|
||||
SIBLING --> SLIFTING["状态提升到共同父 ✅"]
|
||||
SIBLING --> STORE["状态管理库（复杂场景）"]
|
||||
IMPERATIVE --> REF["forwardRef +<br/>useImperativeHandle ✅"]
|
||||
|
||||
style PROP fill:#4FC08D,color:#fff
|
||||
style CTX fill:#F5A87D,color:#000
|
||||
style SLIFTING fill:#61DAFB,color:#000
|
||||
style STORE fill:#C084FC,color:#fff
|
||||
style REF fill:#A0AEC0,color:#000
|
||||
```
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/REACT/1. 基础篇/03-组件与 Props.md]] — Props 类型校验、组件拆分原则
|
||||
- [[hhs/REACT/2. Hooks 篇/05-核心 Hooks.md]] — useContext / useRef 原理
|
||||
- [[hhs/REACT/2. Hooks 篇/06-性能优化 Hooks.md]] — 配合 Context 的性能优化手段
|
||||
- [[hhs/REACT/4. 进阶篇/12-HOC 与 Render Props.md]] — 高阶组件与 Render Props 进阶
|
||||
- [[hhs/REACT/3. 生态工具篇/09-状态管理.md]] — Zustand / Redux Toolkit 选型对比
|
||||
- [[hhs/REACT/5. 工程实践篇/15-性能优化.md]] — React.memo、虚拟列表、Bundle 分析
|
||||
|
||||
Reference in New Issue
Block a user