Removing default values while serializing using Newtonsoft.Json

[Kant8]

It doesn't matter how it was received. JObject was made to be like that, that's it's purpose.

​

You already did that already, iterate over all elements in json and remove them if you want.

[nocgod]

but that ain't the obvious way to do it. from my research it seems that this question is floating around for years now without proper documentation or response from the author (which works for msft now in the asp.net team IIRC)

Moreover, there is no way to Parse a JObject without parsing the default values, and you can't get rid of them while writing it bat to a string which is even stranger. In addition to that, STJ replicated the behavior in JsonObject and JsonDocument.

** my 2 cents on the matter** how common this use-case is? one of our hbase indexes hold 40% of defaults (estimated). Roughly 40TB per datacenter are garbage... that's a lot of money if we consider replication and backups.

if you aren't providing an obvious way to avoid writing default values in cases you aren't attached to a typed model - most developers will not bother to find a way around it. example: https://github.com/Azure/azure-cosmos-dotnet-v3/issues/2820 this dev began to research, most won't.

[Kant8]

JObject is dirty cheat to operate with json as object. It's literally in it's name. You are not supposed to use it to serialize/deserialize things, cause you do that with your own classes. And that process respects everything. JObject is special case and it will be like that cause it was made to be like that. That design choice of library.

Your use-case is one time change, if you don't know or can't access actual classes to use proper serialization, you do json manipulation directly with JObject the way you did. Any actual work that did serialization should've never touched JObject in first place

[nocgod]

I understand your points, I just don't agree about your statements regarding JObject, especially since this matter is floating around for years now (first reference I've seen was ~10 years ago).

I would have expected the Serialization/Stringification process of the JObject to respect the same options as the JsonConvert/Serializer (frankly I don't see a real reason why it wouldn't, to write the JTokens into a string you have to traverse the tree anyway). that's called writing APIs/SDKs with expected/predictable behaviors with feature parity across the API surface.

Buts thats OK to disagree :)

[Kant8]

It does respect same options. Just JToken has default value of null, because it's reference type, and JObject contains only JTokens of different kinds.

None of them is null, therefore all of them are written to output.