Closed jeffaburt closed 6 years ago
Hi @jeffaburt ,
You rock! Your suggestion makes total sense. Let me have a quick look into your PR as well as your DI pattern. I usually use the context of the resolver method (products(root, { id }, context)
) when I mock. I'm currently on holidays in Thailand and I'll be back on the 7th of August. I'll try to have a look before. Worst case scenario I'll have a look into that when I'm back.
Thanks a million time for your support and for helping us.
Cheers,
Nic
Thanks for the feedback and I hope you're enjoying your vacation! After looking at it again, I don't see a good reason not to just use the context argument in the resolver function, especially since it's already built in. I'll go ahead and close this PR in favor of that. Thanks again for an awesome library!
First off, I want to thank you for an awesome library! I recently started a greenfield project using GraphQL, and this library has been an awesome addition.
To facilitate functional dependency injection, I'm proposing to allow resolvers to be exported as functions with a single
context
argument. When glueing everything together usingglue('src/graphql', options)
,options.context
gets passed into each resolver'scontext
argument.context
is best used as a hash of dependencies. This pattern facilitates the unit testing of resolvers by allowing dependencies to be easily mocked.Basic example passing in raw data:
Advanced example passing in a curried function that encapsulates the shared database connection. This makes testing resolvers incredibly easy:
Thanks!