Feature enhancement: support deriving arguments?

[evbo]

I use a graphql client (Apollo-scalajs) which supplies the Variables of the Graphql Query in the form of a case class Scala object, e.g.: case class Variables(someArg: String)

So it would be nice to have full code reuse of my Sangria Argument objects and client Variables objects.

Currently I can deriveInputObjectType:

val someType = deriveInputObjectType[SomeType]()

But then I must manually define arguments:

Field("getStuff", ListType(ResultType),
        arguments = List(
          Argument("someArg", OptionInputType(ListInputType(someType))),
        ),
        resolve = c => ....
      )

Could there be some helper, that takes a case class, so that my client (scalajs) and server can reuse the scala object?:

someArgs = deriveArguments[Variables]()

so that it's reused in the server like:

Field("getStuff", ListType(ResultType),
        arguments = someArgs,
        resolve = c => ....
      )

[danestig]

I'm not sure I fully understand the issue here. But you. don't actually have to define your arguments explicitly. Take a look at the Deriving Methods with Arguments section of sangria documentation. Would this solve your use case?

[evbo]

Thanks, that is almost what I'm looking for. I am trying to store the Arguments to a graphql method in a case class, in hopes that both Sangria server could derive them as Arguments and so that my graphql client could reuse that same case class in definitions of query Variables: https://graphql.org/learn/queries/#variables

The documentation you pointed to is deriving the arguments from a method, but again graphql client Variables are an object, so I'm wondering if Sangria Arguments could be derived from an object too rather than a method.

So this enhancement would increase code reuse, in the case where both a scala sangria server uses the same object to derive Arguments as the scala.js client uses for defining Variables (in the same manner that InputObjectType and ObjectType can be derived from case classes reused by the client)

Code reuse like this is very nice, because it would ensure the signature is obeyed by both client and server anytime a refactor is made (the Variables being sent will automatically be in sync with the Arguments being received)