Improve doc of additionalResolvers sourceArgs

[NicolasMahe]

I just find out by a random test that's possible to specify a value inside object using the dot notation (condition.assetId) in the sourceArgs in additionalResolvers:

additionalResolvers:
  - targetTypeName: Query
    ...
    sourceArgs:
      condition.assetId: "{root.id}"

It would be nice to add this to the doc with at least an example.

---

I think the documentation is missing a section explaining all the features possible in the yaml file.

As another argument for you to consider the doc improvement: I recently experienced the same random discovery about env in the yaml file: #2986.

[santino]

Thanks for raising this.

It would be great if you could contribute to improving the documentation.
Do you feel you would be able to raise a PR for this?

[cancan101]

Can you run arbitrary js iside the sourceArgs resolver? For example if I have an array of key/value pairs and I want to filter for a specific one:

    sourceArgs:
      inviteeEmail: "{root.fields.filter(x => x.key === 'email')[0].value}"

and if this does not work, is there another way to get the same effect?

[ardatan]

Currently it is not possible. You should write the resolver in code.

[cancan101]

Is it possible to write an additional resolver that runs on the source beforehand so that the value can then be extracted using the sourceArgs? My naive approach where I wrote the resolver + requested that field in requiredSelectionSet did not seem to work where the value shows up in the args.

[ardatan]

It is possible to define the required selection set in a programmatic resolver definition.

{
   SomeType: {
      myField: {
         selectionSet: /* GraphQL */`
           {
              fields {
                 key
                 value
              }
           }
         `,
         resolve: (root, args, context, info) => {
            return context.SomeAPI.Query.someField({
               args: {
                  inviteeEmail: root.fields.filter(x => x.key === 'email')[0].value
               },
               context,
               info
            })
         }
      }
   }
}

[Urigo]

Is someone here willing to take all the info from this issue and add it to the right place to our docs?
It would be very helpful and a great way to contribute
Thanks!

[cancan101]

It is possible to define the required selection set in a programmatic resolver definition.

{
   SomeType: {
      myField: {
         selectionSet: /* GraphQL */`
           {
              fields {
                 key
                 value
              }
           }
         `,
         resolve: (root, args, context, info) => {
            return context.SomeAPI.Query.someField({
               args: {
                  inviteeEmail: root.fields.filter(x => x.key === 'email')[0].value
               },
               context,
               info
            })
         }
      }
   }
}

I am trying this, but await context.SomeAPI.Query.someField(...) is returning null and I am trying to debug. Is there anything like includeHttpDetailsInExtensions so that I can see what HTTP requests / responses are happening in the underlying call?

For reference, when I used the declarative resolver in the yaml file, everything worked fine.

[cancan101]

Ok so the issue is that the call to context.SomeAPI.Query.someField needs to include a sourceSet. It looks like when using the declarative API, generateSelectionSetFactory in involved to generate this value. Is there any reason that generateSelectionSetFactory or something like it isn't exposed publicly?

https://github.com/Urigo/graphql-mesh/blob/ee592adbfb3a73f91f4694c03fdca6b55553f925/packages/utils/src/resolve-additional-resolvers.ts#L47-L135

[ardatan]

@cancan101 That helper function is useful for declarative API and programmatic API shouldn't need that. If you provide a working example, we can help you better.

[cancan101]

The issue is that the source nests the data under a key:

    sourceName: Calendly 
    sourceTypeName: Query 
    sourceFieldName: Calendly_getScheduledEvents 
    result: collection # nested

so when I call context.Calendly.Query.Calendly_getScheduledEvents, the selection set has to be:
{ collection { PASS_THROUGH_SELECTION } } and this is where generateSelectionSetFactory is helpful for working with the ast