大家好，我是前端西瓜哥。
最近公司的项目用的 React 从 16 升到了 17 版本，选择升级的原因是想以后将项目迁移到 Nextjs 上。
结果发现因为 React 的行为不一致导致了一些看得见的和看不见的 bug，真的是一场灾难。
React 17 是一个比较特别的版本，它没有任何新特性，但它改造了 React 的底层，让 React 17 可以渐进式地升级部分的模块，为 18 版本做准备。
这些改造，有一部分是破坏性的。
问题
我这里有个弹窗，弹窗里面是一些表单项。当用户在表单项做了一些修改，然后点击弹窗的遮罩层时，里面的组件会销毁掉。
在销毁时，我们会调用一个 ref 上的 save() 方法来保存这些数据。
useEffect(() => {
return () => {
formRef.current && formRef.current.save();
}
}, []);
在 React 16 的时候是正常的，但到 React 17，失败了，我们无法保存表单里面的数据。
一顿排查之后，我找到了问题所在：在 React 17 版本，组件销毁时获取的 ref.current 可能会被重置为 null。
接着我找到了官方文档对于这种情况的说明：
https://zh-hans.reactjs.org/blog/2020/08/10/react-v17-rc.html#effect-cleanup-timing
useEffect 的清理时机
useEffect(() => {
return () => {
// 这里的执行清理操作
}
})
在 React 17 中，副作用的执行时机发生了变化，一个破坏性的效果是：如果组件卸载，副作用的清理时机是异步的，对应的回调函数执行也同样是异步的。是的，异步。
卸载时的要执行的回调函数，对于状态和方法的访问，问题不大，它们是不可变的，能通过闭包的方式访问到的。
但问题是 ref，它是可变的，我们可以随意的设置 ref.current 的值，且不会触发组件的重新渲染。
这个 ref 会被 React 在组件卸载时重置为 null。因为是异步的，所以我们有很大可能会喜提一个 null 值。
这里有一个简单的在线 demo，感兴趣可以看看，当 Component 组件销毁时，elRef 变成了 null：
https://codesandbox.io/s/react-17-zhong-zu-jian-xiao-hui-shi-ref-ke-neng-bei-she-zhi-wei-null-2kl4xu。
然后是 React 16 版本的 ref，因为是同步的，所以销毁时 ref 没有重置为 null：
https://codesandbox.io/s/16-de-ref-shi-zheng-chang-de-18mqmd。
解决方案
官方的文档提供了两个解决方案。
一个是用 useLayoutEffect。
useLayoutEffect(() => {
return () => {
formRef.current && formRef.current.save();
}
}, []);
useLayoutEffect 可以保证回调函数 同步 执行，这样就能确保 ref 此时还是最后的值，而不是被设置为 null。
第二种方式是用一个临时变量在 ref 每次变化时，将 ref.current 保存起来，放到副作用清理回调函数的闭包中，来保证不可变性。
useEffect(() => {
const instance = someRef.current;
instance.someSetupMethod();
return () => {
instance.someCleanupMethod();
};
});
但这里貌似还是有一点局限性：不能提供第二个参数，也就是依赖项参数，因为我们不能保证中途 ref 没有发生改变。
目前我是用第一种方案来处理我遇到的问题。
结尾
版本升级这件事情，还是得权衡利弊。
