🎉 Composition Api 重构计划

[XieZongChen]

说明

1. 使用 Composition Api 语法重构，文件类型依然使用 tsx
2. 参与贡献请在此 issue 中评论领取的组件
3. 重构时的思考，避免 optionsAPI 照搬 compositionAPI
4. 重构前联系管理员先进行一轮组件的 review

开发规范

https://github.com/Tencent/tdesign-vue-next/wiki/TDesign--CompositionAPI-%E5%BC%80%E5%8F%91%E8%A7%84%E8%8C%83

基础Hook:

• [x] useConfig：全局配置 hook。 @pengYYYYY
• [x] useEmitEvent: @vnues #177 (不推荐，事件参数类型不明确，建议直接使用 props.onXXX)
• [x] useDefault： 用于实现 v-model，内置受控和非受控处理。 @chaishi
• [x] useVModel： 用于实现 v-model:xxx，内置受控和非受控处理。 @chaishi
• [x] useTNode: 用于在 setup 组合 TNode，render 函数渲染 TNode 请使用 renderTNodeJSX。 @pengYYYYY
• [x] useChildComponentSlots：渲染 default slot，获取子组件 VNode。处理多种子组件创建场景。
• [x] useIcon: 多种icon的render方式 @vnues
• [x] useVirtualScroll @Louiszhai

组件

全局组件

• [x] config-provider - @pengYYYYY

基础

• [x] button - @amadeus711 #106

布局

• [x] grid - @pengYYYYY #233
• [x] layout - @pengYYYYY #233

导航

• [x] affix - @btea #105
• [x] anchor - @Blackn-L #646
• [x] breadcrumb - @Blackn-L #567
• [x] dropdown - @qunbotop #749
• [x] pagination - @youuss #282
• [x] steps - @K1nZ #584
• [x] tabs - @LeeJim #490

输入

• [x] cascader - @pengYYYYY - #585
• [x] checkbox - @whylost -#436
• [x] date-picker - @HQ-Lin #943
• [x] form - @k1nz - #782
• [x] input - @youuss #588
• [x] input-number - @youuss #588
• [x] radio - @k1nz #555
• [x] select - @pengYYYYY #965
• [x] slider - @ChrisLee0211 #552
• [x] switch -@zouhangwithsweet #434
• [x] textarea - @btea #432
• [x] transfer - @btea #496
• [x] time-picker - @uyarn #943
• [x] tree-select -@Godlike-meteor #508
• [x] upload - @pengYYYYY #427

数据展示

• [x] avatar - @vnues #160
• [x] badge - @ChrisLee0211 #402
• [x] calendar - @PsTiu #472
• [x] comment - @simpleAndElegant #263
• [x] list - @ChrisLee0211 #321
• [x] progress - @Blackn-L #276
• [x] table - @chaishi #468
• [x] tag - @higuaifan #273
• [x] tooltip- @cca313 #566
• [x] tree - @pengYYYYY #857

消息提醒

• [x] alert - @vnues #159
• [x] dialog- @vnues #312
• [x] drawer - @vnues #210
• [x] loading - @uyarn #212
• [x] message - @qunbotop #539
• [x] notification - @qunbotop #429
• [x] pop-confirm - @pengYYYYY #410
• [x] popup @ikeq #635

[chaishi]

后面会输出 TagInput，SelectInput，暂时先别做 输入框相关的组件：cascader, select, treeselect , datepicker, timepicker

[XieZongChen]

button

[uyarn]

@amadeus711 icon是在icon库中维护的 已经是用composition API的方式实现的了。

[uyarn]

loading

[Rainer-Yu]

领取 checkbox

[Rainer-Yu]

现在项目内没有lock文件, 不需要统一开发环境依赖版本吗?

[PengYYYYY]

现在项目内没有lock文件, 不需要统一开发环境依赖版本吗?

开发者的源和npm版本，node版本都会存在不一致的情况。lock可能会导致一些差异，或者一些版本未被更新的情况。 我们在ci流程会用固定的环境跑test，lint，build。

[PengYYYYY]

cascader

[Rainer-Yu]

compositionApi中 provide/inject 的 injectKey 是需要单列文件 还是统一有什么规则

[PengYYYYY]

compositionApi中 provide/inject 的 injectKey 是需要单列文件 还是统一有什么规则

目前没有统一规则，对这一块又什么想法嘛

[Rainer-Yu]

compositionApi中 provide/inject 的 injectKey 是需要单列文件 还是统一有什么规则

目前没有统一规则，对这一块又什么想法嘛

是不是可以与props定义一样由脚本生成, 可以在一部分组件重构后进行尝试 同时希望 开放仓库的 discussions 进行社区讨论

[PengYYYYY]

compositionApi中 provide/inject 的 injectKey 是需要单列文件 还是统一有什么规则

