vue-vben-admin
vue-vben-admin copied to clipboard
vbenjs
关于项目更新与封装
首先感谢作者的无私奉献，目前已经投入两个项目的生产使用，毋庸置疑，在速度,ui适配和使用体验来说已经远远超过蚂蚁的antd pro。所以后续我们打算把所有产品的中后台使用vben重构。 但是在使用中遇到一个比较棘手的问题，提出一些建议
因为已经投入生产环境，但是当前仓库一经更新，我们本地项目的代码就跟不上了，也需要同步更新。比如日前客户需要暗黑主题在线切换，前面我们是直接整个antd打包两个css文件的方式实现。等到作者放出更好的通过css变量的方案来实现我们打算全面更换，但是要更改的地方就非常多，并且无论查看仓库还是官方文档都没有一个有效的更新说明，花了非常多的时间去修改才搞定。 以上只是一个例子，还有从beta版开始，我们非常多的精力都花在跟着仓库同步更新上，因为官方仓库没有任何更新说明，差不多每天代码都在更新，使用者也必须至少两三天查看commit来更新，这个非常不方便
并且目前vben的代码碎片化也比较严重，很难统一管理
所以提出更改方案的几项建议，希望可以供作者参考
关于src运行时代码：
- 类似Antd pro那样把布局和一些常用的hooks等抽出来做成monorepo发布,比如单独一个vben-components，包括vben-layout,vben-card,vben-table,vben-charts等到库，需要更新时，只要
pnpm update vben-xxx,然后改几个api就行 - 对于非远程加载的数据,比如settings等，抽出单独的组件,使用类似react中
useContext,useRedcuer这样的hooks封装,而不要用vuex统一管理
关于build开发代码: 尽量把所有的插件和配置等都提取出来打包到一个仓库里，只要在vite.config.ts里引入一个import vbenconfig函数就行,接着放出几个自定义配置的选项就行
关于文档: 尽量把每次更新和调整的API写进去，这样方便升级
最后再次感谢作者提供这么好的后台，让管理系统开发工作量减少很多
抱歉，给你们造成了麻烦。
- 在更新上面，这个我一直没有好的办法，我看了很多别的开源框架，基本都是不能同步更新，所以更新这块一直是个问题，文档提供了一种方式来合并代码。但也不是最好的方式。后面我在看看有没有别的方式来，或者是按你说的只更新项目依赖这样。
- 对于src组件抽取成第三方依赖这种，可能会等项目在稳定点，且我有时间优化组件后在来抽取，现在的组件对我来说只能说是比较粗糙，自我感觉达不到组件抽取的程度，依赖可能也会比较耦合。所以可能会在3.0做一次抽取，时间也暂未定。
- 关于文档，后续的更新我会尽量写详细
这个问题我开着，有什么建议可以提出来
现在就管理面板本身功能而言已经几乎完美，该有的都有了，平时用着挺舒服的，一更新就头大，所以代码还是暂时别更新了，有空更新更新文档，修复修复bug就行，等到3.0直接发布好了，就让我们没有心智负担的去用吧😄，大神，千万别再每日一更，正常人吃不消啊😅
xxx名言
最可怕不是vben出bug,是vben又开始更新了^v^
我现在是文档里的方式，参考代码用admin，开发基于thin，开新分支，同步到自己的git，有更新时从main合并，需要解决一下冲突。如果改动多，冲突多就要考虑cherry-pick了。还好作者代码整洁，提交规范，目前还没遇到什么麻烦。
大力开发中项目的思考
Commit频繁我觉得是个好事，vue3生态库都还没有稳定（甚至vue2to3的文档还在更新中，有的也只是提案状态），很多第三方库大多数处于beta中，甚至兼容性都达不到要求，相关问题解决方案选择很多，也没有固定下来，来回变动肯定的。如果现在不修改，以后很容易埋下技术隐患，产生技术债，影响到一大批将要采用的用户（当前还只是vue3的开始，后续vue3正式版后，将会有一大批用户进入），后面再修改，影响相当大，甚至需要考虑兼容。
照顾现有生产用户
不过为了照顾已经进行生产开发的用户，文档只可能尽量详细。同时建议熟悉项目的人员合并新功能，不用团队每个人都做这个工作，这样会好得多，特殊冲突可以查看Commit手动处理问题不大。相信大多数用户修改的也只是业务代码，公用代码可能只会客户化的时候修改一次，理论大多代码合并都非常简单，因此持续维护的项目，建议定期同步，避免以后重构工作量大，至于那种开发了不管的项目，其实更新不更新意义都不大。
另外对拆组件做依赖库的思考
感觉拆组件做依赖库确实有点早了，很多组件比较零碎，有的可能非常简单，就几行代码，有的通用性又不够强，达不到拆分的条件，有的组件交互又太强，不像antpro那种result通用性特别强的组件，甚至拆分组件后维护和修改相对来说成本更高，就像刚才说的那样，它可能几行代码。拆分组件将产生数十个新项目，对作者维护来说真的成本太高了，价值回报低，更新好文档相比拆分来说更有价值。
下一个版本
类似做成vben.config.js的方式来说，更复杂，等vue和基础代码以及组件大规模使用稳定后修改也是可以的。
以上只是自己的个人想法，仅供参考，另外谢谢作者的辛苦付出。
@zhangfugui727 已经放弃vue3,滚回React了,vue3的写法一言难尽，还是React的TS支持完美，写起来纯粹，畅快。。。尤其我们这样的团队，分工通过服务来分而不是前后端来分，也就是每个人都是在用ts写前后端，后端除了少量cpu密集的场景用golang外大部分是用的nestjs这种纯ts框架，所以前端需要TS支持非常好的框架，vue3目前来看真的难以胜任ts全栈开发，还是合适spring boot/laravel+vue这样的组合。 但vben项目的价值还是非常大的，样式可以拿来枪，各种vben作者写好的vite插件可以用(尤其vite-theme简直神了)，感谢作者的贡献。
目前我在尝试搭建一个 vite+pro components+windicss+antd+antd charts+ vben的所有插件样式的通用后台, 再套上react router,rematch,swr等然后加上各种hooks，那写起来是真的爽。
建议如果觉得vue3的生态目前不够成熟，可以尝试一下React+vite+pro components,然后抄袭vben的各种vite插件和样式😄
为什么还是用React写东西好？因为不需要在组件里写hooks还要加个setup👍🏻
最后等vben3发布的时候再去尝试，作者加油💪🏻
@nangongmo 祝贺，各个团队有各个团队的历史积累，适合就好，React也不错，NPM下载量长期也是居高不下，生态成熟稳定。
Vben也是我见过各种问题解决方案最完善，代码质量高，综合最好的前台模板，作者绝对是个对行业技术有敏锐感知，对项目功能质量及自己有所要求的人，现在的更新频率和MIT免费开源的精神，绝对可以期待一下。
感谢作者的开源贡献，加油。
估计没有关注最新的更新 vuex 已经被 pinia 替换了 其他的不了解，楼下继续
自从这次 Breaking changes 之后, 现在手中正在开发得项目, 就放弃了和vben-admin上游版本的同步.
因此再也不用担心作者更新了
@anncwb 这个项目相当的赞👍🏻，第一眼看到就很喜欢🤩，感谢作者。 看了看代码，和antd pro早期版本类似，所有的公共代码都在项目里，怕不方便迭代升级。 以前用react技术栈时，用antd pro做过一些项目，删除示例代码，然后开发。N个项目之后，放弃了公共代码的同步升级，如果赶上break升级会更痛苦😱。 期待作者能将项目拆分封装成类似pro-layout这样的组件，方便大家升级迭代，不知道作者有没有组件化的时间表？🤓
包管理器在V2.8.0 改用pnpm了，它自带了monorepo解决方案， 那下一步是不是就会把vben的组件转到一个独立项目，以monorepo的形式来管理项目？
@Aimumu 感觉就算抽离出公共的组件在升级上也难以避免大量的merge，毕竟为了契合自己的项目难以避免会修改一些基础框架和页面。可以考虑下在两个仓库开三个分支来合并两边的代码，这样虽然首次更新依然比较麻烦，但后续更新会容易很多。 大致思路：基于官方分支创建一个合并分支，并与当前项目代码分支进行合并，三个工作分支：官方分支，合并分支，开发分支（A、B、C表示），首次A copy B 然后 C merge into B解决主要冲突，后续更新只需要A merge into B，然后C merge into B，最后从 B pick 合并结果到 C就OK，这样保证了合并分支在pull 官方代码时候不存在冲突的同时保证了自己的开发分支C不会被官方commit污染
