👑 [一点建议]antd是国内react的标杆,请不要越跑越偏 #7753
Replies: 14 comments 19 replies
-
具体什么问题?插件应该都是直接可以用的,不需要改造。 |
Beta Was this translation helpful? Give feedback.
-
其实这个问题,简单的说,就是越和蚂蚁内部的设计越吻合的方案,用 umi@3 就会越舒服。越偏离设计的方案,就会觉得越复杂。举一个具体一点的例子,umi 把握了 route,plugin 掌握了 layout。给用户的操作空间非常小,也许在内部项目,或者团队内有强制规范的项目中使用会觉得省了很多事情。但是不少团队有自己的开发习惯时,就会有晦涩难懂的感觉。拿我这边的情况来说,所有的设计都遵从蚂蚁对外的规范,只有路由采用了约定式路由,这一点的差异,但是需要做的工作就会多出很多。 |
Beta Was this translation helpful? Give feedback.
-
umi@3在多入口、build静态文件时的编译性能、调试debug方面是不是能尽快提升一下啊。 |
Beta Was this translation helpful? Give feedback.
-
主要是人力不够,ant design pro 主要就我一个人维护,我还要做内部的业务,还要做插件,还要做procomponents,所以pro 收窄了使用范围,专心服务中后台。 如果能接受我们的模式是可以很快的实现一个 crud 的页面,各种 xxx 管理后台可以很快的搭建起来。
需求催生产品。我们主要满足内部的需求,所以就会变成现在的样子。社区的思路也会吸收,但是社区的使用方式维护力度需要非常大,一个产品能用很简单,要好用至少需要不少于一年的迭代。
我们的本来的初衷就是因为 用 antd 搭建一个后端管理控制台,太复杂了需要拼接各种代码。不是取代cra,我测试某些页面的时候也会用 cra,cra 适合所有 react 的项目,那 pro 只适合中后台,干别的也可以,但是设置起来很麻烦。 你说的文档问题的确存在,文档更新不及时,更新的日志没有写,这其实是因为精力的问题,维护一个开源项目是非常苦难的事情,我们因为可以内外结合,所以已经算是相当有维护力度的,你可以看我们相关同学的 timeline。但是我们也不可能全职的搞开源,尤其是文档,文档真的很难。我宁愿写很多的代码都不想写文档。文档要花费超级多的精力,密集的开发过后一般都会进行文档的改进。但是进入维护期后一般都会懈怠,同时也顾不上每日的维护。 但这也是开源的意义所在,我们之所以愿意把代码放出来,还投入不小的精力修复内部不会碰到的bug,添加一些社区呼声比较高得功能,就是因为社区是自驱动得,有很多小伙伴可能随手就改动了文档,或者随手修个小bug,日积月累也会让我们的项目变得更好。 你吐槽的很合理,但是这个对产品变得更好意义不大,如果你觉得不好用得地方可以提炼以下,想一想是不是可以作为需求。如果你提得电子帮助到了更多的人,开源就会变得更好。 |
Beta Was this translation helpful? Give feedback.
-
越来越多的人贡献代码,就好了。光使用,不贡献,就给antDesignPro很大压力。 |
Beta Was this translation helpful? Give feedback.
-
pro这边还好,1个人顶3个人,umi好像更严重。 |
Beta Was this translation helpful? Give feedback.
-
使用ant design pro 2.2.0开发内部需求,开发完打包上线,在打包部份就出现问题,後面没办法了,直接试著2.3.1版,看看打包完後nginx可不可以顺利的执行而不出错。确认2.3.1打包後可以让nginx顺利执行,就立马搬迁开发好的程式,结果悲剧再次发生,前端传送到後端springboot controller params不能解析.................原因是utils\requst.js使用的元件将与2.2.0不同,除非後端controller代码调整,想了想,试试看2.2.0的request.js档案能不能直接给2.3.1使用,看来可以,这才临时解决了上线时程压力。 确实,版本的更新是好事,但ant design pro内部使用的重要util不能稳定下来,这实在不是一个好的现象。而且2.3.1这个版本在github上也不见了。虽然很喜欢使用ant design pro,但一直不稳定,实在不是一个好事情 |
Beta Was this translation helpful? Give feedback.
-
作为一个自学的人,能看到有antd pro的这个这么好的开源项目感到很幸福。 |
Beta Was this translation helpful? Give feedback.
-
把antd 搞好就可以了,不要封装过度了,只知其然,不知其所以然.... |
Beta Was this translation helpful? Give feedback.
-
我个人并没有觉得antd pro 现在的模式有何不妥。你完全可以只用antd UI,antd本身并没有过渡封装,你完全可以用其他的组件来实现request、部署、调试等,或者自己造。 antd pro 不是UI框架,它是基于antd ui库提供了一套解决方案: ——方便用户基于antd pro快速实现业务。 antd pro能让我一个后端对前端知之半解,对react毫无了解,更别提webpack、路由等等的情况下就能快速开发一套很漂亮的企业级系统。那是相当优秀了,对于这一点,现其他UI框架都是望尘莫及的。 所以对于我个人来说,antd pro已经是国际标杆了。 |
Beta Was this translation helpful? Give feedback.
-
@galileo303 首先,这么diss一个开源库,我觉得你的私心有点重了,在用任何一个库之前,都要调研清楚是否符合自己的需求。当你最后说:“...相反还不如cra自己配置一个反而比umi快很多,自有很多。” 的时候,我就觉得你做的技术选型不是很合理,是不是一开始就使用CRA更好?为什么现在反过来 PUA antd pro呢?如果你想让antd pro变得更好,就提PR,或者成为Sponsor;如果有使用的问题,就提issue。 “跑偏”?你知道正确的方向?而且,你说了也不算。 我最近用antd pro v5做了一个后台系统,也是第一次用,说说我的感受吧: |
Beta Was this translation helpful? Give feedback.
-
也说出了部分我们团队的痛点。 因为入坑比较早,对 dva, umi ,pro 都是有点感情的,很多话,不敢讲,因为怕被喷。 我们团队,小,技术菜,只有一个诉求,能不能支持 JS ,现在的版本,你说你不会 TS,干脆就别选。 |
Beta Was this translation helpful? Give feedback.
-
许久没有折腾前端了,以前用过 NG,自己的项目需要自己开发前端,又重新学NG17,发现强大,齐全,好了!发现需要折腾大量的UI,看了好久,没有好的方案,看 antd 这么齐全(有pro),又重新学 react(以前是会class的方式),基础学完了,用 Pro 还需要学这个 umi ,这个 umi 基本搞明白了,发现一堆过时或不维护的库如:数据流、模型、dva 等等,还存在依赖耦合,一个 http 请求让我看一两天选什么(最新ahooks?umi不兼容,需自行按需用,我就想简简单单用http呢,过时不维护的不要),真是乱七八糟花里胡哨,再认真看 pro 用一堆过时,说好的是大厂呢,维护力呢。。。 如今有两种让我继续折腾。 |
Beta Was this translation helpful? Give feedback.
-
直接用webpack, webpack-dev-server, Redux Toolkit, react-router或者CRA, vite等,按需使用,少一层封装,少一层麻烦,尤其是封装不好,没人维护,社区不行,维护人员水平有限的东西。有些东西可能开箱即用,但是后续遇到问题要么社区搜不到,要么提issue没人解决,要么问问题没人回答,要么回答也是草草了事,答非所问。这样的话,这个东西就有KPI项目,面子、品牌项目的嫌疑,就像OP说的,这东西是用来吹牛逼,涨粉用的,设计是否合理,API是否好用,是否建立社区,根本不再考虑范围。 |
Beta Was this translation helpful? Give feedback.
-
umi和pro原先我还觉得不错,现在越来越觉得群魔乱舞。
完全不考虑开发者和使用者。越来越远离初衷了。
框架本质本来就应该提升开发体验,提高开发效率。
现在的pro和umi开发体验没体验到啥好处,配置倒是越来越繁琐,不是这里出错就是哪里出问题。升级就要去翻源码看。文档也不会及时更新。升级不会不做任何兼容,或者提示。
走了一大圈,不能立马写业务不说,还要重新去学习哪些所谓自己发明,自认为牛x的插件,写法确实牛逼,但是这些重型插件,百分之90都是不能用的,需要重新改造。而且改造起来还不如重新写一个组件。适用性太弱。可能写这个组件的人感觉不到,但是对于百分之90的使用者来说,都是哗众取宠。
越来越觉得pro和umi在沉浸在自己的世界里面,自己感动自己。认为自己的组件价值观是“伟大的”,而忽略了中国大部分react开发者的开发体验。当打开pro给的案例的时候,ohshirt~!�react是这么写的吗?大段大坨恶心的群魔乱舞的代码,个现聪明。结果成了一个乱糟糟的代码页面,没有任何思想的硬怼的业务代码。就像初级程序员开发一个紧急需求一样。
越来越华而不实,反而是带偏了react开发者们的思考方向。越来越觉得react乱七八糟。本来的初衷是为了取代cra,智能化的配置。现在看来,配置成了群魔乱舞,相反还不如cra自己配置一个反而比umi快很多,自有很多。
我觉得应该值得思考
Beta Was this translation helpful? Give feedback.
All reactions