前言

最近接手了一個新項目，用的是VUE3+pinia的組合。由于之前沒有用過這2個庫，只能現(xiàn)學現(xiàn)做。幸運的是這兩者的上手難度都不大，項目可以正常開發(fā)。但這其中也遇到了一些坑，今天就來講其中我印象最深的一個。

An Object could not be cloned？

不知道有多少開發(fā)者遇到過這個報錯——An Object could not be cloned

本人這里是一個electron項目，在使用ipcRenderer.invoke通訊時傳入了一個對象，就拋出了這個錯了。把傳入的對象打印出來，發(fā)現(xiàn)對象里有字段被轉(zhuǎn)成了proxy對象，估計就是在ipcRenderer.invoke處理proxy的時候無法處理，因此報錯。

VUE 3的toRaw

我們都知道VUE 3 相比VUE 2在響應(yīng)式數(shù)據(jù)的處理上有著巨大的改動，從2的Object.defineProperty到3的proxy。而為了讓用戶可以自行選擇是否使用響應(yīng)式，VUE 3提供了 reactive，ref等API。在把數(shù)據(jù)轉(zhuǎn)成響應(yīng)式之后，數(shù)據(jù)就已經(jīng)被VUE修改成一個新的對象了，通過打印我們可以看到。

const obj = reactive({ a: 1, b: 2 });
console.log(obj);

當然為了避免上述我遇到的這類問題，VUE 3提供了一個API讓用戶可以把proxy對象轉(zhuǎn)回原生的對象。這個API就是toRaw()。

const obj = reactive({ a: 1, b: 2 });
console.log(obj);
console.log(toRaw(obj));

有了toRaw之后，理應(yīng)不會遇到什么問題了?？墒窃谖业膱鼍袄镉钟幸粋€情況，就是混用了PINIA。

PINIA與VUE 3可以混合搭配？

PINIA是公認下一代的“VUEX”，同樣有著與VUEX一樣的特性——與VUE搭配使用會更加流程。但要注意的一點是，PINIA并不是VUE的專屬，也就是說無論你開發(fā)的是什么項目，只要用到JavaScript你就可以用PINIA。也正因此如此，似乎與前面提到的一點是沖突的，這也出現(xiàn)在了我的項目中。

我們先來寫一個簡單的PINIA store

// store.js
export const useCounterStore = defineStore('counter', {
  state: () => {
    return {
      myData: {
        o1: {
          b: 2
        },
        a: 1
      }
    }
  },
  actions: {
    setMyData(data) {
      this.myData = { ...data };
    },
  },
})

然后在VUE中使用

import { useCounterStore } from "./stores/index.js";
const counter = useCounterStore();
const obj = reactive({ a: 1, b: 2 });

console.log(counter.myData);
counter.setMyData({newO:obj});
console.log(counter.myData);

打印出來的結(jié)果如下：

我們發(fā)現(xiàn)這個myData對象是一個proxy嵌套proxy的對象。當我們想要讓他轉(zhuǎn)成原生對象時，在VUE 3項目中很自然會想到用toRaw。

console.log('toRaw',toRaw(counter.myData))

可是打印出來的結(jié)果是沒有把里面的proxy解開的。

正因為這樣所以我得到了本文最開始提到的報錯信息。

同樣的操作在VUE 3下的結(jié)果

遇到這樣的問題，我第一時間懷疑是不是因為我在用到 setMyData中用到了解構(gòu)語法。那如果同樣的寫法在VUE3 可行嗎？我們再來試一下：

const obj = reactive({ a: 1, b: 2 });
const obj2 = reactive({c:3,d:4});

obj2.d = {...obj};
console.log(obj2);

我們可以看到在VUE3中解構(gòu)寫法的賦值，并不會出現(xiàn)proxy嵌套的情況。說明VUE3在對自己的響應(yīng)式數(shù)據(jù)賦值的時候是做了專門的處理的。因此我們可以得到一個簡單的結(jié)論：PINIA與VUE3的搭配雖然在使用上可以很自然順暢，但他們并不是天生一對的。PINIA在數(shù)據(jù)賦值的時候沒有像VUE 3一樣有針對VUE 3響應(yīng)式數(shù)據(jù)的處理，同時VUE 3的toRaw也沒有辦法為PINIA的數(shù)據(jù)完美的還原。

最后的解決方式

說完了問題的原因，簡單來提一下本文錯誤的解決方案。其實說到底我們的目標就是要得到一個“干凈”的對象。我最后用是JSON.stringify()解決的，也說明了JSON.stringify的處理是可以解決proxy嵌套的。

console.log(counter.myData);
console.log(JSON.stringify(counter.myData));

當然我的同事用lodash的omit方法也可以解決，只是我覺得JSON.stringify會更加的“原生”。關(guān)于lodash的omit更多信息可以看：www.lodashjs.com/docs/lodash…

總結(jié)

相信并不是很多人會遇到我的這種情況，我也知道手上的項目代碼中有很多可以優(yōu)化的地方（我是中途加入這個項目的）。但本文想要分享的是在VUE 3搭配PINIA做項目開發(fā)的時候，有可能會遇到的問題。以及表明他們兩并不是“天生一對”的，當然對于這個問題不知道后續(xù)會不會被優(yōu)化。我個人是覺得如果把他們看作是兩個獨立的工具，其實這個并不是BUG，更多的是開發(fā)者的“一廂情愿”。

最后，希望本文可以幫助到一些開發(fā)者，在開發(fā)過程中避免掉坑。

到此這篇關(guān)于vue3搭配pinia踩坑的文章就介紹到這了,更多相關(guān)vue3 pinia踩坑內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論