React状态提升层级咨询：中间组件该控状态还是提升至更高层级？

Hey there! These are such common (and totally valid) questions when you’re getting comfortable with React’s state model—let’s break them down with clear, practical examples that tie back to your scenario.

1. What’s the right level to lift state to? #

The golden rule here is: Lift state to the closest common parent component that needs to read or update that state.

Let’s translate that to your example: If your Main component only needs the result of the filter (to display filtered data) but doesn’t care about the menu’s internal state (like which filter option is selected, or whether the menu is expanded), then that menu-specific state doesn’t need to live in Main. Keep it local to the Menu component!

Only lift state when multiple components rely on the same data. For example: If both Main and another sibling component needed to know which filter was active, then you’d lift that filter value up to their shared parent.

2. Should intermediate components control state, or should everything be lifted higher? #

This depends entirely on what the state is used for:

• If the state is for the intermediate component’s own UI/logic: Keep it local. For example, if your Menu component has a toggle to show/hide filter options, that toggle state belongs in Menu—no need to pass it up to Main unless Main needs to react to the menu being open/closed.
• If the state is meant to be shared with parent or child components: Evaluate if it’s better to lift or pass callbacks. In your case, Main needs the filter criteria to update its data, so instead of lifting the menu’s filter state up to Main, have Main pass a callback prop (like onFilterSelected) to Menu. When the user picks a filter in Menu, call that callback with the new criteria, and let Main handle updating its data state.

Applying This to Your Scenario #

Here’s a quick code sketch to make this concrete:

// Main component
function Main() {
  const [rawData, setRawData] = useState(initialData);
  const [filteredData, setFilteredData] = useState(initialData);
  const [activeFilter, setActiveFilter] = useState(null);

  useEffect(() => {
    // Apply filter to raw data when the filter changes
    const updatedData = rawData.filter(item => {
      if (!activeFilter) return true;
      return item.status === activeFilter;
    });
    setFilteredData(updatedData);
  }, [activeFilter, rawData]);

  // Pass callback to Menu—Main doesn't care about Menu's internal state
  const handleFilterChange = (filterValue) => {
    setActiveFilter(filterValue);
  };

  return (
    <div>
      <Menu onFilterChange={handleFilterChange} />
      <DataDisplay data={filteredData} />
    </div>
  );
}

// Menu component (keeps its own state)
function Menu({ onFilterChange }) {
  const [selectedOption, setSelectedOption] = useState("all");
  const [isMenuExpanded, setIsMenuExpanded] = useState(false);

  const handleOptionClick = (option) => {
    setSelectedOption(option);
    // Trigger parent's callback to update the filter
    onFilterChange(option === "all" ? null : option);
  };

  return (
    <div className="menu">
      <button onClick={() => setIsMenuExpanded(!isMenuExpanded)}>
        {isMenuExpanded ? "Close Filters" : "Open Filters"}
      </button>
      {isMenuExpanded && (
        <ul>
          <li onClick={() => handleOptionClick("all")} className={selectedOption === "all" ? "active" : ""}>
            All Items
          </li>
          <li onClick={() => handleOptionClick("active")} className={selectedOption === "active" ? "active" : ""}>
            Active Items
          </li>
          <li onClick={() => handleOptionClick("completed")} className={selectedOption === "completed" ? "active" : ""}>
            Completed Items
          </li>
        </ul>
      )}
    </div>
  );
}

In this setup:

• Menu handles its own UI state (isMenuExpanded, selectedOption) because Main doesn’t need that info to function.
• Main only cares about the active filter value, which it receives via the callback—no unnecessary coupling between the two components.

Quick Best Practices to Avoid Overthinking #

• Start local: Always default to keeping state in the component that needs it first. Only lift it when you find yourself needing to share it across components.
• Follow the data flow: If state updates need to trigger changes in a parent component, use callbacks instead of lifting the entire state.
• Avoid "state bloat": Don’t put every piece of state in your top-level App component unless it’s truly global (like user authentication status).

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