I believe "custom" is provided as a "escape hatch" for when using what the library provides is turning out to be inefficient / hairy.
Let's say we have a target class A which is such a class that can't be easily serialized with this library. And there are several other classes (B, C) which use this library just fine but have A as one of their fields.
class A { ... }
class B {
@serialized(custom(ASerializer, ADeserializer))
public a : A;
...
}
class C {
@serialized(list(custom(ASerializer, ADeserializer)))
public aList : A[];
...
}
Note that in the above, currently I have to mention the custom serializers for A in both field lists of B and C.
This is because custom serializers can only be applied to propschemas for now.
I'm wondering if the library could allow custom serializers for the entire modelschema, which would then make things simpler:
// somehow associate custom serializer as a modelschema for A. Perhaps a class decorator? or just a createModelSchema call?
class A { ... }
class B {
@serialized(object(A))
public a : A;
...
}
class C {
@serialized(list(object(A)))
public aList : A[];
...
}
I believe "custom" is provided as a "escape hatch" for when using what the library provides is turning out to be inefficient / hairy.
Let's say we have a target class
A
which is such a class that can't be easily serialized with this library. And there are several other classes (B
,C
) which use this library just fine but haveA
as one of their fields.Note that in the above, currently I have to mention the custom serializers for
A
in both field lists ofB
andC
.This is because custom serializers can only be applied to propschemas for now.
I'm wondering if the library could allow custom serializers for the entire modelschema, which would then make things simpler: