I'm wondering if this shouldn't actually be the default, I would even not add this as an option as this would simplify the code if a value is null we just skip it. The JsonStreamer should be used for maximum performances,null values just add noise and have rather few impact when used in Javascript as they'll just get evaluated asundefined.

I agree with@soyuka; in my opinion, the less noise we have, the better. I updated the PR in that way.

Let's target 7.3 then

This PR needs#60544, which has been merged in 7.4.
Maybe we can backport it - as it is only internal changes?

Omitting a property from the JSON or setting it tonull is not equivalent, and might behave differently:

• it is observable in Javascript, which hasundefined andnull as different types (and if you doa.myProp === null, it won't be true forundefined)
• it is different in term of OpenAPI or json-schema specs (it is possible to have a nullable required property in such spec)
• it might have an impact for parsers in other languages that might be strict about such properties

Always stripping null properties from the output is a no-go to me, as it makes the component incompatible with some kinds of output (and this would be a BC break for projects that rely on those cases)

I agree with@stof: consuming APIs with fields that can sometimes appear or disappear can really be disturbing. That's also true if a documentation is provided: the response may be different from what's written in the doc because some fields are missing.

To me, it is semantically really different to have a null value or no value at all and it may not be treated the same way in underlying code. The option you proposed first,skip_null_properties, looks better to me.

I see your point, I'm convinced the null type may be required in JSON. I still think that the default for this component should be that it's disabled by default. From an architecture point of view, when it comes to resource oriented APIs or JSON-LD, we don't recommend the use of null values, it adds unnecessary noise and adds complexity to front ends.
Also as we're all about performances and band-width consumption when it comes to streaming I think that we should go with the less the better.

You're right@stof, omitting a property from the JSON or setting it tonull is not the same.
Therefore, I reintroduced the option, but inverted it so that the default will be to omit null properties (the option becameinclude_nullable_properties).

Ah yes! I wanted to comment back to suggest an opt-in to include null values but forgot about it. It seems to be the good compromise!

What aboutinclude_null_values instead ofinclude_nullable_properties?

This might be misleading, IMO.
For example, if we want to stream[null, null, null], withoutinclude_null_values, what can we expect?[null, null, null]?[]? "property" here is important to me.

include_nullable_properties gives the impression that if set to false, properties thatcould be null will not be included in the output. That's why I'm a bit reluctant for this naming

I see your point, therefore what aboutinclude_null_properties, or maybeinclude_null_property_values?

Both removes the ambiguity, definitely better! Maybe the first one is more accurate (because you include the property and its value, not only the value)

I went forinclude_null_properties.

rebase needed
still 👍 on my side

Thank you@mtarld.