Relay: Pattern matching variables for queries in mutation.getFatQuery() ?

[joonhocho]

As I commented on https://github.com/facebook/relay/issues/1046#issuecomment-235314338, I want to have a fatQuery that matches all variables in the store so that I do not have to specify all variable possibilities stored in the current relay store.
I tried to not specify variable, but it fails the query validation.

For example,

getFatQuery() {
    return Relay.QL`
      fragment on Payload {
        viewer {
          fieldWithArguments(id: *, name: "a")
          // * as a wild card that matches all ids found in the current relay store.
        }
      }
    `;
  }

[joonhocho]

I also noticed that @relay(pattern: true) only applies to connections, not other fields with arguments.

[arypurnomoz]

is there anyway to declare variable for fatQuery?

[josephsavona]

Fat queries are evaluated without looking at arguments, so in the example it should be sufficient to write just fieldWithArguments in the fat query instead of fieldWithArguments(id: ...). If that isn't passing validation, we can change @relay(pattern: true) to apply to any fields within a fat query. The logic for handling this in the babel plugin - PRs welcome!

[joonhocho]

@josephsavona Are you sure that @relay(pattern: true) works on any fields? It didn't work for me when I tried as it caused validation error. I think it only works for relay connection fields.

[josephsavona]

Are you sure that @relay(pattern: true) works on any fields?

No, I suspect it won't. As I mentioned, though, we'd welcome a PR to support this.

[ddgromit]

I'm assuming in your example the arguments are required and you're (like me) expecting that fieldWithArguments @relay(pattern: true) will make those arguments not required. This errors out in GraphQL before it even gets to Relay.

In a relay ConnectionType all the arguments before, after, etc are optional. Omitting them passes GraphQL validation, but is caught at Relay validation time which checks that at least one exists or the pattern directive was provided. The validation happens in Relay so its pretty easy for Relay to get around it.

So to make this work, I think you'd have to override the ProvidedNonNullArguments validation here. Just a guess though. Does any of that make sense @josephsavona?

[ddgromit]

@josephsavona created a PR, would love some feedback https://github.com/facebook/relay/pull/1376

[dminkovsky]

In the meantime, suppose you pass the required field's value by hand. It appears that Relay ignores the value anyway and fetches the field for all previously used call values of the variable.

So say I have previously used jim and nancy as call variables for required variable name for field findPerson, then including field findPerson(name: "tom") in the fat query actually produces two aliases of findPerson in the query, one for jim and one for nancy but not one for tom. Which makes sense, but if that's the behavior, why require the field value at all? (I guess that's the point of this PR).

Anyway, while we have fat queries, it makes sense to be able to specify that a mutation affects only a certain combination of field/variable. Not all previously known calls. Does that make sense?

Anyway, I know fat queries are going away.

[wincent]

I'm going to close this now. Since this issue was created, we've made the new Relay.GraphQLMutation API public, and have also started rolling out new APIs and a new core to the master branch here. Neither of those APIs make use of fat queries any more, and we don't want to devote any further resources to working on the legacy system, so closing seems appropriate.

Thanks for everybody who participated in the discussion.