「WIP」feat: ProChat 2.0 重构升级

[ONLY-yours]

💻 变更类型 | Change Type

• [ ] ✨ feat
• [ ] 🐛 fix
• [ ] 💄 style
• [ ] 🔨 chore
• [ ] 📝 docs

🔀 变更说明 | Description of Change

📝 补充信息 | Additional Information

[github-actions[bot]]

😭 Deploy PR Preview 8e3144be72e6e5e8f717e573d8881289e21e0246 failed. Build logs

_{🤖 By surge-preview}

[LCJove]

这次的重构会优化哪些部分哇

[ONLY-yours]

这次的重构会优化哪些部分哇

• 去除现有的数据流方案（现在的数据流 api 和 普通的 api 混在一起用，代码里面很乱 ）
• 打平组件层级，现在各个层级太深了，重构完后就 List + Item 两层

[Adrian-Zephyr-Liao]

这次的重构会优化哪些部分哇

• 去除现有的数据流方案（现在的数据流 api 和 普通的 api 混在一起用，代码里面很乱 ）
• 打平组件层级，现在各个层级太深了，重构完后就 List + Item 两层

v2版本有什么其他考量么？最近在深度使用v1版本，想试试后续能不能参与进来 核心api考虑以下场景：

1. 目前是string类型的返回对应着一个chatItem，是否考虑支持自定义结构化数据 可能在一次问答中，不一定需要answer

• 返回一个有序列表的数据结构，前端自定义有序列表可以供用户点击跳转
• 返回一个富交互的卡片等等 不同的返回可以对应着不一样的chatItem渲染

2. 一次的request请求，可以渲染出多个chatItem，可以有默认的Item，也可以有自定义的Item

[ONLY-yours]

这次的重构会优化哪些部分哇

• 去除现有的数据流方案（现在的数据流 api 和 普通的 api 混在一起用，代码里面很乱 ）
• 打平组件层级，现在各个层级太深了，重构完后就 List + Item 两层

v2版本有什么其他考量么？最近在深度使用v1版本，想试试后续能不能参与进来 核心api考虑以下场景：

1. 目前是string类型的返回对应着一个chatItem，是否考虑支持自定义结构化数据 可能在一次问答中，不一定需要answer

• 返回一个有序列表的数据结构，前端自定义有序列表可以供用户点击跳转
• 返回一个富交互的卡片等等 不同的返回可以对应着不一样的chatItem渲染

2. 一次的request请求，可以渲染出多个chatItem，可以有默认的Item，也可以有自定义的Item

最后一个我们已经在构造了，1.x 版本的 request 会分裂成两个

• sendMessageRequest
• request sendMessageRequest 会承载 1.x 里面的 request 能力，只要求返回一个，作为最新的。 request 会变成整个大数据，一次渲染整个列表

另外几个都是很不错的 idea thanks

[erlinerd]

去除现有的数据流方案（现在的数据流 api 和 普通的 api 混在一起用，代码里面很乱 ）

这个是一些api不在store里维护的意思吗

[ONLY-yours]

去除现有的数据流方案（现在的数据流 api 和 普通的 api 混在一起用，代码里面很乱 ）

这个是一些api不在store里维护的意思吗

是的，现在 1.0 会有一些很疑惑的逻辑，为什么有些要用 Provider 包裹，有些又是 ref，2.0 会统一这些 @levidcd

时间点比较靠后，大概 4月底之后才会正式发布