目前没有统一规则，对这一块又什么想法嘛

是不是可以与props定义一样由脚本生成, 可以在一部分组件重构后进行尝试 同时希望 开放仓库的 discussions 进行社区讨

已放开讨论

[youuss]

领取 pagination

[qunbotop]

领取 divider

[higuaifan]

领取 tag

[higuaifan]

有些公共方法会出现一些不兼容的情况， 例如emitEvent这个，老版本的写法是用vm: ComponentPublicInstance的， 如果迁移到composition api上的话，getCurrentInstance获取到的是ComponentInternalInstance类型， 原本的$props和$emit都要改成props和emit。 类似于这种情况是在emitEvent后新起一个func保证兼容性以及方便后期统一替换，还是有别的方案呢？

以及类似于这类问题是放issue还是到开发指南的discussions上去。。

[PengYYYYY]

有些公共方法会出现一些不兼容的情况， 例如emitEvent这个，老版本的写法是用vm: ComponentPublicInstance的， 如果迁移到composition api上的话，getCurrentInstance获取到的是ComponentInternalInstance类型， 原本的$props和$emit都要改成props和emit。 类似于这种情况是在emitEvent后新起一个func保证兼容性以及方便后期统一替换，还是有别的方案呢？

以及类似于这类问题是放issue还是到开发指南的discussions上去。。

关于迁移compositionAPI的差异问题，新起一个 discussions 。 关于emitEvent 以及其他公共 func 可以起一个新的 func 先保证兼容性

[XieZongChen]

如果大家有关于重构的想法和问题，可以到这里进行讨论 #84

[gumingWu]

领取input

[simpleAndElegant]

领取 comment

[chaishi]

Cascader / DatePicker / TimePicker / TreeSelect 等组件 Vue2 本身还需要继续建设，大家先不要重构

这些组件会单独抽出一个 SelectInput 统一控制输入框和下拉框逻辑

[chaishi]

有些公共方法会出现一些不兼容的情况， 例如emitEvent这个，老版本的写法是用vm: ComponentPublicInstance的， 如果迁移到composition api上的话，getCurrentInstance获取到的是ComponentInternalInstance类型， 原本的$props和$emit都要改成props和emit。 类似于这种情况是在emitEvent后新起一个func保证兼容性以及方便后期统一替换，还是有别的方案呢？

emitEvent 是 Vue2 特有的写法，为了支持 <checkbox @change="xxx"/> 和 <checkbox :onChange="xxx" 两种写法。Vue3 不需要 emitEvent。

⚠️ 看到 emitEvent 的地方，Vue3 组件内部直接执行 this.onChange(xxx) 即可。 ⚠️

@higuaifan @pengYYYYY

[chaishi]

https://github.com/Tencent/tdesign-vue-next/pull/96

https://v3.cn.vuejs.org/guide/composition-api-introduction.html#setup-%E7%BB%84%E4%BB%B6%E9%80%89%E9%A1%B9

突然，在思考一个关于 composition api 问题：

从官网描述来看，CompisitionAPI 的出发点是为了在复杂的业务场景中可以更好的复用各类逻辑。setUp 函数也是因为逻辑复用而存在。

如果压根儿没有什么需要复用的逻辑，我们仅仅是把每个组件改成 setup 写法的目的是什么？

