Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use resolver classes for queries by default #4513

Merged
merged 1 commit into from
Dec 18, 2023

Conversation

radar
Copy link
Contributor

@radar radar commented Jun 13, 2023

After raising #4468 and getting a thumbs-up from @rmosolgo about it, I've finally gotten around to issuing this PR.

I've updated the install generator to generate a base resolver class, and directed readers of the Getting Started guide to use this class when defining fields. Similar changes have been made elsewhere in the documentation as well.

Ultimately, the goal of this change is to alter the way types such as QueryType are defined. Currently, the suggestion is:

module Types
  class QueryType < Types::BaseObject
    # Add `node(id: ID!) and `nodes(ids: [ID!]!)`
    include GraphQL::Types::Relay::HasNodeField
    include GraphQL::Types::Relay::HasNodesField

    field :repos, [RepoType], null: false

    def repos
      Repo.all
    end

    field :repo, RepoResult, null: false do
      argument :id, ID, required: true
    end

    def repo(id:)
      Repo.find(id)
    end

    field :category, CategoryType, null: false do
      argument :id, ID, required: true
    end

    def category(id:)
      Category.find(id)
    end
  end
end

After this change, it will be:

module Types
  class QueryType < Types::BaseObject
    # Add `node(id: ID!) and `nodes(ids: [ID!]!)`
    include GraphQL::Types::Relay::HasNodeField
    include GraphQL::Types::Relay::HasNodesField

    field :repos, resolver: Resolvers::Repo::List
    field :repo, resolver: Resolvers::Repo::Find
    field :category, resolver: Resolvers::Category::Find

With each of those resolver classes defining the types, arguments and resolution techniques for the fields themselves.

I've intentionally left the definition and structure of those resolvers "loose", as I think it's one of those areas where every developer would have an opinion about The One True Way(tm) to structure these classes.

Where I work, we follow this pattern with some decent success, with those resolver classes typically having resolution methods that pass the GraphQL args down to operations, which then resolve however they need to. The operations themselves are tested in isolation and also with GraphQL request specs. Seems to work for us!

@radar radar marked this pull request as ready for review June 13, 2023 21:56
@rmosolgo rmosolgo added this to the 2.1.8 milestone Dec 18, 2023
@rmosolgo
Copy link
Owner

Hey, thanks for this contribution and sorry it took me so long to get it merged!

@rmosolgo rmosolgo merged commit 54608fd into rmosolgo:master Dec 18, 2023
@radar
Copy link
Contributor Author

radar commented Dec 19, 2023

Thank you so much for continuing to maintain this great gem! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants