使用TypeScript并升级到React 18

[flytam]

为了支持React 18，React类型定义进行了升级，其中包含了一些break change。本文将讲述在TypeScript中如何升级到React 18

React 18和Definitely Typed

在alpha和beta测试经历了相当长的一段时间后，React 18 于2022年3月29日正式发布。在第一个alpha版本发布的时候，TypeScript就提供了支持

这是通过Definitely Typed(一个社区维护的各种TypeScript类型定义的库)的类型定义实现的)来使用。感谢Sebastian Silbermann的贡献，他在React18的类型定义工作中投入了大量的精力

目前React 18已经发布并且React 18 的类型定义在 Sebastian 的pr合并后也进行了更新。许多项目会面临一些break change。本文章将介绍会产生哪些break change及如何解决

Definitely Typed和语义版本控制

开发者习惯于在使用的软件中进行语义版本控制。通常来说在主版本的修改是表明有重大更改的。这正是React从v17升级到v18所做的事

Definitely Typed是不支持语义版本控制的

这不是故意的。因为Definitely Typed特意将类型定义发布到npm的@types作用域下。例如，React的类型定义被发布到@types/react

需要注意的是，npm 建立在语义版本控制之上。为了使类型定义的使用更容易，类型定义包的版本将等同于它支持的 npm 包的版本。对于 react的18.0.0，对应的类型定义是@types/react的18.0.0

如果@types/react类型定义发生breaking change，则会发布新版本而不是增加主要或次要版本号

修改将仅应用于修订号。这样做是为了通过npm维护当前更简单的类型消费模型

React 18: 类型上的breaking change

综上所述，对于那些被广泛使用的类型定义包，都会尽量减少产生breaking change

顺便说一句，Definitely Typed自动化工具将类型定义分为三类: "深受大家喜爱(Well-liked by everyone)"、"流行(Popular)"和"关键(Critical)"。感谢Andrew Branch的分享。被广泛使用的React被认为是"关键的"

当Sebastian提交了一个pr来升级TypeScript的React类型定义时，就有机会来做一些重大的修改。这些修改可能并不都与React 18有直接关系但会修复React类型定义中长期存在的一些问题

Sebastian pr非常好，我建议你去看一下。以下是重大更改的摘要

• 移除隐式children
• 移除ReactFragment中的{}(related to 1.)
• this.context变成unkown
• Using noImplicitAny now enforces a type is supplied with useCallback
• noImplicitAny应用到useCallback
• 删除不推荐使用的类型与React官方保持一致

在上述修改中，移除隐式children是最具破坏性的。Sebastian专门写了一篇博客来解释其原因。他还写了一个codemod来有利于进行这个代码迁移

下面让我们开始将代码库的react升级到18吧！

升级

我将通过升级我阿姨的网站进行演示。这是一个简单的网站，升级的pr

首先在package.json中升级React

-    "react": "^17.0.0",
-    "react-dom": "^17.0.0",
+    "react": "^18.0.0",
+    "react-dom": "^18.0.0",

然后升级类型定义

-    "@types/react": "^17.0.0",
-    "@types/react-dom": "^17.0.0",
+    "@types/react": "^18.0.0",
+    "@types/react-dom": "^18.0.0",

升级的时候需要检查lock依赖（yarn.lock / package-lock.json等），确保只有18版本的@types/react和react。

现在依赖安装已完成，会看到以下报错

Property ‘children’ does not exist on type ‘LoadingProps’.ts(2339)

代码如下

interface LoadingProps {
  // 你会注意到这里没有 `children` 属性 - 这就是出现错误的原因
  noHeader?: boolean;
}
// if props.noHeader is true then this component returns just the icon and a message
// if props.noHeader is true then this component returns the same but wrapped in an h1
const Loading: React.FunctionComponent<LoadingProps> = (props) =>
  props.noHeader ? (
    <>
      <FontAwesomeIcon icon={faSnowflake} spin /> Loading {props.children} ...
    </>
  ) : (
    <h1 className="loader">
      <FontAwesomeIcon icon={faSnowflake} spin /> Loading {props.children} ...
    </h1>
  );

在这里看到的是去除隐式children的改动。在我们进行升级之前，所有React.Component和React.FunctionComponent都有一个children属性，它允许React用户在不声明children的情况下直接使用

升级18后就不一样了。如果有一个带有子组件，则必须显式声明这个组件的类型

在这个例子中，通过直接添加children属性的声明可以修复这个问题

interface LoadingProps {
  noHeader?: boolean;
  children: string;
}

但是，当可以让其他方式帮我们写代码的话，为什么还要写代码呢？

我们可以使用Sebastian开发的codemod来替代手动修改代码。使用它直接通过以下的命令就可以：

npx types-react-codemod preset-18 ./src

执行后，会看到如下提示：

选择a并让codemod运行。对于这个项目，有37个文件更新了。所有文件都需要进行相同的修改。在每种情况下，组件的props都被React.PropsWithChildren包起来。例如Loading组件如下

-const Loading: React.FunctionComponent<LoadingProps> = (props) =>
+const Loading: React.FunctionComponent<React.PropsWithChildren<LoadingProps>> = (props) =>

PropsWithChildren仅仅是将children属性添加，如下

type PropsWithChildren<P> = P & { children?: ReactNode | undefined };

这就解决了上面遇到的编译问题，没有类型问题报错了

总结

通过本文我们已经学习到React 18是如何出现类型的破坏性更改，并知道可以使用codemod快速进行升级