React函数组件传状态至组件时遇闭包陷阱致回调取值为空

你遇到的回调读取到的containerName始终为空的问题，是两个React特性叠加导致的：

• 函数组件的闭包陷阱：首次渲染创建的所有函数、对象，都会固化捕获当次渲染的状态值。你初始化存在state里的frameworkComponents是首次渲染时生成的，里面的editButton绑定的onDeleteSetting，捕获的是当次渲染时初始空值的containerName，哪怕后续状态更新了，这个存进state的旧对象不会自动更新内部的引用。
• 之前尝试更新frameworkComponents的方案失效，是因为在同一个useEffect执行流中，先调用setContainerName触发状态更新、再立刻调用setFrameworkComponents时，当前执行上下文还是上一次渲染的闭包，你能拿到的containerName依然是旧的空值，更新后的配置依然绑定的是旧闭包。
• 额外提一个潜在问题：原代码中useEffect直接传入async函数的写法本身不规范，async函数会返回Promise，React会将这个Promise当成组件清理函数执行，容易引发隐蔽的运行时bug。

完全不需要把frameworkComponents存在state中，结合useRef做回调引用同步，就可以从根本上解决闭包问题：

1. 移除frameworkComponents的state包装，静态组件配置直接在渲染作用域声明即可
2. 用useRef存储最新的回调函数，作为跨渲染周期的引用桥梁——就算UxDataGrid内部缓存了早期传入的组件配置，最终触发回调时，也能通过ref拿到最新的逻辑，读取到正确的状态值
3. 移除useEffect上的async标记，保证组件生命周期逻辑的规范性

修正后核心代码 #

const DataGrid = (props) => {
  const [containerName, setContainerName] = useState("");                                                                    
  // 存储最新删除回调的ref，跨渲染周期保持引用同步
  const latestDeleteCallbackRef = useRef(null);

  // 业务删除回调，直接读取当前渲染作用域的最新状态
  const onDeleteSetting = async (settingKey) => {
    console.log("ON DELETE AND CONTAINER NAME:");
    console.log(containerName); 
  };
  // 每次渲染都将最新的回调同步到ref中
  latestDeleteCallbackRef.current = onDeleteSetting;

  // 同步外部传入的containerName
  useEffect(() => {
    if(props.containerName) {
      setContainerName(props.containerName);
    }
  }, [props.containerName]);

  // 无需将frameworkComponents存入state，渲染时直接生成最新配置
  const frameworkComponents = {
    customLoadingOverlay: LoadingOverlayTemplate,
    customNoRowsOverlay: UxDataGridCustomNoRows,
    editButton: (params) => <ViewAndDeleteSetting 
      {...params}  
      openAddConfigurationsWindow={openAddConfigurationsWindow}
      // 通过ref桥接，调用时永远拿到最新的回调逻辑
      onDeleteSetting={(key) => latestDeleteCallbackRef.current?.(key)}
    />
  };

  return (
    <UxDataGrid 
      frameworkComponents={frameworkComponents}
    />
  );
}

• 该方案适配UxDataGrid这类会内部缓存传入组件配置的第三方组件特性，从引用同步逻辑上绕开了闭包固化的问题，不需要反复更新state触发组件重渲染
• 去掉了不必要的frameworkComponents状态存储，减少了无意义的状态更新带来的性能开销
• 修复了原代码中useEffect的不规范写法，避免了潜在的运行时错误

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