preface

I recently took on a new project using a combination of VUE3+ Pinia. Since I haven’t used these two libraries before, I can only learn and do them as I go. Fortunately, both were easy to get started with and the project worked. But this also encountered some pits, today I will tell one of the most impressive.

An Object could not be empirical?

I don’t know how many developers have encountered this type of error — An Object could not be empirical

This error was thrown when an object was passed in using the ipcRenderer. Invoke communication. IpcRenderer. Invoke could not handle proxy when ipcRenderer. Invoke could not handle proxy.

VUE 3的toRaw

We all know that VUE 3 has a big change in reactive data handling compared to VUE 2, from object.defineProperty in 2 to proxy in 3. VUE 3 provides reactive, REF, and other apis to allow users to choose whether to use reactive or not. After converting the data to reactive, the data has been modified to a new object by VUE, as we can see by printing.

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

Of course, to avoid the kind of problems I encountered above, VUE 3 provides an API that lets users roll proxy objects back to their native ones. The API is toRaw().

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

With toRaw, there should be no problem. However, there was another situation in my scene where PINIA was mixed.

PINIA and VUE 3 can be mixed and matched?

PINIA is considered the next generation of “VUEX” and has the same features as VUEX — it’s much more streamlined when paired with VUE. It’s important to note, however, that PINIA is not exclusive to VUE, which means you can use PINIA whenever you’re working on JavaScript, no matter what project you’re working on. Therefore, it seems to be in conflict with the previous point, which also appears in my project.

Let’s start with a simple PINIA Store

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

It is then used in 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);
Copy the code

The printout looks like this:

We found that this myData object is a proxy nested proxy object. When we wanted to convert it to native objects, it was natural to use toRaw in VUE 3.

console.log('toRaw',toRaw(counter.myData))
Copy the code

But the printed result did not unhook the proxy inside.

That’s why I got the error message I mentioned at the beginning of this article.

The result of the same operation under VUE 3

When I encountered this problem, I immediately wondered if it was because I used the deconstruction syntax in using setMyData. What if the same writing works in VUE3? Let’s try it again:

const obj = reactive({ a: 1.b: 2 });
const obj2 = reactive({c:3.d:4}); obj2.d = {... obj};console.log(obj2);
Copy the code

We can see that in VUE3 the assignment of the deconstructed notation does not involve proxy nesting. VUE3 does special processing when assigning its own responsive data. The simple conclusion is that PINIA and VUE3 are not meant for each other, even if they work naturally. When assigning data, PINIA did not have the same processing for VUE 3’s responsive data as VUE 3, and toRaw of VUE 3 could not restore PINIA’s data perfectly.

The final solution

Having said the cause of the problem, I will briefly mention the wrong solution in this article. At the end of the day, the goal is to get a “clean” object. Json.stringify () can be used to handle proxy nesting.

console.log(counter.myData);
console.log(JSON.stringify(counter.myData));
Copy the code

Of course my colleague can also omit anything with Lodash, but I think json. stringify will be more “native”. About lodash omit more information we can see: www.lodashjs.com/docs/lodash…

conclusion

I’m sure not many people will encounter my situation, and I know that there are a lot of areas that can be optimized in the project code at hand (I joined the project in the middle). However, this article wants to share some of the problems you may encounter when developing projects with VUE 3 and PINIA. As well as showing that they are not “made for each other”, it is not known if this will be optimized in the future. I personally feel that if they are seen as two separate tools, this is not a BUG, but more of a “wishful thinking” by developers.

Finally, I hope this article can help some developers avoid pitfalls in the development process.