Proper way to register custom type in store state?

[jdheeter]

Most of the Pinia examples are using simple primitive types. When using more complex custom types I'm finding that the type returned by the pinia store instance is "exploded" and no longer considered to be equal to the type assigned to the state which is defined in the store.

So for this pinia store, I would expect that tables.packs.cartoon is of type Packs[]

However when used in a .vue file

So all that gibberish is the actual type definition of Packs[]
and now tables.packs.cartoon is no longer of type Packs[]

Why is the type exploded open like this? It should simply be of type `Packs[]`

Is Pinia meant to only be used with basic primitives?

Here is the definition of the Packs type and Struct

@Struct.type('packs')
export class Packs extends Struct {
    @Struct.field(UInt64) template_id!: UInt64
    @Struct.field(Asset) base_price!: Asset
    @Struct.field(Asset) floor_price!: Asset
    @Struct.field(TimePointSec) last_sold!: TimePointSec
    @Struct.field('string') pack_name!: string
}

declare class Struct implements ABISerializableObject {
    static abiName: string;
    static abiFields: ABIField[];
    static abiBase: ABISerializableConstructor;
    static from<T extends StructConstructor>(this: T, value: any): InstanceType<T>;
    static from(value: any): unknown;
    static get structFields(): ABIField[];
    /** @internal */
    constructor(object: any);
    /**
     * Return true if this struct equals the other.
     *
     * Note: This compares the ABI encoded bytes of both structs, subclasses
     *       should implement their own fast equality check when possible.
     */
    equals(other: any): boolean;
    /** @internal */
    toJSON(): any;
}
declare namespace Struct {
    function type(name: string): <T extends StructConstructor>(struct: T) => T;
    function field(type: ABISerializableConstructor | string, options?: Partial<ABIField>): <T extends Struct>(target: T, name: string) => void;
}

[LinusBorg]

As a general advice:

Vue's reactivity work best with primitive data, that's true for both runtime and the types. And generally, it's also recommended to keep complex objects with side effects or complex internal state non-reactive, as you might get unintented side-effects when you make these object's properties reactive, depending on the internal interactions.

This specific issue is, as far as I can tell from the information provided, because of Generics not working too well with Vue's (type) unwrapping of refs when the generic could be a ref.

I can't pin it down for your types here as I don't know them all (i.e.: what's Int?), but generally, if a generic's specific value could potentially contain a ref(), then there can be a conflict because:

const x = { foo: ref('bar') }
// => shape: { foo: Ref<string> }

const reactiveX = reactive(x)
// => shape: { foo: string }

There are generally two ways to solve this depending on the requirements:

1. Typecasting
2. markRaw() to keep Vue from making complex objects reactive in the first place.
3. (2b) the whole state could maybe also be wrapped in a shallowReactive() which would make all root state properties reactive, but not their nested objects.

this is not a Pinia problem, so should be closed here (didn't realize this was a topic, not an issue ^^).

[jdheeter]

Very clear response. I wasn't aware of the utilities to limit reactivity on nested properties. Thanks!

[miquelromero]

Thanks for your clarifications. Could we expect in a future a way of getting the original types, or we should assume that we will have to typecast non-primitive types in pinia forever?