完成第一個 Vue3.2 項目後，使用體會

第一次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的含義之一。

/usePage.js
export default ()=>{
    const a = ref(0)
   const b = ref('')
   const c = ref(true)
    const actionA = ()=>{a.value++}
   const actionC = ()=>{c.value=!c.value}
   const actionB = ()=>{b.value += 'test' }
   //這時候需要寫return
   return {
       a,actionA，
       b,actionB,
       c,actionC
   }
}
// usePageD.js
export default ()=>{
const d = reactive({})
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])
   }
   return {
       d,actionD,resetD
   }
}

這時候，當我們在不同的組件中使用時，我們可以按需使用，假設我們現在有A和D兩個組件

//組件A
import usePage from './usePage'
const {a,actionA} = usePage()

//組件D
import usePage from './usePageD'
const {actionD,resetD} = usePageD()

上述兩種，自然時封裝組合後更好閱讀。更方便的是，他有更好玩的用法。我目前這個項目是一個iOS混合開發的,這其中必不可少的需要用的jsBridge，由於iOS原生的限制，所有回調都是通過其他函數接收的。例如，下方是我調取原生A方法時的代碼

//jsBridge.js
const callBridge = (msg)=>{
 try {
     window.webkit.xxxHandler.postMessage(msg)
 }catch(e){
     console.log(msg)
 }
}
export const bridgeA = (id,cb='')=>{
    const msg = {
     func:'A',
     params:{id},
     cb
    }
    callBridge(msg)
}

而原生則會這樣告訴我結果(這塊是偽代碼，畢竟我不會iOS)

evaluateJavaScript(cb(data))

當我使用的時候，就會有這種邏輯

//App.vue
const store = useStore()
window.test = function(data){
    store.commit('saveA',data)
} 
//其他組件中
const handleClick = ()=>{
    bridgeA('123','test')
}

而現在，我可以不需要通過vuex了,這樣寫不香嗎？

//useBridgeA.js
export default ()=>{
const id = ref('')
const saved = reactive({})
window.test = function(data){
    saved.data = data    
}
const handleClick = ()=>{
    bridgeA('123','test')
}
onBeforeUnmount(()=>{window.test = null})
return {saved,handleClick,id}
}

最妙的是，這裡實現當使用時註冊回調，不使用時移除，通過reactive通信,而且可以把回調方法隱藏起來，我需要的只是結果，而不需要把所有代碼都在外層。
當我寫組件時，代碼將更加簡單

<template>
  <input v-model="id" />
  <button @click="handleClick">
    Action A
  </button>
</template>
<script setup>
  import useBridgeA from './useBridgeA'
  const {id,handleClick} = useBridgeA()
</script>

這裡其實我也確立了一些我的vue3的寫法吧。
組合不僅是功能點的組合，更是把一些關聯性比較高的方法，變數放到一起。
在上面這個例子，其實我們可以把回調方法再抽離出來，放一個單獨的文件中，我再import，但是這樣只會讓項目文件越來越多，每次查找的文件越來越多罷了。

思考setup

很少有人會去想，為什麼這個新的生命周期叫setup，set up 有建立的意思，難道意思僅僅是這個App創建時嗎，那麼created顯然更好理解一些。
我認為，setup是一個鏈接，是把數據和template連接起來的一個橋梁，因此才會使用這個動詞，本質上這不是一個生命周期，是一個動作，是我們把數據和Vue連接起來。
我把你做的webApp比作一臺機器，setup就好比電源線，你把你變數，邏輯作為電源，輸入到電源線，機器就啟動了。

最常見的問題，忘記寫.value

其實在vue3中，我更喜歡用ref,ref結構簡單，有著更可靠更方便的響應式。例如，當我們需要聲明一個響應式的對象時，你可以有這兩種寫法

const a = shallowRef({})
const b = reactive({})

但是，當你需要替換整個對象時怎麼辦？對於變數來說，直接修改value即可。

