为什么不应该在 Sidebar 组件中直接使用 useSessions Hook

引言#

在 React 开发中，我们经常面临一个重要的架构决策：是否应该让组件直接使用业务逻辑 hooks，还是通过 props 传递数据和回调函数？本文将通过一个实际的聊天应用案例，分析为什么建议保持组件的数据流清晰，而不是在组件中直接使用业务逻辑 hooks。

问题背景#

在我们的聊天应用中，有一个 Sidebar 组件负责显示聊天会话列表。最初的设计是：

1
// 当前架构：通过 props 传递数据
2
<Sidebar
3
  sessions={sessions}
4
  currentSessionId={currentSessionId}
5
  onSelectSession={selectSession}
6
  onNewSession={createNewSession}
7
  onDeleteSession={deleteSession}
8
  isOpen={sidebarOpen}
9
  onToggle={() => setSidebarOpen(!sidebarOpen)}
10
/>

有人可能会问：为什么不直接在 Sidebar 组件中使用 useSessions hook 呢？

1
// 不推荐的架构：直接在组件中使用 hook
2
export function Sidebar() {
3
  const {
4
    sessions,
5
    currentSessionId,
6
    selectSession,
7
    createNewSession,
8
    deleteSession,
9
  } = useSessions();
10
  // ...
11
}

为什么不建议在组件中直接使用业务逻辑 Hooks？#

1. 关注点分离 (Separation of Concerns)#

组件应该专注于 UI 渲染，而不是业务逻辑

1
// ✅ 好的做法：纯展示组件
2
export function Sidebar({
3
  sessions,
4
  onSelectSession,
5
  onNewSession,
6
  onDeleteSession,
7
}) {
8
  return (
9
    <div>
10
      {sessions.map((session) => (
11
        <button key={session.id} onClick={() => onSelectSession(session.id)}>
12
          {session.title}
13
        </button>
14
      ))}
15
    </div>
16
  );
17
}
18

19
// ❌ 不好的做法：组件混合了业务逻辑
20
export function Sidebar() {
21
  const { sessions, selectSession } = useSessions(); // 业务逻辑混入组件
22
  // ...
23
}

2. 可测试性 (Testability)#

纯组件更容易进行单元测试

1
// ✅ 容易测试：只需要模拟 props
2
test("Sidebar renders sessions correctly", () => {
3
  const mockSessions = [
4
    { id: "1", title: "Chat 1" },
5
    { id: "2", title: "Chat 2" },
6
  ];
7

8
  render(<Sidebar sessions={mockSessions} onSelectSession={jest.fn()} />);
9

10
  expect(screen.getByText("Chat 1")).toBeInTheDocument();
11
  expect(screen.getByText("Chat 2")).toBeInTheDocument();
12
});
13

14
// ❌ 难以测试：需要模拟 hook 和依赖
15
test("Sidebar with useSessions", () => {
16
  // 需要模拟 useSessions hook
17
  jest.mock("./useSessions", () => ({
18
    useSessions: () => ({
19
      sessions: mockSessions,
20
      selectSession: jest.fn(),
21
    }),
22
  }));
23
  // 测试变得复杂...
24
});

3. 可复用性 (Reusability)#

纯组件可以在不同场景下复用

1
// ✅ 可以在不同场景下复用
2
// 场景1：聊天应用
3
<Sidebar sessions={chatSessions} onSelectSession={handleChatSelect} />
4

5
// 场景2：文件管理器
6
<Sidebar sessions={fileSessions} onSelectSession={handleFileSelect} />
7

8
// 场景3：测试环境
9
<Sidebar sessions={mockSessions} onSelectSession={mockHandler} />

4. 状态管理集中化 (Centralized State Management)#

所有状态变化都在一个地方管理，便于调试

1
// ✅ 状态管理集中化
2
export function useChat() {
3
  const { sessions, selectSession, createNewSession, deleteSession } =
4
    useSessions();
5
  const { messages, sendMessage } = useMessages();
6
  const { user, logout } = useAuth();
7

8
  // 所有业务逻辑都在这里
9
  const handleSessionSelect = async (sessionId: string) => {
10
    await selectSession(sessionId);
11
    await loadMessages(sessionId);
12
  };
13

14
  return {
15
    sessions,
16
    onSelectSession: handleSessionSelect,
17
    // ...
18
  };
19
}

5. 数据流清晰 (Clear Data Flow)#

遵循 React 的数据流原则：props 向下，事件向上

1
// ✅ 清晰的数据流
2
App
3
├── useChat (业务逻辑层)
4
│   ├── useSessions
5
│   ├── useMessages
6
│   └── useAuth
7
└── Chat (组件层)
8
    └── Sidebar (纯展示组件)
9
        ├── sessions (props 向下)
10
        ├── onSelectSession (事件向上)
11
        └── onNewSession (事件向上)

6. 便于调试和维护 (Debugging and Maintenance)#

当出现问题时，可以快速定位到业务逻辑层

1
// ✅ 问题定位清晰
2
// 如果会话选择有问题，直接查看 useChat 中的 handleSessionSelect
3
// 如果 UI 显示有问题，直接查看 Sidebar 组件的渲染逻辑
4

5
// ❌ 问题定位困难
6
// 如果直接在 Sidebar 中使用 useSessions，问题可能分散在多个地方

实际案例分析#

让我们看看当前项目中的实现：

当前架构的优势#

