精读《@types/react 值得注意的 TS 技巧》

[ascoders]

持续寻找高质量前端周刊真不容易，前端周刊现在有大量新闻稿类的与深度万字入门文章类，都不太有营养，本周还是继续从官方资源挖掘信息吧，读一读 react 的类型定义文件，学习与分享一些 TS 技巧。

---

精读《@types react 值得注意的 TS 技巧》

[dancerphil]

@types/react 属于有精华也有糟粕吧，单说 TS 技巧确实值得学习

[ascoders]

一定有糟粕，但整体看下来有很多值得学习的地方。

[sl1673495]

@types/react 属于有精华也有糟粕吧，单说 TS 技巧确实值得学习

请教下糟粕是指哪部分~

[dancerphil]

@types/react 属于有精华也有糟粕吧，单说 TS 技巧确实值得学习

请教下糟粕是指哪部分~

我也是一直观察 @types/react 的 issue 和 pr。

我说的糟粕主要是说和 react 的实现上的 gap，而且这个 gap 不小。

---

1. react 本身是非常复杂且灵活的，有很多意想不到的用法。

   比如 react 和 web-component 一起用可不可以呢？但相应的类型上的实现就很难兼顾到所有的用法。

   比如我给 @types/react 提的一个 pr，https://zhuanlan.zhihu.com/p/98485133 ，事实上我觉得是一个比较常用的用法了，但是在我实现之前依旧也是没有的。

2. 版本号限制

   @types/react 是不能随意发布 breaking change 的。

   这些 breaking change 必须在 react@17 发布后跟进相应的版本的时候，顺便的带上，所以很多实现之前有坑的地方就会累积，很多想要的变更也会被推迟。

   比如 hooks 出现后，StatelessFunctionComponent 事实上不能这么叫了，但是这个接口还会保留很久。

   再比如 FC<Props> 里会自带一个 children，这样其实不能定义出 不接受 children 的组件 如果想要改掉这里势必会有很大的 breaking，所以也不能改。（站在我的角度感觉现在这样挺好的，只是举个例子）

3. 第三方开发者维护带来的问题

   比如 useReducer （我最熟哈哈），有一些看似奇怪的重载，一度使我的 pr 陷入了讨论，刚开始我和审稿人都没看懂，后来才得知相应的信息。第一手资料其实就是一份代码而已。

   兼职维护还有一个问题，很多 issue 提出，如果不是特别重要也不太管，有 pr 了看一眼而已。比如我虽然蹭了个 author，却基本不管，时区问题，具体的 pr 的 case 根本没遇到过，等等。

---

我一时间想到的是这些，这都是很具体的，很 corner case 的问题。

TypeScript 像是一个很标准的正方形，它却要 100% 适应 JavaScript 这样很容易奇形怪状的具体实现。这是其中的困难之处。我不认为其中有 @type/react 的实现太差，或者是 TypeScript 用的不好的问题。

它在 TypeScript 的实现上是非常优秀的，我也是从中学到了很多。

[sl1673495]

@types/react 属于有精华也有糟粕吧，单说 TS 技巧确实值得学习

请教下糟粕是指哪部分~

我也是一直观察 @types/react 的 issue 和 pr。

我说的糟粕主要是说和 react 的实现上的 gap，而且这个 gap 不小。

1. react 本身是非常复杂且灵活的，有很多意想不到的用法。
   比如 react 和 web-component 一起用可不可以呢？但相应的类型上的实现就很难兼顾到所有的用法。
   比如我给 @types/react 提的一个 pr，https://zhuanlan.zhihu.com/p/98485133 ，事实上我觉得是一个比较常用的用法了，但是在我实现之前依旧也是没有的。
2. 版本号限制
   @types/react 是不能随意发布 breaking change 的。
   这些 breaking change 必须在 react@17 发布后跟进相应的版本的时候，顺便的带上，所以很多实现之前有坑的地方就会累积，很多想要的变更也会被推迟。
   比如 hooks 出现后，StatelessFunctionComponent 事实上不能这么叫了，但是这个接口还会保留很久。
   再比如 FC<Props> 里会自带一个 children，这样其实不能定义出 不接受 children 的组件 如果想要改掉这里势必会有很大的 breaking，所以也不能改。（站在我的角度感觉现在这样挺好的，只是举个例子）
3. 第三方开发者维护带来的问题
   比如 useReducer （我最熟哈哈），有一些看似奇怪的重载，一度使我的 pr 陷入了讨论，刚开始我和审稿人都没看懂，后来才得知相应的信息。第一手资料其实就是一份代码而已。
   兼职维护还有一个问题，很多 issue 提出，如果不是特别重要也不太管，有 pr 了看一眼而已。比如我虽然蹭了个 author，却基本不管，时区问题，具体的 pr 的 case 根本没遇到过，等等。

我一时间想到的是这些，这都是很具体的，很 corner case 的问题。

TypeScript 像是一个很标准的正方形，它却要 100% 适应 JavaScript 这样很容易奇形怪状的具体实现。这是其中的困难之处。我不认为其中有 @type/react 的实现太差，或者是 TypeScript 用的不好的问题。

它在 TypeScript 的实现上是非常优秀的，我也是从中学到了很多。

受教了！谢谢，看来里面的 TS 写法还是值得学习的。

[cike8899]

    interface Component<P = {}, S = {}, SS = any> extends ComponentLifecycle<P, S, SS> { }
    class Component<P, S> {
        static contextType?: Context<any>;
        context: any;

        constructor(props: Readonly<P>);
    
        constructor(props: P, context?: any);

        setState<K extends keyof S>(
            state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
            callback?: () => void
        ): void;
        forceUpdate(callback?: () => void): void;
        render(): ReactNode;
        readonly props: Readonly<P> & Readonly<{ children?: ReactNode }>;
        state: Readonly<S>;

        refs: {
            [key: string]: ReactInstance
        };
    }

@types/react 为什么对Component用了interface又用了class，只用interface表示不行吗？@ascoders