nettofarah
Add support for inline and named fragments
Add support for inline fragments and named fragments, supporting queries such as:
fragment ChefFragment on chef {
name
recipes {
title
ingredients {
name, quantity
vendor {
name
}
}
}
}
query {
restaurant(id: 1) {
... on restaurant {
name
owner {
... ChefFragment
}
}
}
}
I had to pass a reference to the hash that contains the fragment definitions through the whole method chain, since it is only available from the context variable. I'd suggest we refactor a module and use an instance of a class to hold current state in order to avoid passing so many parameters on method calls. something like:
module GraphQL
module QueryResolver
def self.run(*args, &block)
Resolver.new(*args).call(&block)
end
class Resolver
attr_reader :model_class, :context, :return_type
def initialize(model_class, context, return_type)
# save values
end
def call
to_load = yield
# and so on...
end
end
end
If you like the idea I can perform the refactoring as well
That actually sounds really great, @khamusa. Let's try the refactoring idea :)
@nettofarah thanks for the comments! Take a look at the last ~two~ three commits.
Regarding the dig_deeper (now to_proceed), I'm not 100% satisfied either. I can think of alternatives for refactoring but they involve switching to a more OO style which I'd rather not do since this code runs for every field and creating more objects could potentially impact performance.
By the way, I don't know how you prefer to manage versions, but I also added these latest changes to the changelog, so that we don't forget what's to be added later. If you prefer I can remove it as well.
@nettofarah please hold this, i'm investigating an issue with relay pagination
hey @nettofarah I'm sorry I haven't been able to work on this anymore. The issue I found was actually this one: https://github.com/nettofarah/graphql-query-resolver/issues/9
I found out that the strategy we're using here was pretty much useless for relay connections.
I do think this PR is unrelated though..