Args for non-root query fields

[hamzakubba]

Not sure if I'm overlooking something, but it seems like using mst-gql, it's only convenient to use args at the root level of queries.

So for example, let's take this included example: https://github.com/mobxjs/mst-gql/blob/7f2933a538abef815f9bffbff8ec04142920314c/examples/3-twitter-clone/src/app/models/RootStore.base.ts#L54-L58

Here (as in above), it's great that the first variables parameter is typed, and that the variables correspond to those args. Indeed, consuming it looks clean, such as here: https://github.com/mobxjs/mst-gql/blob/7f2933a538abef815f9bffbff8ec04142920314c/examples/3-twitter-clone/src/app/models/RootStore.ts#L43-L46

However, sometimes you want to pass in variables to args deeper in the tree. For example, let's say the gql query should ultimately look something like this:

query ($userId: ID!, $offset: ID, $count: Int, $replyTo: ID, $birthdayFormat: String) {
  user(userId: $userId) {   # note that i added this parent to messages
    messages(offset: $offset, count: $count, replyTo: $replyTo) {
      id
      likes
    }
    birthday(format: $birthdayFormat)
  }
}

That's a reasonable (or at least possible) way to structure a graphql request. If my request looked like that, the msq-gql scaffold would have a queryUser root action, but it would only accept userId as a variable/arg. That is, I would have no nice way to pass the messages args (offset, count, replyTo) and birthday arg (format) through the queryUser() interface. Selectors in general seem to completely overlook args as well?

What's the nice/elegant/correct mst-gql way to do a query like that one above? I realize I could always add my own actions to implement those things, but I got the impression the selector system would/should support something like that?

[arodik]

Would be great if we had something like this

queryUser({userId}, q => 
   q.messages({offset}, message => message.likes)
    .birthday({format})  
)

How possible is it to implement such functionality?

[beepsoft]

It seems like a duplicate of #272 and is now solved by PR #349. It is not yet released but merged into master.

[jesse-savary]

Should be resolved as of 0.17