Update upgrading docs to refactoring

This commit is contained in:
Aaron Carlino 2021-02-17 10:40:19 +13:00
parent 1be5f471de
commit d023f46137
2 changed files with 39 additions and 23 deletions

View File

@ -24,7 +24,7 @@ If you need the type name during normal execution of your app, e.g. to display i
on the cached typenames, which are persisted alongside your generated schema code.
```php
SchemaFactory::singleton()->get('default')->getTypeNameForClass($className);
SchemaBuilder::singleton()->read('default')->getTypeNameForClass($className);
```
## Persisting queries

View File

@ -53,7 +53,8 @@ registration of types, execution of scaffolding, running queries and middleware,
class has been broken up into separate concerns:
* `Schema` <- register your stuff here
* `QueryHandlerInterface` <- Handles GraphQL queries. You'll probably never have to touch it.
* `QueryHandlerInterface` <- Handles GraphQL queries, applies middlewares and context.
You'll probably never have to touch it.
### Upgrading
@ -72,7 +73,8 @@ SilverStripe\GraphQL\Manager:
SilverStripe\GraphQL\Schema\Schema:
schemas:
default:
src: app/_graphql # A directory of your choice
src:
- app/_graphql # A directory of your choice
```
Add the appropriate yaml files to the directory. For more information on this pattern, see
@ -142,7 +144,7 @@ and moved into a class.
### Upgrading
Move your resolvers into one or many `ResolverProvider` implementations, register them.
Move your resolvers into one or many classes, and register them.
**before**
```php
@ -156,15 +158,16 @@ class LatestPostResolver implements OperationResolver
```
**after**
**app/_graphql/config.yml**
```yaml
SilverStripe\Core\Injector\Injector:
SilverStripe\GraphQL\Schema\Registry\ResolverRegistry:
constructor:
myResolver: '%$MyProject\Resolvers\MyResolvers'
resolvers:
- MyProject\Resolvers\MyResolverA
- MyProject\Resolvers\MyResolverB
```
```php
class MyResolvers extends DefaultResolverProvider
class MyResolverA
{
public static function resolveLatestPost($object, array $args, $context, ResolveInfo $info)
{
@ -218,7 +221,7 @@ class MyProvider implements ScaffoldingProvider
SilverStripe\GraphQL\Schema\Schema:
schemas:
default:
builders:
execute:
- 'MyProject\MyProvider'
```
@ -304,14 +307,33 @@ Change the casing in your queries.
**before**
```graphql
query readPages {
edges {
nodes {
Title
ShowInMenus
}
}
}
```
**after**
```graphql
query readPages {
edges {
node {
title
showInMenus
}
}
}
```
### `edges` no longer required
We don't have [cursor-based pagination](https://graphql.org/learn/pagination/) in Silverstripe CMS, so
the use of `edges` is merely for convention. You can eliminate a layer here and just use `nodes`, but `edges`
still exists for backward compatibility.
```graphql
query readPages {
nodes {
@ -321,6 +343,7 @@ query readPages {
}
```
## DataObject type names are simpler
To avoid naming collisions, the 3.x release of the module used a pretty aggressive approach to ensuring
@ -398,10 +421,3 @@ Status:
CANCELLED: Cancelled
PENDING: Pending
```
## Middleware signature is more loosely typed
In the 3.x release, `QueryMiddleware` was a very specific implementation that took parameters that were unique
to queries. The middleware pattern is now more generic and accepts a loosely-typed `params` array that can consist
of anything -- more like an `event` parameter for an event handler. If you've defined custom middleware, you'll
need to update it. Check out the [adding middleware](extending/adding_middleware) section for more information.