question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: explicitly declaring resolvers with decorator

See original GitHub issue
class 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:open
  • Created 5 years ago
  • Reactions:2
  • Comments:8 (2 by maintainers)

github_iconTop GitHub Comments

2reactions
dvndrsncommented, May 20, 2019

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.

class StoryType(graphene.ObjectType):

    class Meta:
        interfaces = (graphene.Node, )
        possible_types = (models.Story, )

    title = graphene.String(description='stuff')
    subtitle = graphene.String()
    description = graphene.String()

    @resolves(graphene.String)
    def published_year(story: models.Story, info: graphene.ResolveInfo) -> str:
        return str(story.published_date.year)

The decorator implementation is pretty simple:

def resolves(field, *args, **kwargs):
    def decorate(resolver_function):
        return field(*args, **kwargs, resolver=resolver_function)

    return decorate

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.

0reactions
stale[bot]commented, Mar 26, 2020

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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found