Attributes which aren't in the constructor aren't serialized

[joostlek]

Hey,

I found an issue whilst working on my flutter app.

(Bit of context first)
I have an Activity, it's a base model, containing a DateTime, Firestore DocumentID, user and a type. That type is an enum, and currently I have ~11 activities, all inheriting the Activity class. And adding more attributes. This all works.

To deserialize the activities, I check on the Type attribute, and get the right class to construct the Activity with.

But because the Type of each different class is the same, I didn't include it as an argument in the constructor (When I am constructing a CreateUser, I don't want to send the type again because if I create a CreateUser, I want a CreateUser, not a CreateUser with a RemoveUser type)

So all the extended models have a constructor with a super constructor, and that type is not passed as argument but is just in the super call (CreateUser(.....) : Super(Activities.CreateUser).

This would create an object with type: CreateUser.

But when I am Serializing, it doesnt Serialize the type attribute. So when it's stored in Firestore it doesn't show what Type it is, thus I can't deserialize it, because I don't know what constructor I need to use.

I fixed this by just putting a , [Activities type] to the constructor.

Relevant code is in GitHub.com/joostlek/eros
(The lib/models/activity/Activity is the main class)

Thanks
Keep up the great work you re doing

[kevmoo]

That's a tricky one. I could imagine adding a special-case annotation for a field – something like "serialize me, even though I'm not in a ctor".

An interesting feature request. Sounds like you have a work-around.

[joostlek]

Yes, the workaround works, but having it working like intended is also a nice to have 😂

[dominickj-tdi]

I have a very similar situation. I want to have a 'type' field that is to be saved in the output JSON when I serialize an object, so I can read that field when deserializing so I know what type class to deserialize it as. My current workaround is adding an extra line to the toJson() method to manually add that missing attribute..

I previously mentioned this in a related issue, #24 It is essentially the same use case and probably the same solution would fix both of these issues.

[esDotDev]

Mentioned this here, but we have the exact same use case, we're sharing data classes on the backend, and we need to embed a type. #891

The work around of adding an optional field is not great, as it's mis-leading code. You're allowing the type can be overridden, which is a bug vector and could confuse some future developer.

[kevmoo]

Duplicate of #569

Trying to align all of these requests into one place!

[kevmoo]

I have a (draft) PR out on this. I'd LOVE (early) feedback about if this works for what folks need here: #1256

I still need to do some documentation and testing...