Only serialize properties that have been assigned

[NickStrupat]

Currently, ZeroQL will serialize a model to JSON text with all the properties, regardless of whether or not they've been assigned, except properties that have a value of null.

This is a problem for any nullable properties that should, during a mutation, be assigned to a value of null.

I propose that models should track which properties have been assigned, and only properties that have been assigned should be in the resulting payload to the server.

Below is an example of a possible implementation of what the generated model code would be...

class Foo
{
    private readonly Dictionary<string, object> assignedProperties = new(); // all models would have this field

    private string? text;
    public string? Text { get => text; set => assignedProperties["Text"] = text = value; }

    private int count;
    public int Count { get => text; set => assignedProperties["Count"] = text = value; }
}

And then whenever serialization happens, it would serialize foo.assignedProperties instead of foo itself.

[NickStrupat]

Hmm, that implementation idea wouldn't really help for the opposite: querying partial entities.

This might need something like Optional<T> for each property.

[byme8]

I saw that the StrawberryShake graphql client from HotChocolate is doing something similar like your first suggestion.

I have been thinking about adding it but never got a good use-case while using the ZeroQL.

[NickStrupat]

What about making a base class/interface for generated DTOs, and making it partial.

That way folks could add custom logic/validation with things like https://github.com/Fody/PropertyChanged. What I proposed could be implemented with that, I'm pretty sure...

[MausVlot]

I would really appreciate this feature! This is really starting to become an issue for me.
(Allows me to ditch update mutations and only use patch mutations)

[purquiz]

(Disclaimer - I used ChatGPT to organize my thoughts and put them in understandable writing)

Hi everyone. Let me first say that ZeroQL is fantastic — strongly typed, linq-like GraphQL is powerful and elegant. I have tried the fantastic Strawberry Shake as well, but the way ZeroQL reduces GraphQL complexity is unmatched.

I think I can provide a realistic use case that would be greatly improved if ZeroQL could just omit the null properties instead of serializing them to "null". This happens with Shopify.

Problem: When calling Shopify Admin GraphQL API using ZeroQL, nullable arguments passed as null are not omitted but instead serialized as arg: null.

However, in GraphQL there is an important semantic difference:

Argument omitted entirely --Means--> Use server default (whatever it is internally)
Argument sent as null --Means--> Invalid for non-nullable (!) params -> results in runtime error

Shopify Admin API defines some arguments (like sortKey in products) as non-nullable, but still optional — meaning they must be omitted when unused, not set to null.

ZeroQL currently forces developers to write branching logic for every optional argument:

if (opts.SortKey is null)
   return q.Products(first: opts.First, ...);
else
   return q.Products(first: opts.First, sortKey: opts.SortKey, ...);

This breaks composability, clarity, and usability for reusable query helpers.

Desired Behavior: If a parameter value is null, ZeroQL should omit the argument entirely in the generated GraphQL query, rather than sending arg: null.

Example

q.Products(first: 10, sortKey: null)

Should generate:

products(first: 10) {
  ...
}

Instead of:

products(first: 10, sortKey: null) {
  ...
}

Why this matters:

• Shopify’s Admin GraphQL API is widely used. Many arguments are effectively "optional but non-nullable"
• Developers expect nullable args to mean “optional”. Having to work around this issue requires the developer to create boilerplate and complexify API design.
• The desired behavior matches common GraphQL client expectations (Apollo, urql, graphql-request, etc.)

Suggested Implementation:

There can be many ways to achieve this. The simplest one is just set this as the default ZeroQL behavior:

Example:
if parameter == null, omit from serialization

Alternatively (or even complementarily), there can be an static global option to enable or disable this behavior.

Example:
ZeroQLSettings.OmitNullArguments = true;

Potential Benefits:

• More natural GraphQL semantics
• Cleaner consumer code
• Reduces branching and duplicate query expressions
• Improves ZeroQL ergonomics for large GraphQL APIs like Shopify, Hasura, etc.
• This small enhancement would dramatically improve developer experience and flexibility when integrating with real-world schemas.