一个始乱终弃的API —— forwardRef

大家好，我卡颂。

React的API大多设计的很优雅，比如经典的this.setState。

但有一个API从诞生之初就争议不断，甚至很多熟练的开发者都不知道这个API存在的意义。

在最新的React19中，官方团队甚至明确提出 —— 会弃用并移除这个API。

这可真是字面意义的始乱终弃。

他就是forwardRef。

他在什么背景下产生？为什么争议不断？最后为什么被弃用？本文就来聊聊forwardRef背后的故事。

欢迎围观朋友圈、加入人类高质量前端交流群，带飞

forwardRef诞生的初衷

ref是reference（引用）的缩写。既然是引用，那根据React元素类型的不同自然有不同的引用效果。

比如，传递给React Element的ref，可以获得对应原生元素实例的引用。

// domRef.current 对应 HTMLInputElement
<input ref={domRef} />

传递给类组件的ref，可以获得类组件实例的引用。

// instanceRef.current 对应 SomeClassComponent实例
<SomeClassComponent ref={instanceRef} />

由于函数组件没有对应实例，所以函数组件没有什么可引用的。

从语义来讲，函数组件自然不能接收ref prop。

但是，虽然函数组件不能接收ref prop，但有时函数组件有转发ref的需要。

比如，下述代码中的函数组件FC有个子组件input。input作为React Element，有自己的实例。

function FC() {
  return <input />;
}

如果FC的祖先元素想获得input实例的引用，就得让FC帮忙转发一下

下述代码中，FC经过forwardRef包裹，就能将子组件input的实例转发给inputRef了：

const FC = forwardRef((props, ref) => {
  return <input ref={ref}/>;
});

<FC ref={inputRef}/>

forwardRef中的forward从字面意义上讲就是转发的意思。

forwardRef的各种坑

forwardRef在使用上会带来很多不便之处，这里举几个例子。

先来看比较不起眼的坑。

如果你像下面这样写，那函数组件本身是个匿名函数，在React Dev Tools中看不到组件名：

// 匿名的函数组件
const FC = forwardRef((props, ref) => {
  return <input ref={ref}/>;
});

必须显式的再写一遍组件名才行：

// 具名的函数组件
const FC = forwardRef(function FC(props, ref) {
  return <input ref={ref}/>;
});

上面还只是小麻烦，更麻烦的是forwardRef与TS结合时造成的类型书写复杂。

如果你的函数组件接收范型类型，当该函数组件被forwardRef包裹，范型推导就会失效。

需要使用一些很hack的类型来断言forwardRef：

文章 [TypeScript + React: Typing Generic forwardRefs
](https://fettblog.eu/typescript-react-generic-forward-refs/)详细介绍了forwardRef + TS的各种坑

如果说以上坑都只是带来不便，那下面这个坑就是实打实的性能问题了。

由于forwardRef会在组件树中生成额外的层级，在应用比较庞大时可能产生性能问题。

比如，React-Redux的维护者markerikson在给React-Redux做性能基准测试时就发现，forwardRef会对页面FPS指标带来不利影响。

类似上面这些问题使forwardRef在社区的争议一直很大。

官方的态度

官方很早就意识到forwardRef的局限性，早在2019年，sebmarkbage就在RFC #107指出未来，最终会移除forwardRef。

Andrew在23年也表达过forwardRef未来一定会被移除，之所以没有立刻做，是因为移除一个被大量使用的API属于Breaking Change。

按照Semantic Versioning（即形如A.B.C的版本号格式）的定义，不向下兼容的变化需要在主版本（即A）中体现。

所以移除forwardRef就和其他Breaking Change（比如移除propTypes和defaultProps）一起被包含在v19中。

促使官方最终决定移除forwardRef的，除了来自社区的各种抱怨，还有个重要的原因 —— ref最初的语义（对实例的引用）是在类组件盛行的时代产生的。随着Hooks的崛起，函数组件的重要性远超类组件。

既然类组件终将消失在历史中，那严守ref的语义就没意义了。

不再执着于ref语义也带来了另一个源码层面的变化。

如果你细心观察会发现，对于React Element与类组件，传递进来的ref会被自动赋予对实例的引用，而传递给forwardRef的ref，需要开发者手动决定怎么用：

// domRef.current 自动获得 HTMLInputElement
<input ref={domRef} />

// instanceRef.current 自动获得 SomeClassComponent实例
<SomeClassComponent ref={instanceRef} />

forwardRef((props, ref) => {
  // 开发者自己决定将 ref.current 赋值给谁
  // ...
});

这种区别导致在类组件中，如果用解构对象的方式操作props，很可能意外将ref传递下去并自动获得实例引用。

比如下面代码中，如果otherProps中包含ref，就会被传递给SomeClassComponent并获得SomeClassComponent实例的引用：

let {myCustomProp, ...otherProps} = props;
doSomething(myCustomProp);
return <SomeClassComponent {...otherProps} />;

所以，ref与key作为JSX中两个特殊字段会被特殊处理，而其他props会被直接透传。

鉴于：

1. 未来forwardRef被废弃
2. 类组件被冷落
3. 函数组件不会自动决定ref的赋值

未来ref也将变成一个可以被透传的普通prop。

总结

本文详细解释了forwardRef：

1. 产生的背景、作用
2. 存在的问题
3. React核心团队对此的思考

往深了说，forwardRef从出现到消失，反映的其实是一个权力问题 —— 类组件失势，导致失去对ref语义的定义权。

失去底层语义的定义权，具体的实现（forwardRef）自然就不复存在了。