关闭 More 保存 重做 撤销 预览

   
关闭   当前为简洁模式,您可以更新模块,修改模块属性和数据,要使用完整的拖拽功能,请点击进入高级模式

上一主題 下一主題
»
miyike123
LV3 流浪的疾风
帖子    34
新博币    0 提现
提现    0
     
    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我觉得大概也没什么特别能引起人不适的地方吧?(还是说我没能理解这样做的好处……?)





    个人签名

    或许我的心包有一层硬壳,能破壳而入的东西极其有限的。所以我才不能对人一往情深

    点击按钮快速添加回复内容: 支持 高兴 激动 给力 加油 淡定 生气 回帖 路过 感动 感恩
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    快速回复 返回顶部 返回列表