Next版开发建议讨论

[Rhilip]

这是一个比较长久的开发建议，其原因在于经过较长时间的开发和合并，目前项目过于臃肿，需要进一步重构。此外，Vue 3的出现（虽然相关生态还未完全建立），有必要进行进一步更新。

本开发的进展（roadmap）见面板 PTPP v2 ： https://github.com/ronggang/PT-Plugin-Plus/projects/2
本开发的开发代码见分支 next： https://github.com/ronggang/PT-Plugin-Plus/tree/next

就开发角度，目前有以下几点希望讨论：

• option页面目前使用Vuetify框架（v1.5），目前此框架已经出了v2版本。继续保留使用 Vuetify 作为 options页面框架，但是该框架的v3版本（适配Vue3）的 计划表 在2021 Q3 ，这可能会影响到我们的开发进度。另一方面，该框架对汉语开发者并不友好，v1和v2的中文文档都有缺失情况。我个人比较建议切换到 antdv 或者 element-ui 上，相对可能会有更多国内开发者来参与。
• 目前对各个站点、各个下载服务器都采用js的方法进行解析或支持（即resource目录），不同类之间缺少抽象和继承关系，带来大量的代码冗余，此外resoucre目录的结构和使用方式（evalScript）导致了最终构造出来的均带有原始文件信息，无法被webpack有效压缩。（目前考虑的是将clients，schemas，sites等移入background中）
• 取消使用chrome命名空间，改用Web Extension标准中的brower命名空间进行操作。底层使用 https://github.com/mozilla/webextension-polyfill 抹平浏览器差异。（Safari 开始支持 WebExtension， 之前Firefox直接构造chrome对象进行polyfill）
• 将部分操作从目前Promise异步回调形式，改为 async/await + throw Exception 形式。优化代码结构，同时避免大量并发请求情况，减少（或者说减轻）电脑负担（特别是对于某些使用手机的用户）。
• 对原先使用jQuery操作DOM和AJAX的操作，改为使用DOMParser和axios+axios-extensions的方式，页面注入使用vue app应该是可行的。但是目前来看，浏览器原生的 document.querySelector 对于CSS选择器的支持程度并没有jQuery高 （部分对比 jQuery Selector vs querySelector），部分DOM查询操作可能存在较难迁移的问题。（或者可以考虑使用 cheerio-without-node-native ？） 使用jQuery的Sizzle作为选择器替代 ( 5fad766 )
• （此点与上一点相关）因为目前我们在CSS选择器中多使用:contains() 这个不是原生的方法，其未被 document.querySelector 所支持，那么是否可以考虑使用XPath的方式，即 Document.evaluate() 来进行匹配。相关文档： https://developer.mozilla.org/en-US/docs/Web/API/Document/evaluate
• 解除目前下载服务器和插件主体功能强耦合状态，或提供zip包下载器（注：类似于部分站点提供的以zip包形式下载多个种子文件的功能）。
• changelog 不单独作为一级目录放入插件内 ，使用 CHANGELOG.md 文件放在项目根目录 ，并入options中。
• 取消可选权限在manifest.json中的注册，这个之前是为了避免商店的审核，但是目前的情况，增加可选选项并没有给通过审核。此外，部分浏览器对可选权限的支持有限，部分情况下用户难以直接进行选择。此外还存在部分站点获取用户信息必须要使用Cookies的情况。
• 优化用户数据获取，目前用户数据获取存在多步走的情况，以NPHP站点为例，基本要第一步先获取ID，再进一步访问userdetails页面。而其实第一步是第一次获取之后优化掉的。
• 对站点域名进行保护，不直接以url硬编码形式写入配置文件，而是改成base64的形式编码，在运行时还原。（复盘后觉得意义不大，且增加维护难度，故删去） 此外，对CDN域名这个站点配置进行调整，内置已知的站点别名域名，提交给用户选择，如果仍非用户当前使用，则提供填写入口。
• 重构辅种服务，将插件自带的基于对比的方法、Reseed、IYUU统一集成。
• 技术页面的依赖项说明修改为动态获取（ 见 9ba08c6#commitcomment-45751445 ）
• 移除对于单站搜索结果本地限制（原为默认10条， 在 4560a91 中将默认限制改为50条 ），可以考虑移除该限制，站点返回几条就显示几条，而不应该在插件侧截取，更好的替代方式应该是提供更为丰富的filter。
• 将站点自定义功能改成高级用法，不再提供GUI配置
• 将omitbox的关键词由 pt 改为 ptpp

