Hey guys,
I've noticed that some of the gql examples are indented differently than the rest and I think that consistent indentation and formatting makes it easier to read and comprehend.
Let me know what you think, thanks.
In an effort to maintain consistency and semantically correct meaning,
this changes (only in documentation and internal Apollo Server tests) the
name of the first argument in resolver signatures to use `parent` rather
than `root`.
While `root` certainly makes sense when the resolver is belonging to the
root `Query` or `Mutation` type, once nested field resolvers begin getting
called, the more semantically correct term would seem to be `parent`.
Since `parent` still makes sense at the root level, and since resolvers
frequently get copied and pasted into more deeply-nested positions, putting
this pattern in place for apps which are just beginning might just help
someone more clearly understand the relationship in the future — without
incorrectly thinking that a nested resolver is accessing the root of the
graph, rather than the parent.
* Example code snippet does not work
for the context it needs to return a connection.context and not a {}.
* Include not about what connection contains
* Add client awareness reference api and some docs
* Reword and add default behavior to docs
* update clientReferenceId docs to be more explicit
* Update the generateClientInfo to use headers
These are docs to accompany the `apollo-server-testing` utils
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
TODO:
* [ ] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [ ] Make sure all of the significant new logic is covered by tests
* [ ] Rebase your changes on master so that they can be merged easily
* [ ] Make sure all tests and linter rules pass
<!--**Pull Request Labels**
While not necessary, you can help organize our pull requests by labeling this issue when you open it. To add a label automatically, simply [x] mark the appropriate box below:
- [ ] feature
- [ ] blocking
- [x] docs
To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
* Incorrect sample codes
```const { ApolloServer } = require('apollo-server');```
should be
```const { ApolloServer, gql } = require('apollo-server');```
The functions in `mocks` would be used when no resolver in `resolvers` is specified only when `mockEntireSchema: false`.
* Update mocking.md
Change the documentation to be correct, indicating that the mocks overwrite the resolvers
On version 3.1.1 there is an error ( `Error: Invalid schema passed` ) when wrapping the `linkTypeDefs` in `gql`. Passing the plain string the example works.
* remove formatParams
* remove formatParams from documentation
* check for valid query string after persisted query mapping
* fix sentence about different logging and label extensions as experimental
* mark graphql-extensions as more experimental
* Add a wider diversity of `gui` options
Although I know we want to remain less tied to the GraphQL Playground
GUI options, we definitely want to support a wider variety of options to
be passed in. This adds support for specifying partial options either
statically or dynamically for the gui, which can be extended to allow
for a wider array of guis than only GraphQL playground.
* Add boolean option and configuration for tabs
* move gui setting into ApolloServer Constructor
* document playground configuration in the constructor
* update playground types and fixed micro + koa integrations
* change gui to playground
* docs: change gui to playground
* fix logic for playground creation
