docs: a few more tweaks

Author: petrus-jvrensburg

docs/custom-scalars.md

@@ -37,22 +37,22 @@ gql_build|schema_builder:
     type_overrides:
       Date:
         name: DateTime
-        import: 'package:my_date_library/date_time.dart'
+        import: "package:my_date_library/date_time.dart"
 ```
 
 ### Configure Custom Serializer
 
-If our Dart type is not a Dart Data Type, we also need to [define a custom serializer](#create-a-custom-serializer) so that the generated classes can be correctly serialized & deserialized the data.
+If our Dart type is not a Dart Data Type, we also need to [define a custom serializer](#create-a-custom-serializer) so that the generated classes can correctly serialize & deserialize the data.
 
-Assuming we've created a [`DateSerializer`](#create-a-custom-serializer) for our custom `Date` scalar, we will need to include it in our `serializer_builder`.
+Assuming we've created a [`DateSerializer`](#create-a-custom-serializer) for our custom `Date` scalar, we will need to include it in our `serializer_builder`:
 
 ```yaml
 gql_build|serializer_builder:
   enabled: true
   options:
     schema: my_project|lib/graphql/schema.graphql
     custom_serializers:
-      - import: 'package:path/to/date_serializer.dart'
+      - import: "package:path/to/date_serializer.dart"
         name: DateSerializer
 ```
 
@@ -92,7 +92,7 @@ targets:
         options:
           schema: my_project|lib/schema.graphql
           custom_serializers:
-            - import: 'package:path/to/date_serializer.dart'
+            - import: "package:path/to/date_serializer.dart"
               name: DateSerializer
 
       ferry_generator|req_builder:
@@ -104,11 +104,11 @@ targets:
               name: DateTime
 ```
 
-## Create a Custom Serializer
+## Creating a Custom Serializer
 
-In order for us to instantiate our generated Dart Classes with data from our GraphQL server, we will need to create a custom `built_value` serializer for our custom `scalar` type.
+For Ferry to create instances of our generated Dart classes, with data from a GraphQL server, we'll need to create a custom `built_value` serializer to handle the custom `scalar` type.
 
-In this case, let's assume that our GraphQL server will return our `Date` scalar as an `int` timestamp.
+Let's assume that our GraphQL server returns our `Date` scalar as an `int` timestamp. Then, a custom serializer can look like this:
 
 ```dart
 import 'package:built_value/serializer.dart';
@@ -141,13 +141,13 @@ class DateSerializer implements PrimitiveSerializer<DateTime> {
 }
 ```
 
-And that's it! Now when we run our `pub run build_runner build` command, ferry's generators will automatically override our GraphQL `Date` scalar with the Dart `DateTime` type and use our `DateSerializer` to serialize & deserialize data.
+And that's it! Now when we run our `pub run build_runner build` command, Ferry's generators will automatically override our GraphQL `Date` scalar with the Dart `DateTime` type and use our `DateSerializer` to serialize & deserialize data.
 
 ### Using `StructuredSerializer`s
 
 We've implemented the above `DateSerializer` using the `PrimitiveSerializer` from `built_value`. However, if we were building a serializer for a non-primitive Dart type, we'd probably want to use the `StructuredSerializer` instead.
 
-Since `built_value` doesn't use standard Json by default, rather than implementing `StructuredSerializer` directly, we may prefer to extend the `JsonSerializer` from `gql_code_builder`. For example, here's a serializer for the `Operation` type from `gql_exec` that ferry's generaters use internally.
+Since `built_value` doesn't use standard Json by default, rather than implementing `StructuredSerializer` directly, we may prefer to extend the `JsonSerializer` from `gql_code_builder`. For example, here's a serializer for the `Operation` type from `gql_exec` that Ferry's generators use internally.
 
 ```dart
 import "package:built_value/serializer.dart";

docs/customization.md

@@ -41,7 +41,7 @@ class CacheTypedLink extends TypedLink {
 
 Not all links need to resolve the request directly. Some links simply modify the request or response stream by calling the `forward()` callback on the `request()` method. This defers resolution of the request to the next link in the chain.
 
-For example, ferry uses the following link to automatically add "___typename_" fields to each node of the GraphQL operation.
+For example, ferry uses the following link to automatically add "_\_\_typename_" fields to each node of the GraphQL operation.
 
 ```dart
 import 'dart:async';
@@ -81,7 +81,7 @@ class AddTypenameTypedLink extends TypedLink {
 
 TypedLinks can be chained together using the `TypedLink.from()` method.
 
-The following will create a link that adds "___typename_" fields to the request, then resolves the request from the Cache:
+The following will create a link that adds "_\_\_typename_" fields to the request, then resolves the request from the Cache:
 
 ```dart
 final myTypedLink = TypedLink.from([
@@ -96,8 +96,6 @@ You can then use this link to execute requests by listening to the Stream return
 myTypedLink.request(GMyQueryReq()).listen((data) => print(data));
 ```
 
-
-
 ### Ordering Your TypedLink Chains
 
 There are a few important guidelines that you should follow when chaining TypedLinks to ensure that your requests get executed correctly.
@@ -120,7 +118,7 @@ Instead, you can simply use the [underlying links that Client composes](https://
 The ferry Client is created by composing these core TypedLinks.
 
 - **Client**: The Ferry Client itself is a TypedLink, implemented by composing other core TypedLinks.
-- **AddTypenameTypedLink**: Adds "___typename_" to each node of the operation.
+- **AddTypenameTypedLink**: Adds "_\_\_typename_" to each node of the operation.
 - **CacheTypedLink**: A terminating link that fetches the operation from the Cache.
 - **FetchPolicyTypedLink**: A terminating link that resolves an operation from the Link or the Cache based on the request's `FetchPolicy`, possibly caching the response.
 - **GqlTypedLink**: A terminating link which defers execution to the provided [gql_link](https://pub.dev/packages/gql_link). Any errors received by the [gql_link](https://pub.dev/packages/gql_link) are included in the `OperationResponse.linkException`.

docs/fetch-policies.md

@@ -8,7 +8,7 @@ A request's `FetchPolicy` determines how it is resolved by Ferry, either from th
 For example, executing the following `reviewsReq` will bypass the cache and return results only from the network.
 
 ```dart
-final reviewsReq = GAllPokemonReq(
+final reviewsReq = GReviewsReq(
   (b) => b
     ..fetchPolicy = FetchPolicy.NetworkOnly
     ..vars.first = 10

docs/structuring-queries.md

@@ -120,7 +120,7 @@ A naive implementation of this (don't do this) might be to:
 
 However, this would result in a seperate network request (and subsequent database query) for each Pokemon in the list. Not very efficient.
 
-Istead, we can extract our `PokemonCard`'s data requirements into a Fragment:
+Instead, we can extract our `PokemonCard`'s data requirements into a Fragment:
 
 ```graphql
 fragment PokemonCardFragment on Pokemon {