[ted423]

@Rhilip 拖动出框自动关窗口会好么，我目前感觉刷新数据占用好高，这个切换后会好么🙈

[Rhilip]

@ted423 之前看ronggang大的意思，Vuetify v2 是解决了 “拖动出框自动关窗口”问题。当然我更建议换框架，Vuetify维护起来过于麻烦。
对于刷新数据占用，我觉得部分从promise改成async/await可能能解决占用（已经补充）。但是对Promise可能要扩展，比如使用bluebirdjs，因为他的 Promise.map 提供了concurrency选项，这样我们就可以对同时进行的请求数量（实际是Promise数量）进行限制，从而减少占用。目前对于排队请求这块，我记得ronggang大是手撸了一个。。。

[ronggang]

今年因个人原因，对项目的参与度低了些。🙏
重构需要花大量的时间，看起来目前时间不允许。
关于 Vuetify ，当初花了不少时间选择，主要是没有找到好用的 table 组件，多方比较后还是觉得 Vuetify 比 element-ui 合适，并一直沿用；v2的之前也大概看了下，升级应该没问题。

这个主题可以好好讨论一下。

[enigmazack]

推荐下quasar，相对于其他的ui框架，这个提供了一整套的开发框架，开箱即用，非常方便。

[Rhilip]

推荐下quasar，相对于其他的ui框架，这个提供了一整套的开发框架，开箱即用，非常方便。

我看了下，觉得quasar 也可行，毕竟其CLI支持建立BEX应用，而且能延续目前使用的Vuetify中的material理念，但另一方面， quasar同样也存在前面我提出的 Vuetify的问题，中文文档支持不太好（虽然有社区提供的中文文档，但也落后于官方文档大版本）。国内 antdv 或者 element-ui 在这方面处理起来都挺麻烦的。
之前我在提出这个issue的时候还选型过 https://vue-web-extension.netlify.app/ ，觉得也是比较好的替代方法。毕竟目前整个应用构造方式方式过于麻烦，如果能把这部分工作交给底层模块，能极大的减轻我们的工作。
正好quasar其路线图应该是在今年年底能完成对Vue3的支持，我预期的也是明年再开始这块重构（今年剩下时间看起来我和ronggang都不太有空以及精力完成重构工作，只能做一些探索性的工作），到时候可以再做关注。

[IITII]

推荐 Quasar+1. 构建系统很完善. 框架横向对比, 我只是业余的, 就不评价了.
文档虽然是英文, 但是从介绍到实例,API 都很齐全. 活跃度的话 Quasar 和 Vuetify 差不了多少, 单看 github.
感觉大致还是有这些问题吧.

1. quasar 比较小众(可能?), 存在学习成本
2. 文档是英文
3. 国内好像没有用 quasar 的... 对个人来说,可能不太想学...
4. 大部分(国内)前端使用的框架好像就是 antv 了

我蛮早就用了 quasar, 官方文档一直很全. 业余时间糊了一个项目, 基本上都是从官方文档里面扣的示例, 缝合怪 : https://github.com/IITII/pic_online/tree/vue3

[Rhilip]

基于当前dev commit （ 627475a ），对vuefity2的patch
https://gist.github.com/Rhilip/8dc72393c411d57b8efc45e112c2c1c3

[enigmazack]

https://github.com/enigmazack/pthub

