降低类型使用成本 about uni-app-types

[Megasu]

现在的临时解决方案，通过 any 屏蔽掉错误，内部再通过 as 断言指定正确的类型：

const onSwiperChange = (ev: any) => {
  activeIndex.value = (ev as WechatMiniprogram.SwiperChange).detail.current
}

期待的解决方案：

const onSwiperChange = (ev: WechatMiniprogram.SwiperChange) => {
  activeIndex.value = ev.detail.current
}

[ModyQyW]

@uni-helper/[email protected] 已经发布，如无意外应该会是 0.3.0 前最后一个测试版本。后续 uni-ui-types 和 uni-cloud-types 会跟进。

[ModyQyW]

@uni-helper/uni-ui-types 和 @uni-helper/uni-cloud-types 已经跟进完毕了。如果没有什么问题，周三或者周四就会发三个包的 0.3.0。

这个 issue 就先关掉了，有问题可以另开 issue，谢谢。

[ModyQyW]

按我的理解，你这里提出的是两个问题的结合。

第一个问题：怎么为回调事件标注类型？实际上，@uni-helper/uni-app-types 导出了相关的类型，你可以导入后使用。

<script setup lang="ts">
import type { SwiperProps } from '@uni-helper/uni-app-types';

const onSwiperChange: SwiperProps['onChange'] = (event) => {
  activeIndex.value = event.detail?.current ?? activeIndex.value;
};
</script>

第二个问题：能不能支持小程序平台原生类型？这有待商榷。原因如下：

1. uni-app 修改了底层事件处理以适配不同的小程序平台，所以事件回调参数不能使用小程序平台的原生类型。官方没有明确说明这一点，我在实际开发中发现确实会有这种情况发生。
2. 目前我知道的，只有微信小程序和支付宝小程序提供了事件类型，没法覆盖全部小程序平台。

如果我误会了你的意思，请指出，我们友好讨论，谢谢。@Megasu

[Megasu]

@ModyQyW Hi，作者你好

其实我的问题应该是：能不能支持小程序平台原生类型？(问题二)

关于问什么

1. 小程序平台主要是微信小程序平台为主。
2. 只有微信小程序和支付宝小程序提供了事件类型。
3. 开发者实际开发体验和书写成本问题。

期待

支持小程序平台原生类型的写法：

<script setup lang="ts">
const onSwiperChange = (ev: WechatMiniprogram.SwiperChange) => {
  activeIndex.value = ev.detail.current
}
</script>

目前 @uni-helper/uni-app-types 导出的类型使用成本有点高：

<script setup lang="ts">
import type { SwiperProps } from '@uni-helper/uni-app-types';

const onSwiperChange: SwiperProps['onChange'] = (event) => {
  activeIndex.value = event.detail?.current ?? activeIndex.value;
};
</script>

讨论

关于作者提及的这两点：

1. uni-app 修改了底层事件处理以适配不同的小程序平台，所以事件回调参数不能使用小程序平台的原生类型。官方没有明确说明这一点，我在实际开发中发现确实会有这种情况发生。
2. 目前我知道的，只有微信小程序和支付宝小程序提供了事件类型，没法覆盖全部小程序平台。

这两天我也有在思考，大致想到的方案如下：

1. 是否可以把类型分为两部分，一部分是组件属性的类型，一部分是组件的事件类型，开发者自行选择。
2. 不提供组件的事件类型，由开发者根据自己要兼容的平台自行指定。(因为没法覆盖全部小程序平台)
3. 考虑支持以下写法，兼容已知的微信小程序和支付宝小程序提供的事件类型：

<script setup lang="ts">
const onSwiperChange = (ev: UniHelper.SwiperChange) => {
  activeIndex.value = ev.detail.current
}
</script>

平衡

我提建议的依据主要是由两点：

1. 作者维护成本问题，作者维护成功不能过高，毕竟平台会持续更新，最好能自动化完成。
2. 开发者使用成本问题，开发者书写不能太高，否则开发的实际体验会大打折扣。

感谢

🌹 感谢作者的开源贡献。

[ModyQyW]

这两天我也有在思考，大致想到的方案如下：

1. 是否可以把类型分为两部分，一部分是组件属性的类型，一部分是组件的事件类型，开发者自行选择。
2. 不提供组件的事件类型，由开发者根据自己要兼容的平台自行指定。(因为没法覆盖全部小程序平台)
3. 考虑支持以下写法，兼容已知的微信小程序和支付宝小程序提供的事件类型

1 是可以的，但是需要考虑下拆分后命名的问题，避免出现误导。
2 不提供会降低开发者体验，既然叫做 uni-app-types，应该要提供 uni-app 文档上有的类型才对。
3 很合理，也能降低类型使用成本，就是 namespace 需要确认一下。

综上所述，我觉得可以在 0.3.0 加入你第一点和第三点建议，第二点建议会降低开发者体验，不做考虑。这可能会是一个 breaking change，而且uni-cloud-types 和 uni-ui-types 也会跟随以上改动，所以我必须仔细斟酌一下，请见谅。如果你有兴趣，也欢迎 PR。

[Megasu]

🌹，期待中。

[ModyQyW]

应该会重点参考 @dcloudio/types 和 element-plus 的类型。

可能会在1-2个月内完成。

[Megasu]

如果你有兴趣，也欢迎 PR。

作者您设计好 0.3.0 的架子和 PR 要求，我和我的小伙伴可以立刻跟进，共同为前端生态做点贡献。🌹

[ModyQyW]

已经发布 0.3.0 了。有问题可以提 issue 或者 PR 的。谢谢。

[Megasu]

感谢~

[Megasu]

之前提出兼容小程序端类型的想法有局限性，需求应该是 UniHelper 提供 event 事件类型。

<script setup lang="ts">
const onSwiperChange = (ev: UniHelper.SwiperOnChangeEvent) => {
  activeIndex.value = ev.detail.current
}
</script>