改成 setup 写法，代码真的更容易阅读了吗？(从 Comment 的实际代码来看，并没有深刻的感受。原先的拆分写法逻辑也是相对独立的，阅读上并没有障碍。）

---

看了下 Element Plus 某组件代码：https://github.com/element-plus/element-plus/blob/dev/packages/components/calendar/src/calendar.vue

这样的写法，把什么内容都放在 setup 里面的写法真的是更简洁了吗？代码真的有复用起来了吗

这样子把什么都写在 setup 里面，真的比以前的 options API 更合理吗 为什么我觉得 Element 这一波代码看起来还不如之前的 options API 变量、方法、计算属性 分开的写的方式呢

---

结尾，提一个问题：

为什么我们一定、必须、非得把每一个组件都改造成 Composition API ？（仅供讨论，欢迎大家发表意见）

仔细对比 Options API 和 Composition API 两种写法，真的是每一种情况下，每一个组件，每一个业务场景里面，Composition API 都更好吗？

https://github.com/element-plus/element-plus/blob/dev/packages/components/calendar/src/calendar.vue 大家在看这一波代码的时候，不觉得就是一个巨大的 setup 函数吗？有点强行 Composition API 的感觉

---

我们是否可以在必要的时候再使用 Composition API ？（通用逻辑再使用 useXXX 这种写法）

[higuaifan]

有些公共方法会出现一些不兼容的情况， 例如emitEvent这个，老版本的写法是用vm: ComponentPublicInstance的， 如果迁移到composition api上的话，getCurrentInstance获取到的是ComponentInternalInstance类型， 原本的$props和$emit都要改成props和emit。 类似于这种情况是在emitEvent后新起一个func保证兼容性以及方便后期统一替换，还是有别的方案呢？

emitEvent 是 Vue2 特有的写法，为了支持 <checkbox @change="xxx"/> 和 <checkbox :onChange="xxx" 两种写法。Vue3 不需要 emitEvent。

⚠️ 看到 emitEvent 的地方，Vue3 组件内部直接执行 this.onChange(xxx) 即可。 ⚠️

@higuaifan @pengYYYYY

👌疏忽了对函数本身作用的思考，感谢提醒

[higuaifan]

个人觉得像 Element Plus中calendar.vue这样全都丢在一个setup的写法可读性和使用Options API差不多差，要阅读一个组件的源码依旧需要上下翻阅。 不过Composition API的出发点应该不仅仅是复用逻辑， 也许是水平不到位，但是目前在我看来代码逻辑收集的作用是极大的， 例如calendar这个组件，将validatedRange和date操作分离开来，或许会一定程度上更易读一些。不过这个组件本身逻辑不算复杂，类似于input这样的组件我觉得将各个功能点抽离开来，可读性和可维护性都会提升。 不过我很疑惑为什么大家都没这么做，不知道是不是有些点我没考虑到，如果有的话希望大佬可以答疑解惑下。

[chaishi]

例如calendar这个组件，将validatedRange和date操作分离开来，或许会一定程度上更易读一些。不过这个组件本身逻辑不算

看看 tdesign-vue(vue2) 的 Calendar，逻辑挺复杂的，交互也挺多

复杂，类似于input这样的组件我觉得将各个功能点抽离开来，可读性和可维护性都会提升。

逻辑复用，逻辑隔离，完全没有问题，支持。

[chaishi]

https://github.com/vuejs/vue-next/issues/5191 大家也可以在这个 issue 里面一起探讨 Vue3 最佳实践

[chaishi]

不是不搞重构，重构很重要，非常重要，特别需要有实力的小伙伴共同参与。 只是在做一件事情之前，我们需要先规划好，然后再行动。

如果 tdesign-vue-next 继续按照每个组件单独开发，单独重构的模式，组件复用率依旧会非常低。而 Composition API 提倡的正是如何更优雅地提高组件复用率。

稍后，我们会拉群沟通，感兴趣的小伙伴可以扫码加入

[chaishi]

@gaopeak Message 组件建议，移步这里：https://github.com/Tencent/tdesign-vue-next/issues/107

当前 issue 讨论 Vue3 重构计划以及 Composition API 最佳实践

[vnues]

领取alert

[PengYYYYY]

目前，正在讨论对一些基础的Hook，大家也可以熟悉一下项目。认领组件后如果有重构完成的，可以提PR，可能CR的时间会稍长。官方这边也会加快基础Hook的建设。也欢迎加入群探讨。

[vnues]

认领avatar组件

[vnues]

有些公共方法会出现一些不兼容的情况， 例如emitEvent这个，老版本的写法是用vm: ComponentPublicInstance的， 如果迁移到composition api上的话，getCurrentInstance获取到的是ComponentInternalInstance类型， 原本的$props和$emit都要改成props和emit。 类似于这种情况是在emitEvent后新起一个func保证兼容性以及方便后期统一替换，还是有别的方案呢？

emitEvent 是 Vue2 特有的写法，为了支持 <checkbox @change="xxx"/> 和 <checkbox :onChange="xxx" 两种写法。Vue3 不需要 emitEvent。 ⚠️ 看到 emitEvent 的地方，Vue3 组件内部直接执行 this.onChange(xxx) 即可。 ⚠️ @higuaifan @pengYYYYY

👌疏忽了对函数本身作用的思考，感谢提醒

这里还不能直接用emit(event)这样写，因为vue3的文档写着支持:onChange=xxx这种写法，还是要处理下兼容的

[vnues]

认领drawer组件

[PsTiu]

认领calendar组件

[Blackn-L]

认领 progress

[uyarn]

认领dropdown

[ChrisLee0211]

认领List组件

[zouhangwithsweet]

认领 radio & switch

[ChrisLee0211]

认领badge组件

[qunbotop]

认领 notification

[ChrisLee0211]

认领slider组件

[btea]

认领 textarea & transfer

[Chanzhaoyu]

认领 message 认领 popup

[Blackn-L]

认领 anchor 和 breadcrumb

[qunbotop]

认领 message

[zouhangwithsweet]

认领 radio & switch

因为最近工作安排较多，radio 暂时没空重构，sorry

[k1nz]

认领 radio

[cca313]

认领 tooltip

[TabSpace]

认领 tree