You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #55781. In general we want to be careful about adding more states in the JsonIgnoreCondition enum, and we generally want to encourage a contract model customization approach via #63686. However your proposals seem fairly straightforward and simple to implement, so I'd support their addition.
There should be WhenReadingNull too, I'm actually surprised that it's absent. Because the obsolete IgnoreNullValus was working on reading too.
For example:
Meanwhile you can't express such behavior with DefaultIgnoreCondition or the [JsonIgnore(Condition = ...)] yet the Microsoft Documentation says you not to use IgnoreNullValues when all the behavior of this property wasn't ported.
NB! small note that if you won't explicitly set the FirstName:null in json the the FirstName will have empty string after deserialization, but this is not enough.
I'd say this is a major problem when you want to counteract null values when some 3rd party sends you null but you don't want it to have, you want an empty array, empty string, etc etc instead.
FYI: the Newtonsoft.Json is able to ignore null values on reading with [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
Also, the issue #62086 shows that I'm not alone thinking the same way that there should be attribute for null deserialization and how misleading the documentation / obsolete attribute on IgnoreNullValues is.
This is a tremendous problem and I JUST ran into this during an upgrade.
The fact that this wasn't thought through as a potential migration path and called out in the documentation is incredibly frustrating, especially since as @ScarletKuro pointed out, this behavior previously worked in IgnoreNullValues and an upgrade has no immediately obvious backwards-compatible option.
It would be so greatly appreciated if there was a little more foresight around deprecating functionality coupled with an appreciation for how that functionality is being used, and a little less opinion on what you think is the appropriate usage, without regards to how it worked previously.
@layomia said to just suppress the warring and use IgnoreNullValues because they do not plan to remove it. But my problem with that is that IgnoreNullValues is an global parameter within JsonSerializerOptions and it works in both direction - serialization and deserialization. In my case, I want it to be only for deserialization. Also, I want to have control over what property can ignore null and what must not ignore on deserialization. Like having an attribute is nowhere close as having just IgnoreNullValues.
I know that the aim is not to copy paste Newtonsoft.Json features, but this one is a simple and useful feature(for some even a stop factor). I was surprised when team said they didn't find much reason to add it in JsonIgnoreCondition, but as I said earlier the ability to counteract nulls, for example, that you don't want the list to be null but empty array is pretty big already, imo.
Update: Also, what I found out, is that IgnoreNullValues is not supported for source generator(i.e. JsonSourceGenerationOptions) meanwhile there is support for the JsonIgnoreCondition that's another reason why there should be WhenReadingNull and etc options.
Activity
[-][API Proposal]: Extension `JsonIgnore`[/-][+][API Proposal]: Extend `JsonIgnoreCondition`[/+]eiriktsarpalis commentedon Mar 11, 2022
Related to #55781. In general we want to be careful about adding more states in the
JsonIgnoreConditionenum, and we generally want to encourage a contract model customization approach via #63686. However your proposals seem fairly straightforward and simple to implement, so I'd support their addition.eiriktsarpalis commentedon Mar 11, 2022
Tagging @layomia for a second opinion. If this seems reasonable, I think I can mark it ready for review.
Symbai commentedon Mar 12, 2022
#52584
ScarletKuro commentedon Jun 1, 2022
There should be
WhenReadingNulltoo, I'm actually surprised that it's absent. Because the obsoleteIgnoreNullValuswas working on reading too.For example:
And deserialization
This will produce:
Meanwhile you can't express such behavior with
DefaultIgnoreConditionor the[JsonIgnore(Condition = ...)]yet the Microsoft Documentation says you not to useIgnoreNullValueswhen all the behavior of this property wasn't ported.NB! small note that if you won't explicitly set the FirstName:null in json the the FirstName will have empty string after deserialization, but this is not enough.
I'd say this is a major problem when you want to counteract null values when some 3rd party sends you null but you don't want it to have, you want an empty array, empty string, etc etc instead.
FYI: the Newtonsoft.Json is able to ignore null values on reading with
[JsonProperty(NullValueHandling = NullValueHandling.Ignore)]Also, the issue #62086 shows that I'm not alone thinking the same way that there should be attribute for null deserialization and how misleading the documentation / obsolete attribute on
IgnoreNullValuesis.Stabzs commentedon Jun 16, 2022
This is a tremendous problem and I JUST ran into this during an upgrade.
The fact that this wasn't thought through as a potential migration path and called out in the documentation is incredibly frustrating, especially since as @ScarletKuro pointed out, this behavior previously worked in
IgnoreNullValuesand an upgrade has no immediately obvious backwards-compatible option.It would be so greatly appreciated if there was a little more foresight around deprecating functionality coupled with an appreciation for how that functionality is being used, and a little less opinion on what you think is the appropriate usage, without regards to how it worked previously.
ScarletKuro commentedon Jun 16, 2022
@layomia said to just suppress the warring and use
IgnoreNullValuesbecause they do not plan to remove it. But my problem with that is thatIgnoreNullValuesis an global parameter withinJsonSerializerOptionsand it works in both direction - serialization and deserialization. In my case, I want it to be only for deserialization. Also, I want to have control over what property can ignorenulland what must not ignore on deserialization. Like having an attribute is nowhere close as having justIgnoreNullValues.I know that the aim is not to copy paste Newtonsoft.Json features, but this one is a simple and useful feature(for some even a stop factor). I was surprised when team said they didn't find much reason to add it in JsonIgnoreCondition, but as I said earlier the ability to counteract nulls, for example, that you don't want the list to be null but empty array is pretty big already, imo.
Update: Also, what I found out, is that
IgnoreNullValuesis not supported for source generator(i.e.JsonSourceGenerationOptions) meanwhile there is support for theJsonIgnoreConditionthat's another reason why there should beWhenReadingNulland etc options.krwq commentedon Jun 28, 2022
@ScarletKuro with contract customization you can simply remove Get/Set from property to prevent serialization or deserialization
eiriktsarpalis commentedon Jun 28, 2022
@krwq would it be possible to write a small snippet here illustrating how this can be done?
22 remaining items
WeihanLi commentedon Aug 4, 2023
@ScarletKuro add a new proposal here #90011
eiriktsarpalis commentedon Aug 4, 2023
Let's use #83706 to track
WhenReadingNull.onurkanbakirci commentedon Sep 20, 2023
@eiriktsarpalis I've already implemented in #69574
WeihanLi commentedon Jul 3, 2024
Hello @onurkanbakirci are you still working on this? I'd like to try to take this if you're not going to implement this
eiriktsarpalis commentedon Jul 5, 2024
@WeihanLi feel free to open a PR.
eiriktsarpalis commentedon Jul 23, 2024
Moving to 10.0.0 since feature development for .NET 9 is now completed.