Limitations

While the plugin offers a lot of flexibility and functionality, there are some limitations that should be considered.

References are not persisted

Due to serialization process, references are lost on refresh. Consider the following:

const a = {
  1: 'one',
  2: 'two',
  // ...
}
const b = a

Before serialization, a and b point to the same object:

a === b // -> true

After deserialization, a and b are two different objects with the same content:

a === b // -> false

As a consequence, reactivity between a and b is lost.

Workaround

To get around this, you can exclude either a or b from being persisted (using the paths option) and use the afterRestore hook to re-populate them after hydration. That way a and b have the same refence again and reactivity is restored.

Non-primitive types are not persisted

Due to the serialization process, non-primitive types such as Date are not rehydrated as Date object but as string instead.

Workaround

To get around this you can:

• Use the afterRestore hook to recreate the objects after rehydration.
• Use a custom serializer that supports the data types you want to persist.

Storage must be synchronous

When providing a custom storage, its methods must be synchronous. This is due to Pinia's state subscription ($subscribe) being synchronous (like mutations).

Workaround

To add asynchronous behavior (such as using async storages), you can try subscribing to actions ($onAction).