bdelacretaz commented on a change in pull request #23:
URL:
https://github.com/apache/sling-org-apache-sling-graphql-core/pull/23#discussion_r633344677
##########
File path: src/test/resources/failing-fetcher-schema.txt
##########
@@ -15,13 +15,6 @@
# * specific language governing permissions and limitations
# * under the License.
-# This directive maps fields to our Sling data fetchers
Review comment:
We should leave tests where these directives are defined in the schema
as before, to make sure these old schemas continue to work. I think doing that
for the @fetcher and @resolver directives is sufficient as we didn't release
this module with the @connection implemented.
##########
File path: README.md
##########
@@ -87,24 +84,23 @@ schemas dynamically, taking request selectors into account.
Unless you have specific needs not covered by this mechanism, there's no need
to implement your
own `SchemaProvider` services.
-## SlingDataFetcher selection with Schema Directives
-
-The GraphQL schemas used by this module can be enhanced using
-[schema directives](http://spec.graphql.org/June2018/#sec-Language.Directives)
-(see also the [Apollo
docs](https://www.apollographql.com/docs/graphql-tools/schema-directives/) for
how those work)
-that select specific `SlingDataFetcher` services to return the appropriate
data.
-
-A default data fetcher is used for types and fields which have no such
directive.
+## SlingDataFetcher selection using the `@fetcher` directive
Review comment:
I would say "built-in @fetcher directive" and use this "built-in" term
for the other directives as well. And we can then add a short "built-in
directives" section which explains the concept.
##########
File path:
src/main/java/org/apache/sling/graphql/core/engine/DefaultQueryExecutor.java
##########
@@ -232,119 +211,6 @@ public ValidationResult validate(@NotNull String query,
@NotNull Map<String, Obj
}
}
- private RuntimeWiring buildWiring(TypeDefinitionRegistry typeRegistry,
Iterable<GraphQLScalarType> scalars, Resource r) {
Review comment:
The diffs for this file are quite large, I don't think they reflect the
actual changes - can you easily revisit to create more precise diffs?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
