willResolveField triggers after resolver runs, not before resolver runs

[timcosta]

I believe this is more of a feature request than bug report, but the GraphQL Extension class has a function called willResolveField that is named in a misleading fashion. will implies that the field will be resolved after willResolveField is called, but the field is actually resolved before the call to willResolveField.

I'd like to suggest updating the name of this function to didResolveField and adding a new function called willResolveField that is triggered before the field's resolve function is called. This matches the pattern used by Reach and other places for lifecycle hooks.

[bardhi]

I am also seeing the same issue. FWIW, this seems to be a problem only on nested resolvers. For root resolvers, the function does what the name implies.

E.g. for a query like the following:

query {
  me{
    name
    friends {
      name
    }
  }
}

the order of calls is

1. Execute willResolveField for query.me
2. Execute resolver for me
3. Execute resolver for friends
4. Execute willResolveField for User.name (for the top-level user, i.e. me)
5. Execute willResolveField for User.friends (the actual resolver for this was executed in step Feature request: Providing an array of resolvers #3 above)
   6-N. Execute willResolveField for User.name for each of the friends above (N times for N friends).

[glasser]

This doesn't match my understanding of how this hook worked. That said, we removed the graphql-extensions API in Apollo Server v3 last year (replaced with the plugin API added in v2). If this is still an issue with the plugin API, please file a new issue. Sorry for the delay!