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
Hi. I have a few questions regarding GraphQlQueryParameter<T> and QueryBuilderParameter<T> design.
The first one is used to create the parametrized query (WithParameter method). The second is to provide an inline arguments value or parameter name (With{FIELD} methods).
GraphQlQueryParameter<T> has a few constructors. When using
I expect the nullability to be inferred from the T nullability, including respecting the NRT if enabled. But instead, it always creates nullable arguments. For example, Int instead of Int!. It also seems to have a bug in the following line because ? shouldn't be appended to the graphql type name:
That allows to define the nullability manually, but T defaultValue is required in this constructor. Any reason why I can't override the nullability without specifying the default value?
The QueryBuilderParameter<T> doesn't have public constructors. This forces me to use GraphQlQueryParameter<T> and provide redundant parameters like graphql type name or isNullable and enforces validations that are not relevant here. I understand that I can reuse an instance that was passed into WithParameter but it makes the API "less fluent". I also understand that adding a public constructor with a single argument for a parameter name will create ambiguity with a private constructor when T is string, but maybe design can be changed slightly to allow simple creation of the QueryBuilderParameter<T> instance.
The text was updated successfully, but these errors were encountered:
one problem with the nullability is that it's not only specified by the type itself. You can pass the value hard coded in the query string as within the parameter object so null value can be passed to parameter that is defined as not null.
public GraphQlQueryParameter(string name, string graphQlTypeName, T defaultValue) probably should be market obsolete, it comes from the time where there wasn't complete bidirectional mapping between the GQL types and the generated .NET types. Hopefully that is now complete so it shouldn't be any reason to pass graphQlTypeName manually.
Yeah, I understand that user will always find a way to misuse the library :)
But I think, providing defaults that will hit most of the time is better than just make everything nullable by default.
And workarouds for possible bugs is a good enough reason to keep the graphqlTypeName #130
Hi. I have a few questions regarding
GraphQlQueryParameter<T>
andQueryBuilderParameter<T>
design.The first one is used to create the parametrized query (
WithParameter
method). The second is to provide an inline arguments value or parameter name (With{FIELD}
methods).GraphQlQueryParameter<T>
has a few constructors. When usingI expect the nullability to be inferred from the
T
nullability, including respecting the NRT if enabled. But instead, it always creates nullable arguments. For example,Int
instead ofInt!
. It also seems to have a bug in the following line because?
shouldn't be appended to the graphql type name:So, my question is if there is any reason why this constructor won't be able to infer the nullability from the
T
?That allows to define the nullability manually, but
T defaultValue
is required in this constructor. Any reason why I can't override the nullability without specifying the default value?QueryBuilderParameter<T>
doesn't have public constructors. This forces me to useGraphQlQueryParameter<T>
and provide redundant parameters like graphql type name orisNullable
and enforces validations that are not relevant here. I understand that I can reuse an instance that was passed intoWithParameter
but it makes the API "less fluent". I also understand that adding a public constructor with a single argument for a parameter name will create ambiguity with a private constructor whenT
isstring
, but maybe design can be changed slightly to allow simple creation of theQueryBuilderParameter<T>
instance.The text was updated successfully, but these errors were encountered: