关于进一步完善组件类型声明的想法

[robinv8]

起因

开发 RN 时发现组件的部分属性有 ts 类型错误

但事实上，该属性在 RN 官方是支持的

刨根

引用组件的方式

import { ScrollView } from '@tarojs/components';

在 `node_modules` 中发现有 2 个 components，查看 2 个库 `package.json` 的 name：

• components 的 name 是 @tarojs/components
• components-rn 的 name 是 @tarojs/components-rn

但在 Taro 配置中并非发现 alias 的功能，浏览源码发现是该插件 babel-plugin-transform-imports-api 起的作用，除此之外的另一个好处在于，按需加载组件，减小包大小

plugins.push(
    [require('babel-plugin-transform-imports-api').default, {
      packagesApis: new Map([
        ['@tarojs/taro', new Set(nativeInterfaces)],
        ['@tarojs/taro-rn', new Set(nativeInterfaces)]
      ]),
      usePackgesImport: true, // Whether to use packagesImport
      packagesImport: {
        '^@tarojs/components(-rn)?$': {
          transform: '@tarojs/components-rn/dist/components/${member}'
        },
        '^@tarojs/taro(-rn)?$': {
          transform: (importName) => {
            if (nativeLibs.includes(importName)) {
              return `@tarojs/taro-rn/dist/lib/${importName}`
            } else {
              return '@tarojs/taro-rn/dist/api'
            }
          },
          skipDefaultConversion: true
        }
      }
    }],
    [require('babel-plugin-global-define'), defineConstants]
  )

查看源码发现，三端共用一套类型声明，且类型不完善。

起初的想法，在现有的类型声明文件里补全所有的类型，但有些不妥，三端组件类型各有差异，写在一个文件，会有很多冗余字段，且不能 extends 各端已有的类型声明，目前的想法，如下图：

在基础类型上实现各端类型扩展，当执行 npm run dev:* 时，动态生成该环境类型。

目前正在实现中，大家有什么好的想法，可以交流一下。

[zhiqingchen]

如果是多端同时运行调试呢？

[robinv8]

我还在想，你有啥好的建议吗？

[robinv8]

目前能想到的，如果多端同时调试，可以把多端类型合并到一起

[robinv8]

抓取各家小程序类型已实现：https://github.com/robinv8/miniapp-types

[Chen-jj]

@ZakaryCode

[ZakaryCode]

抓取多端类型是个很好的方法，但是在开发环境动态生成不同端的类型文件并不是很合理，一方面来说有点消耗开发端的性能，另一方面并不能很好的适配多端并行的场景

[robinv8]

大佬的意思是无需改进现有类型声明的方式，如果想要更新组件声明，可以在现有类型声明基础上进行扩展，例如：

import { ComponentType } from 'react'
import Taro from '@tarojs/taro'

declare module '@tarojs/taro' {
  interface Ix {
    onCashierEventReceive (cb: any): void
  }
  interface TaroStatic {
    ix: Ix
  }
}

interface PosterProps {
  posid: string
  audible?: boolean
  onSuccess?: () => void
  onFail?: () => void
  onChange?: () => void
}

declare module '@tarojs/components' {
  export const Poster: ComponentType<PosterProps>
}

大佬我理解的对不?

[ZakaryCode]

是的，可以看看如何和这个类型声明结合到一起，当然结合时还需要考虑切换框架类型（React、Vue……）

[robinv8]

开发小程序使用 Taro 自定义类型没什么问题，但对于 RN 就不太友好了，RN 上的很多属性 Taro 自定义类型都不支持，如果开发者自己扩展费时费力，我认为有现成的就应该可以直接拿来用。

大佬对我方案的质疑无非就两点：

1. 消耗开发端的性能
2. 并不能很好的适配多端并行的场景

针对问题 1，性能优化有很大空间，我可以在自己写的类型库中提前生成基础类型，也可以在用户编译的时候生成类型缓存等
针对问题 2，并行的场景，我完全可以通过 types json schema 生成和 Taro 自定义类型完全一致的类型声明，基于 types json schema 可以跟运行环境相结合，提示用户在该环境下用了哪些不支持的属性等

关于在不同框架下的类型声明，这我确实还要研究一下

[ZakaryCode]

针对问题 1，性能优化有很大空间，我可以在自己写的类型库中提前生成基础类型，也可以在用户编译的时候生成类型缓存等

这就要看具体方案，但这里对于开发者体验实际上还是会不太友好，取决于实际使用场景。以初始化项目为例，用户获得选定平台的代码提示需要在用户首次决定编译平台，生成编译平台 ts 代码，接着需要编译器重新解析 ts 代码并更新 ts server。在小微项目中这是个很快的过程，但对于大型项目来说，tsc 扫描所有的代码并更新代码提示就需要一定的时间，如果还需要等待 ts 代码更新不太能接受，同时还需要考虑并非所有编译环境都需要这个能力，譬如发版 ci 等等，使用静态类型文件可以节省很多性能。

针对问题 2，并行的场景，我完全可以通过 types json schema 生成和 Taro 自定义类型完全一致的类型声明，基于 types json schema 可以跟运行环境相结合，提示用户在该环境下用了哪些不支持的属性等

其实有 json schema 可以提供更完善的静态类型文件给到开发者自行配置就行，在编译场景下，根据编译平台和代码 ast 解析提供不支持 api 或参数的警告信息相对于生成 dts 文件开发者能够更快的获得实时反馈，这样可以不用考虑并行等场景的兼容问题，可选能力也更容易接受。

[robinv8]

理解大佬意思了，关于完善类型声明可以分多个版本，小幅迭代，在不破坏现有逻辑的基础上，可以让我深入了解 Taro。

[robinv8]

v1

结合我生成的 JSON Schema 补充 Taro compontents 类型声明，便于和各家小程序组件属性保持一致。

[robinv8]

大事记

第一版 PR 来了 #12441，该 PR 只包含同步后的组件类型声明文件，还未提交同步类型程序，原因如下：

1. 各家小程序文档参差不齐，需要花时间处理好爬虫程序，得到正确的 JSON Schema 文件
2. 组件类型大小写的问题，影响 JSON Schema 跟 Taro 组件类型声明匹配存在误差，需要花时间比对，提高类型同步程序的正确性

[robinv8]

v2

• 优化小程序组件同步脚本
• 脚本迁移到 taro-doc

[ZakaryCode]

可以考虑在这一版中加入 CI 触发脚本提交 PR

[robinv8]

v3

• 类型声明属性排序，把事件属性放到最后面

[robinv8]

已完成

[robinv8]

v4

在 taro-docs 项目中提供 canIuse 的能力
相关 issues： NervJS/taro-docs#34

初步方案

改进方案