为何在React的useState中存储组件属于不良实践？

const [Component, setComponent] = useState<JSX.Element>(<Empty />);

我想基于多个互斥条件进行组件的条件渲染，但在实际渲染前要添加防抖（无操作x毫秒后延迟渲染）。这种场景下直接将组件赋值为状态值似乎更直观且代码量更少，我也可以用状态存储文本值，再通过映射表关联组件，但感觉没必要。网上提到这属于不良实践，应仅在状态中存储数据，但没人说明具体原因，官方文档也未提及这是不良实践。

以下是一个可运行示例，展示将组件存入状态的便捷性。所有Message组件均通过React.memo进行记忆化处理，不会出现props变更问题：

import React, { useState, useEffect } from 'react';
import useDebounce from '../../hooks/useDebounce';
import {
  TooShort,
  NoPrompt,
  LimitWarning,
  LimitReached,
  Empty,
} from './Messages';

interface Props {
  promptAreaTouched: boolean;
  promptText: string;
  debounceTimeout?: number;
}

const DEBOUNCE_TIMEOUT = 2000;
const SHORT_PROMPT_LENGTH = 5;
const APPROACHING_PROMPT_LENGTH = 40;
const MAX_PROMPT_LENGTH = 50;

const PromptLengthMessage = ({
  promptAreaTouched,
  promptText,
  debounceTimeout = DEBOUNCE_TIMEOUT,
}: Props) => {
  const [Component, setComponent] = useState<JSX.Element>(<Empty />);
  const DebouncedComponent = useDebounce(Component, debounceTimeout);

  const numWords = promptText.split(/\s+/).length;

  const isEmpty = promptAreaTouched && promptText.length === 0;
  const isTooShort = promptAreaTouched && numWords <= SHORT_PROMPT_LENGTH;
  const limitWarning =
    numWords >= APPROACHING_PROMPT_LENGTH && numWords < MAX_PROMPT_LENGTH;
  const limitReached = numWords >= MAX_PROMPT_LENGTH;

  useEffect(() => {
    switch (true) {
      case isEmpty:
        setComponent(<NoPrompt />);
        break;
      case isTooShort:
        setComponent(<TooShort />);
        break;
      case limitWarning:
        setComponent(<LimitWarning />);
        break;
      case limitReached:
        setComponent(<LimitReached />);
        break;
      default:
        setComponent(<Empty />);
    }
  }, [promptText]);

  return DebouncedComponent === Component ? DebouncedComponent : <Empty />;
};

export default PromptLengthMessage;

为什么不建议把组件存在状态里？ #

• 违背React状态设计逻辑：React状态的核心是存储驱动UI的数据，而非UI本身。组件是数据渲染后的产物，把它存在状态里会让数据和UI强耦合，后续维护时很难快速理清“数据如何映射到UI”的逻辑链条。
• 隐藏依赖易出bug：你示例里的useEffect只依赖了promptText，但组件渲染实际还受promptAreaTouched影响——如果这个值变化，状态里的组件不会自动更新，除非手动把它加到依赖数组里。这种隐藏的依赖很容易引发“状态和UI不同步”的问题。
• 存在性能浪费：每次调用setComponent(<XXX />)时，都会创建一个新的组件实例对象。React会对比新旧对象的引用，只要引用变了就会触发重渲染。相比存储字符串/枚举值（比如'empty'、'tooShort'），组件对象的引用变更频率更高，可能带来不必要的重渲染。
• 调试难度飙升：在React DevTools里查看状态时，看到的是一个组件对象，很难直接判断当前应该渲染什么内容；如果存储的是数据标识，一眼就能看出当前状态对应的UI逻辑。

更合理的替代方案 #

其实只需把状态改成存储组件标识（比如字符串），再通过映射表匹配组件，代码量没增加多少，还能规避上述问题：

import React, { useState, useMemo } from 'react';
import useDebounce from '../../hooks/useDebounce';
import {
  TooShort,
  NoPrompt,
  LimitWarning,
  LimitReached,
  Empty,
} from './Messages';

interface Props {
  promptAreaTouched: boolean;
  promptText: string;
  debounceTimeout?: number;
}

const DEBOUNCE_TIMEOUT = 2000;
const SHORT_PROMPT_LENGTH = 5;
const APPROACHING_PROMPT_LENGTH = 40;
const MAX_PROMPT_LENGTH = 50;

// 组件映射表
const COMPONENT_MAP = {
  empty: Empty,
  noPrompt: NoPrompt,
  tooShort: TooShort,
  limitWarning: LimitWarning,
  limitReached: LimitReached,
};

const PromptLengthMessage = ({
  promptAreaTouched,
  promptText,
  debounceTimeout = DEBOUNCE_TIMEOUT,
}: Props) => {
  const numWords = promptText.split(/\s+/).length;

  // 计算当前应显示的组件标识
  const componentKey = useMemo(() => {
    if (promptAreaTouched && promptText.length === 0) return 'noPrompt';
    if (promptAreaTouched && numWords <= SHORT_PROMPT_LENGTH) return 'tooShort';
    if (numWords >= APPROACHING_PROMPT_LENGTH && numWords < MAX_PROMPT_LENGTH) return 'limitWarning';
    if (numWords >= MAX_PROMPT_LENGTH) return 'limitReached';
    return 'empty';
  }, [promptAreaTouched, promptText, numWords]);

  // 防抖处理组件标识
  const debouncedComponentKey = useDebounce(componentKey, debounceTimeout);

  // 根据标识获取对应组件
  const CurrentComponent = COMPONENT_MAP[debouncedComponentKey];
  const OriginalComponent = COMPONENT_MAP[componentKey];

  return debouncedComponentKey === componentKey ? <CurrentComponent /> : <Empty />;
};

export default PromptLengthMessage;

这个方案的优势：

• 状态存储轻量字符串，引用稳定，减少不必要的重渲染
• 依赖关系完全透明，所有影响UI的变量都在useMemo依赖数组里，不会出现隐藏bug
• 逻辑流程清晰：数据→标识→组件，调试和维护更方便

内容的提问来源于stack exchange，提问作者Matthew