a.value = {c:1}

對於變數b，那就麻煩了，如果你的對象層級比較簡單，我能想到的方法就是用Object.assign

Object.assign(b,{c:1})

如果只是刪除這個c這屬性，對於變數a,很簡單

a.value = {}

對於變數b呢，使用了reactive的那個呢，顯然更加麻煩

b=reactive({}) // 報錯

能直接這樣寫嗎，不行，這樣會報錯，因為b是一個const。於是乎，你簡單的思考一下，把const 改為let

let b = reactive({})
b.c = 1
b = reactive({})

理論上這樣沒有問題，在b沒有別的依賴或者是被別的變數依賴的時候。某種程度上講，這樣也會丟失響應性。你只能這樣做，這也是我之前為什麼要寫reset的原因

delete b.c
//假設b這個變數中有很多屬性，則需要遍歷
Object.keys(b).forEach(key=>delete b[key])

上面這些其實都是一些容易被忽略的點，也是我為什麼更推薦ref的原因，但是有利有弊，ref最大的問題是容易忘記寫.value

const a = ref(0)
a=1 //報錯
//做判斷的時候
if(a){ //永遠為true,因為a是一個對象，不是數字}

這時候，我推薦你使用unref，上面的if判斷應該這樣寫

const a = ref(0)
if(unref(a)>0){
  // do sth
} else {
  // do another
}

你可以毫無心智負擔的使用unref,哪怕這個變數不是ref

style v-bind 的優缺點

style v-bind可能很多人不熟悉，我把這稱之為vue對css變數的hack。我項目中偶也也會使用一些css變數。
具體的css變數的教程，大家可以看一下這個鏈接www.ruanyifeng.com/blog/2017/05/css-variables.html

<template>
  <p>123</p>
</template>
<style scoped>
  p{
    color:var(--pcolor)
  }
</style>

這樣是純粹的原生css的寫法，vue幫我們做了一個hack.這裡需要註意，style中的v-bind裡面是一個字元串。

<template>
  <p>123</p>
</template>
<script setup>
  const pcolor = ref('#000')
</script>
<style scoped>
  p{
    color:v-bind('pcolor')
  }
</style>

但是我發現一個問題，在某些情況下的偽元素中的content屬性似乎不生效,依舊是上面那個模板，我多寫幾個p

<template>
  <div>
    <p>123</p>
    <p>123</p>
    <p>123</p>
    <p>123</p>
  </div>
</template>
<script setup>
  const text = ref('hello')
</script>
<style scoped>
  div p:first-of-type:before{
    content:v-bind('text')
  }
</style>

這時候v-bind似乎沒生效，這個偽元素不顯示，也不知道是bug還是什麼，這時候我建議你這樣寫

<template>
  <div>
    <p :data-text="text">123</p>
    <p>123</p>
    <p>123</p>
    <p>123</p>
  </div>
</template>
<script setup>
  const text = ref('hello')
</script>
<style scoped>
  div p:first-of-type:before{
    content:attr(data-text)
  }
</style>

pinia or not

pinia約等於vuex5，使用起來和vuex稍有不同，我在項目中是這樣使用的

// store/user.js中定義具體的store
export const UserStore =  defineStore('user', {
  state:()=>({
    name:'',
    id:''
  })
  getters:{
    nameId:state=>```{state.name}_``{state.id}`
  }
actions:{
  async getUserInfo(){}
}
})

//store/index.js
//這樣寫的好處是，以後引用的時候可以直接from '@/store'，並且當文件多了，可以用通過webpack的require.context或者vite的import blob來自動處理
export {UserStore} from './user'

比vuex來說少了一個mutation,也不能說沒有，只是用$patch函數代替了,使用起來更靈活

import UserStore from  '@/store'
const user = UserStore()
user.name = 'test'
//or
user.$patch({
  name:'test',
  id:123
})
//or 
user.$patch(state =>{
  state.name = 'test'
  state.id = 123
})