c# 8 non nullable types suppport in query types and etc

[aammfe]

Hello!
as title stated. is there any plans to add support for c# 8 non nullable https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references) types?

right now we have to explicitly tell what's nullable or not.

my actual intentions are query type should be as close as POCOs

[sungam3r]

This is a pretty big feature. It requires a lot of refactoring and redesigning. In any case, I think it's too early to talk about it before the final release (not preview 6,7,8...) of the netcore 3 release.

[aammfe]

More I'm thinking about it more Its clearing.

 public class StarWarsMutation : ObjectGraphType
    {
        public StarWarsMutation(StarWarsData data)
        {
            Name = "Mutation";

            Field<HumanType>(
                "createHuman",
                arguments: new QueryArguments(
                    new QueryArgument<NonNullGraphType<HumanInputType>> {Name = "human"}
                ),
                resolve: context =>
                {
                    var human = context.GetArgument<Human>("human");
                    return data.AddHuman(human);
                });
        }
    }

public class HumanInputType : InputObjectGraphType<Human>
   {
       public HumanInputType()
       {
           Name = "HumanInput";
           Field(x => x.Name);
           Field(x => x.HomePlanet, nullable: true);
       }
   }

its declaring more or less these things

1. types and their fields
2. mutations/queries arguments and its types
3. type is nullable, or non nullable
4. types, fields name and description
5. mutations/queries resolver

Possible Solutions 3 after C# 8 non nullable reference types it could be resolve // we have discussed it.

1, 2, 5 it seems like type = class field = property mutation/query = function mutation/query params = function params

and 4th one can be resolve by c# documentation-comments Like this

/// <summary>This constructor initializes the new Point to
///    (<paramref name="xor"/>,<paramref name="yor"/>).</summary>
/// <param name="xor">the new Point's x-coordinate.</param>
/// <param name="yor">the new Point's y-coordinate.</param>

public Point(int xor, int yor) {
    X = xor;
    Y = yor;
}

What I m trying to say is if we use c# full features we can simplify Graphql just to simple class, property and function.

[sungam3r]

To be honest, I can’t imagine how C# 8 features can help in this matter. Perhaps you talking about schema first approach by which we can map sdl schema to "simple" classes.

[aammfe]

I m not talking about schema first. I m talking about type first. bcs it has more power.

but at the end both will be entertained by this feature.

[ryanmaxwell]

I agree that it would be nice for the nullability of the built field to be driven by the c# type. e.g. If the underlying type has nullability enabled, then you should be able to omit the nullable argument from the field resolver and for the information to be inferred automatically by the backing type for the cases where there is an implicit type mapping from c# object to schema type.

e.g. Field(x => x.HomePlanet, nullable: true); could become Field(x => x.HomePlanet);.

C# type -> schema type string -> String! string? -> String etc.

[aammfe]

Any news ?

[sungam3r]

In principle, it is possible. There are subtleties with reading attributes. I think that when ApiApprover/ApiApprover#54 is ready, we can do this too.

[aammfe]

More I'm thinking about it more Its clearing.

 public class StarWarsMutation : ObjectGraphType
    {
        public StarWarsMutation(StarWarsData data)
        {
            Name = "Mutation";

            Field<HumanType>(
                "createHuman",
                arguments: new QueryArguments(
                    new QueryArgument<NonNullGraphType<HumanInputType>> {Name = "human"}
                ),
                resolve: context =>
                {
                    var human = context.GetArgument<Human>("human");
                    return data.AddHuman(human);
                });
        }
    }

public class HumanInputType : InputObjectGraphType<Human>
   {
       public HumanInputType()
       {
           Name = "HumanInput";
           Field(x => x.Name);
           Field(x => x.HomePlanet, nullable: true);
       }
   }

its declaring more or less these things

1. types and their fields
2. mutations/queries arguments and its types
3. type is nullable, or non nullable
4. types, fields name and description
5. mutations/queries resolver

Possible Solutions 3 after C# 8 non nullable reference types it could be resolve // we have discussed it.

1, 2, 5 it seems like type = class field = property mutation/query = function mutation/query params = function params

and 4th one can be resolve by c# documentation-comments Like this

/// <summary>This constructor initializes the new Point to
///    (<paramref name="xor"/>,<paramref name="yor"/>).</summary>
/// <param name="xor">the new Point's x-coordinate.</param>
/// <param name="yor">the new Point's y-coordinate.</param>

public Point(int xor, int yor) {
    X = xor;
    Y = yor;
}

What I m trying to say is if we use c# full features we can simplify Graphql just to simple class, property and function.

means we will have support for these simple (kinda poco) query and mutations classes ? :)

[sungam3r]

I don’t know yet, but at least it will be possible in some cases to stop setting the nullable property explicitly.

[sungam3r]

@Shane32 implemented NRT support for schema first.

[sungam3r]

https://github.com/graphql-dotnet/graphql-dotnet/pull/2902 https://github.com/graphql-dotnet/graphql-dotnet/pull/2891 https://github.com/graphql-dotnet/graphql-dotnet/pull/2884 https://github.com/graphql-dotnet/graphql-dotnet/pull/2882 https://github.com/graphql-dotnet/graphql-dotnet/pull/2880 https://github.com/graphql-dotnet/graphql-dotnet/pull/2879 https://github.com/graphql-dotnet/graphql-dotnet/pull/2877 https://github.com/graphql-dotnet/graphql-dotnet/pull/2875

[Shane32]

I m not talking about schema first. I m talking about type first. bcs it has more power.

but at the end both will be entertained by this feature.

Essentially this is what I’m implementing in:

• #2880
• #2884
• #2891
• #2892
• #2893

[Shane32]

There is a lot of work left before graphs can be completely “type first” but it is getting close.

[sungam3r]

@Shane32 any progress here since last year? Maybe close this one since formally GraphQL.NET has NRT support in type first?

[Shane32]

Agree