Invalid input type declaration order in client gen.

[gitmodimo]

Given schema.graphql:

input InputA{
 a: Boolean!
}

input InputB{
 b: Float!
}

input InputBC{
 c: ID!
 b: InputB!
}

input InputABCD{
 d: String!
 a: InputA!
 b: InputB!
 bc: [InputBC!]!
}

type Output{
	id:Boolean
}
type Control{
	test(new: InputABCD!): Output
}
type Query{
 control: Control!
}
type Mutation{
 control: Control!
}

type Subscription{
 control: Control!
}

schema{
 query: Query,
 mutation: Mutation,
 subscription: Subscription
}

and request.graphql

query testQuery($stream: InputABCD!) {
    control {
        test(new: $stream) {
          id
        }
      }
    
  }  

clientgen.exe --schema schema.graphql --request request.graphql --prefix GQL --namespace GQL
generates "GQLClient.h":

...
struct Variables
{
	struct InputABCD
	{
		response::StringType d {};
		InputA a {};
		InputB b {};
		std::vector<InputBC> bc {};
	};

	struct InputA
	{
		response::BooleanType a {};
	};

	struct InputB
	{
		response::FloatType b {};
	};

	struct InputBC
	{
		response::IdType c {};
		InputB b {};
	};

	InputABCD stream {};
};
...

Clearly order of Variables declaration is not correct since InputABCD depends on InputA and InputB.

I narrowed down the problem in RequestLoader::reorderInputTypeDependencies() to
_referencedInputTypes...->fields...->type().lock()->name() being "" (empty)
and
_referencedInputTypes...->fields...->type().lock()->kind() being NON_NULL.
for all types. I could not find root problem of this.

Additionally when I manually fix order of declaration in header file there are also errors in source file GQLClient.cpp:

template <>
response::Value ModifiedVariable<Variables::InputABCD>::serialize(Variables::InputABCD&& inputValue)
{
	response::Value result { response::Type::Map };

	result.emplace_back(R"js(d)js"s, ModifiedVariable<response::StringType>::serialize(std::move(inputValue.d)));
	result.emplace_back(R"js(a)js"s, ModifiedVariable<InputA>::serialize(std::move(inputValue.a)));
	result.emplace_back(R"js(b)js"s, ModifiedVariable<InputB>::serialize(std::move(inputValue.b)));
	result.emplace_back(R"js(bc)js"s, ModifiedVariable<InputBC>::serialize<TypeModifier::List>(std::move(inputValue.bc)));

	return result;
}

InputA, InputB and InputBC are not referred to using their namespace Variables::InputA etc.

[gitmodimo]

I managed to make a really ugly workaround
TBH I was really surprised that client generator does not use imput types generated by schemagen.

[wravery]

The part about missing Variables::... was fixed for the v3.x branch in #203 (and in #202 for the main branch, but I see you're using an older fork of 3.x).

It sounds like the reordering issue is caused by the NON_NULL wrapper type interfering with the detection of whether or not it's referenced. I don't remember any fixes that would affect that, so it probably does repro in v3.x and main.

[wravery]

The reference detection will probably have some overlap with the fix for #225.

[gitmodimo]

The part about missing Variables::... was fixed for the v3.x branch in #203 (and in #202 for the main branch, but I see you're using an older fork of 3.x).

I don't think it solves the problem since input type can contain other input types that are in Variable namespace. It should depend on type->kind().

[gitmodimo]

Upon further analysis it should be relatively easy to add clientgen switch to use types generated by schemagen (schema.h file).
With switch enabled:
-skip types definition
-use types from schema namespace
This would be useful l in my application, although it may be uncommon for one application to be server and client at the same time.

[wravery]

Upon further analysis it should be relatively easy to add clientgen switch to use types generated by schemagen (schema.h file). With switch enabled: -skip types definition -use types from schema namespace This would be useful l in my application, although it may be uncommon for one application to be server and client at the same time.

Yeah, I didn't want to couple the types between the client and the service like that. A pure client shouldn't need to include any service specific headers or link with any service support libraries, and vice versa. A service should also be able to talk to any client (especially any non-C++ client, which is most of them), and the client should be able to talk to any service, with the optimization of using response::Value directly instead of needing to parse JSON if it's talking to a schemagen service.

If the input types are identical (or at least, you can initialize them with the same syntax), then it might make sense to share common declarations for them. I need to do a little more research into that. This part likely overlaps with #218, which should generate some shared headers for clientgen.