大佬们看看我自己边学边搞的个，vite+vue3，用的andtv，vuetify实在是太慢了。好像还有个大神推荐的naive UI，没去看。
vite实在是太爽了，开发效率大大提升。

[Rhilip]

enigmazack/pthub

大佬们看看我自己边学边搞的个，vite+vue3，用的andtv，vuetify实在是太慢了。好像还有个大神推荐的naive UI，没去看。 vite实在是太爽了，开发效率大大提升。

我也觉得vuetify过慢了，要 February 2022 才release。
但是从目前的版本更替来说，data table依旧是我们在ui选型中最为关注的要素之一。
比如我们现在有个需求，就是表格的多列排序 （ #897 ），这个目前在多个ui framework中都没有见到有支持，只有 vuetify 2 有支持，我也在等待vuetify 3能否有相关的支持。

naive ui挺好的，我个人项目有在尝试使用。
你的repo，到时候我看看怎么吸收过来或者给你做贡献2333

[enigmazack]

其实我主要是想推一下vite，大部分时候编辑器这边ctrl-s一下，浏览器那边就能看效果。以前给ptpp提交pr时都是改完了编译一边再插件reload一遍，在看效果，太麻烦了，也一直没搞清楚有什么快捷的方式。

https://github.com/antfu/vitesse-webext

这个是模板。

如果用antd或者naive，实现多列排序，可以写个custom表头定义一下click方法，排列算法的话用lodash实现有现成的。

UI这一块我看着都头大，我这个repo就是自己练练手，我主要是期待能给ptpp的next版本做点贡献。

[Rhilip]

感觉 yarn dev:bc 在目前的dev channel应该能实现 HMR，
但是其实我目前修改也是 改完了编译一边再插件reload一遍，在看效果 的（笑
因为目前dev channel的实现，需要收集信息形成 systemConfig.json 文件，所以需要编译才完整。
这一块目前在next branch中是使用 require.content 函数实现的，避免了在编译过程中的信息收集（实质是把收集过程交给webpack，而不是自己写处理脚本）

[Rhilip]

鉴于vuetify的开发进度实在过慢，而且本人在升级到 3.0.0-alpha.11 时出现了严重的编译问题，
我个人建议切换至 naive ui。请其他contributer提提意见。
@ted423 @enigmazack @ronggang @luckiestone @sabersalv @tongyifan

[sabersalv]

对vue不太了解, 切换重写要花大量时间把, Ant Design Vue 有考虑过吗

[Rhilip]

对于我们选型，主要考虑的是Table组件的功能性（这点上面 ronggang 他也提及了）。AntDV的table组件不支持多列排序，所以不在考虑范围内。
另外有一点是vuetify的风格是 Material Design，所以如果切换 ui framework，那么势必要在css上多做打磨（而且这块之前我也没了解）。
其他问题不大，我昨天晚上做了初步的尝试，应该很快有commit上来。

---

主要是因为这个discussion已经一年多了，不想再等vuetify的release了，我这边需要加快速度。

[ted423]

话说现在vuetify是挪到了 Q3 2023？
现在还是因为这玩意卡着么

[vivodi]

话说现在vuetify是挪到了 Q3 2023？ 现在还是因为这玩意卡着么

vuetify 3.0是2022年11月11日发布的，最新版已经是3.7.3了。不知道后续为什么没有迁移？

[ted423]

话说现在vuetify是挪到了 Q3 2023？ 现在还是因为这玩意卡着么

vuetify 3.0是2022年11月11日发布的，最新版已经是3.7.3了。不知道后续为什么没有迁移？

摸鱼 大概

[Rhilip]

话说现在vuetify是挪到了 Q3 2023？ 现在还是因为这玩意卡着么

vuetify 3.0是2022年11月11日发布的，最新版已经是3.7.3了。不知道后续为什么没有迁移？

摸鱼 大概

是的，实在是日常及工作太忙，抽不出很完整的时间来实现next开发任务。
从各个依赖上来看，基本manifest v3 以及 vuetify 3.x 等的都不是大的问题，。