博牛社区
https://bbs.boniu123.cc/
Vue不如React
2019-04-02
miyike123
恢复备份
导出
导入
更新
清空
关闭
More
保存
重做
撤销
预览
开始
框架
模块
您可以通过导出进行模板备份
我知道了
添加框架
添加模块
100%框架
1:1
1:2
2:1
1:3
3:1
1:1:1
tab框架
关闭
当前为
简洁模式
,您可以更新模块,修改模块属性和数据,要使用完整的拖拽功能,
请点击进入高级模式
广告合作
招聘广告
社区广告
博牛APP
博牛QA
官方人员
官网验证
论坛首页
新闻中心
东南亚新闻
国际新闻
产业新闻
讨论广场
综合讨论
黑点曝光
求助问答
灌水闲聊
生活服务
房屋租售
商品交易
外卖点餐
畅游世界
美食之旅
博牛招聘
求职招聘
招聘专区
求职专区
产业中心
免费广告
全球展会
娱乐大厅
每日签到
萌物寻踪
俄罗斯方块
声色犬马
私密聊吧
情欲图鉴
绯梦书阁
站务公告
公告专区
毛遂自荐
建议投诉
登录/
注册
博牛社区
›
讨论广场
›
综合讨论
电梯直达
»
返回列表
miyike123
LV3 流浪的疾风
LV3 流浪的疾风,当前积分413,距离下一等级还需387积分
如何获得积分?
帖子
34
新博币
0
提现
提现
0
元
发表于 2019-4-2 14:15:40
6528
0
|
显示全部楼层
|
倒序浏览
楼主
1 让人搞不清楚状况的API
@click="handleClick"
这个写法大家都很熟悉的。然后,Vue还允许这样写:
@click="handleClick()"
emmm……????
精彩。
于是,当我们有这样一个函数的时候呢:
handleClick : (fnType) => () => { .... }
@click="handleClick(1)"
请问:在点击之后,我们预期中的那个函数到底是会执行呢,还是不会执行呢?
括号这东西,要加就加,要不加就不加,怎么做都是对的,但这一会儿加一会儿不加的……emmm?
这种省几个字母造成更大困惑的地方我印象中可能还不止这一处。
作者:匿名用户
链接:
https://www.zhihu.com/question/315734889/answer/624608264
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
2 不方便编辑器/IDE提供支持,相关支持较为滞后
首先要承认,这个现在这个已经基本不算问题了。不过曾经还是让人很卵痛的。vue的组件的配置项大概是这样:
{
data(){ return {...} }
methods: {
xxxFn(){ this.xxxx }
}
}
于是,通常来说,在methods对象而言,this指针访问不到data函数return的对象里面的数据,这个应该算是js的正常表现吧?但是在vue里面是可以的。其间发生了什么大家肯定都知道也就不必多说。但是,但是呐——
编辑器/IDE(包括Typescript)的智能提示是怎么知道的呢?
一开始的时候大概也就是瞎猜,后来TS专门为了这玩意儿更新了一些特性,终于能支持了。
但是我们可以马后炮地回想一下,vue的这个组件API设计之初……肯定是没考虑IDE的支持问题的。
事实上,不止如此。
包括那个什么.vue文件,这个东西推出的时候,IDE支持是跟着同步推出的吗?我印象中好像是没有的。包括vetur什么的,也都是第三方提供的吧。那么在此之前是怎么写.vue文件的呢……?
谈到这个话题恐怕就要男默女泪了。
究其根本,那就是vue一开始并非为工程化而设计的。某些特性提出来,配套工具却不一定跟上了的。相对应的,你看React丢一个hooks出来,会为之配套eslint规则;Vue群众最喜欢黑的“超级复杂的”Angular框架,也有模板语法的语言服务啊?
当然,这只是针对现阶段的Vue来黑的。
3 做不了面向对象编程
有一些大佬以为在React“代表了函数式编程”之后,Vue就可以被称作是“面向对象之大成”了,以至于如果有人说喜欢React、厌烦Vue,那么就可以给他打上“此人不懂面向对象”的标签。
殊不知Vue这个框架也就是个谜一样的this指针比较万能,开发起来的体验其实更像是过程化编程……(当然,我不是说面向过程编程就有问题了)
我们都知道,vue的结构是data是data,methods是methods,分的很开的。而这个“分的很开”的做法,恰巧就和面向对象一毛钱关系都没有。可能各位非常懂得面向对象编程的Vue大佬们会不屑于看一下其他语言吧,但是……通常来说,一个存储了各种数据、没有挂方法的“对象”……是会被称作为“结构”的……(当然,这个也不是准确的定义,很多语言的结构上也是能挂方法的)
那么,这样有什么坏处呢?来举个简单的例子。
比如我们有个pager: { pageSize: number, pageNum: number, totalCount: number }
然后项目里规定了一些通用的翻页事件,比如这样:
next() {
this.pageNum++
// ...someting else
}
那么,这个时候,pager对象里面既有数据又有方法,它该不该放到data里面呢?顺带,哪怕你硬着头皮把它放到data里面了,它的this也依然会指偏啊。
可能有人会想起来,我们还有autobind之类的装饰器,能够方便地把this锁住。然而,这就涉及到另一个悲伤的故事了:vue是会用getter和setter做代理的,而autobind之类的库也会用到getter和setter……它们……冲突了……
可能这个时候有人会想:“一个pager而已,直接拆开写又怎么了。”
那么,很好,现在就进入了面向对象的领域……
如果某些页面的pager需要一些强化的功能呢?是不是要扩展这个对象?那么拆开写可怎么extend啊?要用魔法mixin吗?
组件因为涉及到模板部分,所以想做扩展是真的难。可是vue这面向过程的设计,怕是连组件逻辑都很难拿出来做扩展了。
4 vuex
魔法字符串过多,且基本不大可能用常量解决。
和v-model冲突。(这一条其实可以理解,但是就实际情况而言……新人们好像经常中招啊)
mapState/mapGetters,在大部分情况下意义不明。
action-mutation看上去好像很美,实际上大部分人写的代码都是重复的……别提redux,提了就一起黑。
5 路由
那个keep-alive……可真是个好功能。(棒读)
6 社区对全局注册的滥用
这个严格意义上来说不是vue本身的问题,但是你看某组件库……
他们的组件是<xx-xxxx>这样命名的,为啥消息框却是this.$message呢……叫this.xxMessage我觉得大概也没什么特别能引起人不适的地方吧?(还是说我没能理解这样做的好处……?)
个人签名
或许我的心包有一层硬壳,能破壳而入的东西极其有限的。所以我才不能对人一往情深
收藏
0
回复
返回列表
点击按钮快速添加回复内容:
支持
高兴
激动
给力
加油
淡定
生气
回帖
路过
感动
感恩
恭喜您已经成功添加了回复内容!
返回重选
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
本版积分规则
发表回复
回帖后跳转到最后一页
快速回复
返回顶部
返回列表