1
// useChat.ts - 业务逻辑集中管理
2
export function useChat() {
3
  const { sessions, selectSession, createNewSession, deleteSession } =
4
    useSessions();
5

6
  // 包装业务逻辑，添加额外的处理
7
  const selectSessionWrapper = async (sessionId: string) => {
8
    clearMessages(); // 清除当前消息
9
    setRequest(""); // 清空输入
10
    setError(""); // 清除错误
11
    await selectSession(sessionId);
12
    await loadChatMessages(sessionId); // 加载消息
13
  };
14

15
  return {
16
    sessions,
17
    onSelectSession: selectSessionWrapper,
18
    // ...
19
  };
20
}
21

22
// Chat.tsx - 组件层
23
export function Chat() {
24
  const { sessions, onSelectSession, onNewSession, onDeleteSession } =
25
    useChat();
26

27
  return (
28
    <Sidebar
29
      sessions={sessions}
30
      onSelectSession={onSelectSession}
31
      onNewSession={onNewSession}
32
      onDeleteSession={onDeleteSession}
33
    />
34
  );
35
}
36

37
// Sidebar.tsx - 纯展示组件
38
export function Sidebar({
39
  sessions,
40
  onSelectSession,
41
  onNewSession,
42
  onDeleteSession,
43
}) {
44
  return (
45
    <div>
46
      {sessions.map((session) => (
47
        <button key={session.id} onClick={() => onSelectSession(session.id)}>
48
          {session.title}
49
        </button>
50
      ))}
51
    </div>
52
  );
53
}

1
// ❌ 不推荐的实现
2
export function Sidebar() {
3
  const { sessions, selectSession, createNewSession, deleteSession } =
4
    useSessions();
5
  const { clearMessages, loadChatMessages } = useMessages(); // 需要额外的 hook
6

7
  const handleSelectSession = async (sessionId: string) => {
8
    clearMessages(); // 业务逻辑混入组件
9
    await selectSession(sessionId);
10
    await loadChatMessages(sessionId);
11
  };
12

13
  return (
14
    <div>
15
      {sessions.map((session) => (
16
        <button
17
          key={session.id}
18
          onClick={() => handleSelectSession(session.id)}
19
        >
20
          {session.title}
21
        </button>
22
      ))}
23
    </div>
24
  );
25
}

何时可以考虑在组件中使用 Hooks？#

虽然我们建议保持组件的数据流清晰，但在某些特定情况下，可以考虑在组件中直接使用 hooks：

1. UI 相关的 Hooks#

1
// ✅ 适合在组件中使用：UI 相关的 hooks
2
export function Sidebar() {
3
  const [isOpen, setIsOpen] = useState(false);
4
  const isMobile = useMediaQuery("(max-width: 768px)");
5

6
  return (
7
    <div className={isMobile ? "mobile-layout" : "desktop-layout"}>
8
      {/* ... */}
9
    </div>
10
  );
11
}

2. 组件内部状态管理#

1
// ✅ 适合在组件中使用：组件内部状态
2
export function Sidebar() {
3
  const [searchTerm, setSearchTerm] = useState("");
4
  const [sortBy, setSortBy] = useState("date");
5

6
  const filteredSessions = useMemo(() => {
7
    return sessions.filter((session) =>
8
      session.title.toLowerCase().includes(searchTerm.toLowerCase()),
9
    );
10
  }, [sessions, searchTerm]);
11

12
  return (
13
    <div>
14
      <input
15
        value={searchTerm}
16
        onChange={(e) => setSearchTerm(e.target.value)}
17
      />
18
      {filteredSessions.map((session) => (
19
        <SessionItem key={session.id} session={session} />
20
      ))}
21
    </div>
22
  );
23
}

3. 第三方库的 Hooks#

1
// ✅ 适合在组件中使用：第三方库的 hooks
2
export function Sidebar() {
3
  const { data, loading, error } = useQuery(["sessions"], fetchSessions);
4
  const { mutate: deleteSession } = useMutation(deleteSessionApi);
5

6
  if (loading) return <Spinner />;
7
  if (error) return <ErrorMessage error={error} />;
8

9
  return (
10
    <div>
11
      {data.map((session) => (
12
        <SessionItem key={session.id} session={session} />
13
      ))}
14
    </div>
15
  );
16
}

最佳实践总结#

1. 分层架构#

1
业务逻辑层 (Hooks)
2
├── useChat
3
├── useSessions
4
├── useMessages
5
└── useAuth
6

7
组件层 (Components)
8
├── Chat
9
├── Sidebar
10
├── MessageList
11
└── ChatInput

2. 数据流原则#

Props 向下传递：数据从父组件流向子组件
事件向上传递：用户交互从子组件流向父组件
业务逻辑集中：所有业务逻辑都在 hooks 中处理

3. 组件设计原则#

单一职责：每个组件只负责一个功能
纯函数：组件应该是纯函数，相同的 props 产生相同的输出
可测试：组件应该易于测试
可复用：组件应该可以在不同场景下复用

结论#

虽然在某些情况下可以在组件中直接使用业务逻辑 hooks，但为了保持代码的可维护性、可测试性和可复用性，建议遵循以下原则：

保持组件的数据流清晰：通过 props 传递数据，通过回调函数处理事件
集中管理业务逻辑：将所有业务逻辑放在专门的 hooks 中
关注点分离：组件专注于 UI 渲染，hooks 专注于业务逻辑
遵循 React 最佳实践：props 向下，事件向上

这种架构模式不仅符合 React 的设计理念，也为项目的长期维护和扩展奠定了良好的基础。

本文基于实际项目经验总结，希望对您的 React 开发有所帮助。如果您有任何问题或建议，欢迎讨论交流。

引言#