Proposal: explicitly declaring resolvers with decorator
See original GitHub issueclass MySecondAttempt(ObjectType):
name = String()
age = Int(required=True)
@name.resolver
def resolve_name(self, ...): ...
@age.resolver
def resolve_age(self, ...): ...
Explicit is better than implicit.
The resolvers could have any arbitrary name, and could also be defined before or after the class definition. Resolvers could still be defined using the resolver_
prefix convention if the explicit decorator isn’t used.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:8 (2 by maintainers)
Top Results From Across the Web
Resolvers - TypeGraphQL
Besides declaring GraphQL's object types, TypeGraphQL allows to create queries, mutations and field resolvers in an easy way - like a normal class...
Read more >type-graphql/Lobby - Gitter
Following is my resolver with the @Arg decorator: @Resolver() export default class TimesheetResolver implements TimesheetQuery { @Query(() => [Timesheet]) async ...
Read more >applyResolversEnhanceMap not adding custom decorators to ...
I'm using the typegraphql-prisma package and am trying to apply custom decorators to my generated resolvers to no avail.
Read more >Building GraphQL APIs with TypeGraphQL and TypeORM
With TypeGraphQL, however, we don't need to explicitly write the schema. Instead, we define our resolvers with TypeScript classes and decorators ...
Read more >Upgrade to Babel 7 (API)
We recommend using babel-plugin-module-resolver@3 's 'resolvePath' options ... plugin has been implemented, which implements the new decorators proposal.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I really like the idea of declaring resolvers with a decorator. There are a couple of patterns that are possible tho. A pattern that I stumbled across recently works pretty well for declaring functions alongside their schema definition. Maybe we should do an evaluation of different approaches?
Here’s a type with both default and custom resolvers for fields, using a decorator pattern for declaring custom resolvers and schema at the same time.
The decorator implementation is pretty simple:
I don’t expect that this would break any of the existing Field API. It also removes the possibility that a
resolve_XXX
method name could be mistyped - the field and resolver are defined in one go.The only strange thing about this approach is that it is a little unexpected that we define a function and our decorator replaces that function reference with a reference to an Field object that contains that function reference, but it makes for pretty clean Graphene code. You also can’t use this decorator on a function outside of a your ObjectType class.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.