关于vue3:基于-Vue3-打造前台中台通用提效解决方案无密

复制URL链接下哉:https://www.666xit.com/3494/

第一次Composition API

在vue3.2中,正式反对了script setup的写法,这样能够大大简化组件的代码量,缩小一些反复操作,我认为当你写vue3时,应该把这当作默认写法。 在vue3.2之前,个别会这样写。

<script>
   export default {
     setup(props,ctx){
      const a = ref(0)
      //必须return能力在template中应用,这里就存在一个反复操作的问题,每次都得cv,万一遗记就得查看
      return {
          a
      }
     }
   }
</script>

那么当初,咱们能够这样写,比照一下,缩小了多少行代码呢

<script setup>
    const a = ref(0)
</script>
PS:之后的代码我会省略script setup,默认都在script setup标签下。
兴许你会感觉这样就更简略了,其实恰恰相反,CompositionAPI其实要求你对逻辑解决有更清晰的意识,对于封装有更高的要求,否则,你一样会写成比以前更丑的代码。
例如:

 const a = ref(0)
   const b = ref('')
   const c = ref(true)
   const d = reactive({})
   const actionA = ()=>{a.value++}
   const actionC = ()=>{c.value=!c.value}
   const actionB = ()=>{b.value += 'test' }
   const actiond = async ( )=> {
       const res =  await ajax(`url`)
       d.a = res.a
       d.b = res.b
       d.c = res.c
   }
   const resetD = ()=>{
       Object.keys(d).forEach(key=>delete d[key])
   }

这一堆代码其实就是当你没有思考逻辑,没有想过封装的时候,像流水账一样间接写进去的代码,这些代码真的比optionsApi更好浏览吗,当然不。
这里更加凌乱,你很难一眼看出某个函数用的是哪个变量,程序凌乱,这时候须要封装,须要组合,这也是CompositionAPI的含意之一。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理