Omit serializing optional fields

[rgjurgens]

Hi,

Is there a possibility to indicate that, when serializing a Dart object to JSON, to NOT have optionals in the keys? What I mean is this:

@jsonSerializable
class Foo {
  final String barA;
  final String? barB;
}

and that when serializing this to JSON, the JSON looks like:

{
    "barA": ""
}

and the key barB is just omitted?

Thanks!

[k-paxian]

Not at the moment, but we could easily introduce such flag on a class level and global scope. Thank you for a nice idea and support!

[rgjurgens]

Any idea when such a feature would be available? Some BE endpoints are not accepting unexpected JSON keys with a null value - but it helps simplify FE code

[k-paxian]

If it's just a case with the null values, you can already use this option to filter out those fields from the json output:

@Json(ignoreNullMembers: true)
@jsonSerializable
class Foo {
  final String barA;
  final String? barB;
}

or on a global scope

final json = JsonMapper.serialize(instance, SerializationOptions(ignoreNullMembers: true));

Another case is that you want to ignore/omit the optional field even if it has not null value assigned, would that case be useful too?

[rgjurgens]

Thanks! That looks like a perfect solution. For the second case you are mentioning: your library already has support for this case, right? Then you are using: @JsonProperty(ignore: true) ?

[k-paxian]

Surely, you can use @JsonProperty(ignore: true) on occasional basis, and when you have too many fields to annotate and they all have something in common, like mentioned above optionality aspect, you can reduce the need to overuse annotations by saying/configuring something more generic to target all of them at once across the entire project if you decide to follow such convention.

Just let me know if this kind of generic filtering is really needed and we could re-evaluate the need to implement it

[rgjurgens]

I think they both cover different scenarios. @JsonProperty(ignore: true) is used when you never want to serialize a property, and @Json(ignoreNullMembers: true) can be used when you only want to ignore null members. So they both make sense, right?

[k-paxian]

yes, exactly that.

My suggestion was to address/target a set of optional fields to potentially reduce the need for individual configuration for each single of them. If you have a full stack convention to treat optional fields in a special way.

There is also a set of cases with the default values, like you can do something like that

@Json(ignoreDefaultMembers: true)
@jsonSerializable
class Foo {
  final String barA;
  @JsonProperty(defaultValue: 'none')
  final String? barB;
}

and it would be effectively the same thing. Additionally it will provide a default value when deserializing/instantiating this class on FE only.

[rgjurgens]

I think indeed @Json(ignoreNullMembers: true) for a whole class is fine. What will @JsonProperty(defaultValue: 'none') then do? Provide this value when serializing to JSON or when deserializing?

[k-paxian]

Provide this value when serializing to JSON or when deserializing?

both by default. Unless you say to ignore default value for serialization with @Json(ignoreDefaultMembers: true) or @JsonProperty(defaultValue: 'none', ignoreForSerialization: true) or @JsonProperty(defaultValue: 'none', ignoreForDeserialization: true)

[rgjurgens]

I don't quite understand. Can I now achieve what I want in my first question already? ignoreNullMembers is something different then ignoreForSerialization or ignoreDefaultMembers, right?

[k-paxian]

yes, those are all different concerns. For your use case it's enough ignoreNullMembers. I'm just exploring more options from this area for you 😄

[rgjurgens]

So you have support for this already? As you said:

Not at the moment, but we could easily introduce such flag on a class level and global scope. Thank you for a nice idea and support!

[k-paxian]

yes, ignoreNullMembers is there already. My initial guess was this flag is not enough to cover your case, so I imagined this as something new

[rgjurgens]

Ahhhhh, okay!