Last edits from tech review

Author: lorensr

README.md

@@ -1,14 +1,18 @@
-# The GraphQL Guide
-
 This repo contains the text of The GraphQL Guide. 
 
 ## Supporting 
 
 If you'd like to read the Guide, and if you can afford to purchase it or if your company reimburses you for educational materials (most do 👍), we would value your support: [https://graphql.guide](https://graphql.guide).
 
+## Contributors
+
+[/GraphQLGuide/book/graphs/contributors](https://github.com/GraphQLGuide/book/graphs/contributors)
+
+Thank you to everyone who has contributed 😃🙌
+
 ## Contributing
 
-We welcome issues and PRs. For large changes, we recommend opening an issue first to get feedback before putting in the work of a PR. Minor things like typo fixes or suggested rewordings can go directly to PRs and will usually get a quick response.
+We welcome issues and PRs! For large changes, we recommend opening an issue first to get feedback before putting in the work of a PR. Minor things like typo fixes or suggested rewordings can go directly to PRs and will usually get a quick response 😊
 
 ### Setup
 
@@ -18,4 +22,8 @@ If you're working on gitbook-related issues or want to see how your PR will be f
 npm i -g gitbook
 gitbook install
 mkdir out/
-```
+```
+
+---
+
+[Changelog](https://github.com/GraphQLGuide/book/releases) (we use Github releases)

text/1.md

@@ -624,7 +624,7 @@ Thus far we’ve been retrieving data in a way that is stylistically similar to
 
 The client should be in control of requesting the data they want from the server. Ideally, this should be done in a single HTTP request. With REST, we can either make multiple HTTP requests to get the different types of data we need for a page, or we can design a custom REST endpoint that returns everything all at once. GraphQL employs a different strategy: a GraphQL endpoint can return many types and execute many queries, not just one. This gives the caller the power of being able to fetch any and all data needed in a single request.
 
-If we want to request multiple types of data with a basic REST API—one in which each endpoint deals with a single type—it might look something like this:
+If we want to request multiple types of data with a basic REST API—one in which each endpoint deals with a single type—our client code might look something like this:
 
 ```js
 const getUserWithGroup = user =>
@@ -643,7 +643,7 @@ fetch('http://localhost:3000/users')
   })
 ```
 
-First we request the users from the server, and once they’ve been returned, we request each user’s group. Once all the groups are returned, we have an array of full user objects to use. Here is the corresponding GraphQL:
+First we request the users from the server, and once they’ve been returned, we request each user’s group. Once all the groups are returned, we have an array of full user objects to use. Here is the equivalent code using our GraphQL API:
 
 ```js
 import { request } from 'graphql-request'
@@ -751,10 +751,10 @@ In this case, we’re requesting three query fields simultaneously (getting a li
 
 In summary, the advantages of using GraphQL for fetching multiple data types are:
 
-- The client retains control over its data requirements. Instead of the REST endpoint dictating the queries being run and the data returned, the client can specify the queries and the desired data and get it all back in a single request.
-- The server doesn’t have to attempt to permute all of the possible desired endpoints. This helps reduce the cost and surface area for the API. We don’t have to know about all the use cases or platforms that the data will eventually appear in, so the implementation becomes much simpler and easier to maintain.
-- It reduces the number of distinct requests for data, and thus the burden on both the client and the server. If we were to request three different pieces of data from a REST API, it could potentially require three different endpoints and three distinct HTTP requests. With GraphQL, we’re guaranteed to have a single request and the same unchanged implementation.
-- It reduces the latency in the overall request by allowing most of the data loading to be done on the server rather than the client (which has to wait for the current HTTP request to complete before initiating any other requests that depend on the current request’s response).
+- **The client retains control over its data requirements:** Instead of the REST endpoint dictating the queries being run and the data returned, the client can specify the queries and the desired data and get it all back in a single request.
+- **Simpler server:** The server doesn’t have to attempt to permute all of the possible desired endpoints. This helps reduce the cost and surface area for the API. We don’t have to know about all the use cases or platforms that the data will eventually appear in, so the implementation becomes much simpler and easier to maintain.
+- **Fewer requests:** It reduces the number of distinct requests for data, and thus the burden on both the client and the server. If we were to request three different pieces of data from a REST API, it could potentially require three different endpoints and three distinct HTTP requests. With GraphQL, we’re guaranteed to have a single request and the same unchanged implementation.
+- **Faster:** It reduces the latency in the overall request by allowing most of the data loading to be done on the server rather than the client (which has to wait for the current HTTP request to complete before initiating any other requests that depend on the current request’s response).
 
 # Security & error handling
 

text/11.md

@@ -2,30 +2,30 @@
 
 Chapter contents:
 
-* [Setting up node](11.md#setting-up-node)
-* [Writing good schemas](11.md#writing-good-schemas)
-* [Writing resolvers](11.md#writing-resolvers)
-* [Structuring the server](11.md#structuring-the-server)
-  * [Schema](11.md#schema-server)
-  * [Models & connectors](11.md#models-&-connectors)
-* [Subscriptions](11.md#subscriptions)
-* [Connecting data sources](11.md#connecting-data-sources)
-  * [SQL](11.md#sql)
-  * [MongoDB](11.md#mongodb)
-  * [REST APIs](11.md#rest-apis)
-  * [Prisma](11.md#prisma)
-  * [Redis](11.md#redis)
-  * [Elasticsearch](11.md#elasticsearch)
-  * [RethinkDB](11.md#rethinkdb)
-* [Security](11.md#security)
-  * [Authentication](11.md#authentication-server)
-  * [Authorization](11.md#authorization)
-  * [Denial of service](11.md#denial-of-service)
-* [Extended topics](11.md#extended-topics)
-  * [Caching](11.md#caching-server)
-  * [Batching](11.md#batching)
-  * [Prepared queries](11.md#prepared-queries)
-  * [Testing](11.md#testing)
+* Setting up node
+* Writing good schemas
+* Writing resolvers
+* Structuring the server
+  * Schema
+  * Models & connectors
+* Subscriptions
+* Connecting data sources
+  * SQL
+  * MongoDB
+  * REST APIs
+  * Prisma
+  * Redis
+  * Elasticsearch
+  * RethinkDB
+* Security
+  * Authentication
+  * Authorization
+  * Denial of service
+* Extended topics
+  * Caching
+  * Batching
+  * Prepared queries
+  * Testing
 
 ---
 

text/5.md

@@ -60,7 +60,7 @@ requests, including HTTP requests):
 $ curl -X POST \
 -H "Content-Type: application/json" \
 -d '{"query": "{ githubStars }"}' \
-https://graphql.guide/graphql
+https://api.graphql.guide/graphql
 ```
 
 * `-X` specifies which HTTP method to use—in this case POST
@@ -175,7 +175,7 @@ of constructing the HTTP POST request and parsing the response. For instance, th
 
 ## Typing
 
-When we’re working in typed languages, we have to write our own objects types and models, and when we get JSON from a REST API, we have to convert the data into our types. With GraphQL, we know the types for everything because they’re in the schema. Which means that our client libraries can provide us with type definitions or generate typed model code for us. For instance, [`apollo-codegen`](https://github.com/apollographql/apollo-codegen) generates type definitions for Typescript, Flow, and Scala, [Apollo iOS](https://www.apollographql.com/docs/ios/) returns query-specific Swift types, and [Apollo-Android](https://github.com/apollographql/apollo-android) generates types Java models based on our queries and schema.
+When we’re working in typed languages, we have to write our own object types and models, and when we get JSON from a REST API, we have to convert the data into our types. With GraphQL, we know the types for everything because they’re in the schema. Which means that our client libraries can provide us with type definitions or generate typed model code for us. For instance, [`apollo-codegen`](https://github.com/apollographql/apollo-codegen) generates type definitions for Typescript, Flow, and Scala, [Apollo iOS](https://www.apollographql.com/docs/ios/) returns query-specific Swift types, and [Apollo-Android](https://github.com/apollographql/apollo-android) generates typed Java models based on our queries and schema.
 
 A combination of having a schema and query documents also allow for some great code editor features, such as autocomplete, go to definition, and schema validation. (See for example the [VS Code plugin](https://github.com/apollographql/vscode-graphql) and [IntelliJ/WebStorm plugin](https://github.com/jimkyndemeyer/js-graphql-intellij-plugin).)
 

text/6.md

@@ -128,11 +128,11 @@ meteor
 
 [Meteor](https://www.meteor.com) is similar to Next in that it is not only the
 build tool but also the production server. Unlike CRA and Next, it does not use
-Webpack—it has its own build system that is blissfully
+Webpack—it has its own advanced build system that is blissfully
 configuration-free. It does not have built-in SSR like Next does, but it does
 have dynamic imports, and all dynamically imported modules are fetched quickly
-over a WebSocket and cached on the client (in
-[IndexedDB](https://en.wikipedia.org/wiki/Indexed_Database_API)).
+over a WebSocket and [cached on the client](https://blog.meteor.com/announcing-meteor-1-5-b82be66571bb) (in
+[IndexedDB](https://en.wikipedia.org/wiki/Indexed_Database_API)). It also does [differential bundling](https://blog.meteor.com/meteor-1-7-and-the-evergreen-dream-a8c1270b0901), further reducing bundle size for modern browsers.
 
 ## App structure
 
@@ -471,7 +471,7 @@ And we have a working GraphQL-backed app!
 
 `react-apollo` provides two APIs for making queries—the `<Query>` render prop API, and the HOC ([higher-order component](https://reactjs.org/docs/higher-order-components.html)) API. Which we use is mostly a matter of preference—the one thing the render prop API can do that the HOC API can’t is use a dynamic query. The aesthetic differences are whether we’re providing querying options and child component props in JSX (render prop) or JS objects (HOC), and whether we combine multiple queries by nesting JSX or composing HOCs. Since we’ll be writing components that use multiple queries and mutations, and we have limited horizontal width in our ebook readers, we’ll avoid highly nested JSX by mostly using HOCs. Note that it’s easy to translate between the two APIs, since they have the same props and provide us with the same information. So when we learn one API, we learn both. 
 
-Here’s the same component using `react-apollo`’s [`graphql()`](https://www.apollographql.com/docs/react/api/react-apollo.html#graphql) HOC API:
+Here’s the same component using `react-apollo`’s [`graphql()`](https://www.apollographql.com/docs/react/api/react- apollo.html#graphql) HOC API:
 
 ```js
 import { graphql } from 'react-apollo'
@@ -3063,12 +3063,12 @@ const USER_QUERY = gql`
   }
 ```
 
-Since we’re just counting the length, we don’t need any many `Review` fields—just the `id`. Now we need to pass the user object down the component tree—first to `<Book>`:
+Since we’re just counting the length, we don’t need many `Review` fields—just the `id`. Now we need to pass the user object down the component tree—first to `<Book>`:
 
 [`src/components/App.js`](https://github.com/GraphQLGuide/guide/compare/10_0.0.3...11_0.0.3)
 
 ```js          
-          <Route render={() => <Book user={this.props.user} />} />
+<Route render={() => <Book user={this.props.user} />} />
 ```
 
 And then to `<Reviews>`:
@@ -3133,6 +3133,7 @@ import remove from 'lodash/remove'
 const READ_USER_FAVORITES = gql`
   query ReadUserFavorites {
     currentUser {
+      id
       favoriteReviews {
         id
       }
@@ -4214,7 +4215,7 @@ Review.propTypes = {
 }
 ```
 
-![Hidden review icons](/imp/hidden-review-icons.png)
+![Hidden review icons](/img/hidden-review-icons.png)
 
 ## Editing reviews
 
@@ -4901,11 +4902,17 @@ const withReviews = graphql(REVIEWS_QUERY, {
     reviews,
     networkStatus,
     loadMoreReviews: () => {
-      const lastId = reviews && reviews[reviews.length - 1].id
+      if (!reviews) {
+        return
+      }
+
+      const lastId = reviews[reviews.length - 1].id
       return fetchMore({
         variables: { after: lastId },
 ```
 
+It’s possible that our scroll handler (which calls `loadMoreReviews`) will fire before the results from the initial reviews query has completed, in which case `reviews` will be `undefined`, and we do nothing.
+
 We also have to remove `skip` from `withAddReview` and `withDeleteMutation`, and update the query:
 
 [`src/graphql/Review.js`](https://github.com/GraphQLGuide/guide/compare/17_0.0.3...18_0.0.3)
@@ -5041,9 +5048,8 @@ The tricky part here is that we don’t know if the list of reviews with `orderB
 
 ---
 
-That’s all we have for you for now! We’re currently working on more advanced React content and the server chapter. Please drop us a line if you have any suggestions for us 😊:
-
-<authors@graphql.guide>
+That’s all we have for you for now! We’re currently working on more advanced React content and the server chapter. Please drop us a line if you have any suggestions for us 😊.
 
-[GitHub issues: book text](https://github.com/GraphQLGuide/book/issues)
-[GitHub issues: code](https://github.com/GraphQLGuide/guide/issues)
+- <authors@graphql.guide>
+- [GitHub issues: book text](https://github.com/GraphQLGuide/book/issues)
+- [GitHub issues: code](https://github.com/GraphQLGuide/guide/issues)

text/8.md

@@ -1,3 +1,3 @@
 # Chapter 8: React Native
 
-We haven't gotten to this chapter yet, but most things from the [React chapter](6.md) apply to React Native. For now, here's a great [small example](https://www.apollographql.com/docs/react/recipes/simple-example.html), and a [paid course](https://www.leveluptutorials.com/tutorials/level-2-react-native-with-graphql).
+We haven't gotten to this chapter yet, but most things from the [React chapter](6.md) apply to React Native. For now, here's a great [small example](https://www.apollographql.com/docs/react/recipes/simple-example.html), and a [paid course](https://www.leveluptutorials.com/tutorials/level-2-react-native-with-graphql?ref=guide).

text/README.md

@@ -1,5 +1,16 @@
 # Introduction
 
+* [Who is this book for?](README.md#who-is-this-book-for)
+* [Background](README.md#background)
+* [The book](README.md#the-book)
+* [The code](README.md#the-code)
+  * [Git](README.md#git)
+  * [Formatting](README.md#formatting)
+* [Resources](README.md#resources)
+* [Version](README.md#version)
+
+---
+
 # Who is this book for?
 
 This book is for most programmers. If you write software that fetches data from a server, or you write server code that provides data to others, this book is for you. It’s particularly relevant to frontend and backend web and mobile developers. If you don’t know modern JavaScript, we recommend [learning that first](bg.md#javascript), but it’s not necessary. For example, if you only know Ruby, you can likely follow the JavaScript server code in Chapter 11 well enough to learn the important concepts of a GraphQL server, most of which will apply to using the `graphql` gem in your Ruby server code.
@@ -62,9 +73,9 @@ If you’re reading this in epub or mobi format on your phone, turning sideways
 
 ## Git
 
-In Chapters 6–11, you’ll learn through writing an app, step-by-step. Each chapter has its own repository. Each step has a branch in that repo, for example branch `0` for the starter template, branch `1` for the code you write in the first step, etc. These branches contain the most up-to-date version of the code (and are updated through rebasing and force pushing). Snapshots of the steps are taken with tags for every release of the ebook. For instance, in the first version of the book (`the-graphql-guide-r1.pdf`, or r1), the React chapter code is at version `0.1.0`, so the code excerpts correspond exactly with tags `0_0.1.0` for step 0, `1_0.1.0` for step 1, etc. In the second revision of the book (`the-graphql-guide-r2.pdf`), if the code hasn’t changed, the tags will stay the same. In the third revision, if there are small changes to the code, the tags will be in the form `[step number]_0.1.1`.
+In Chapters 6–11, you’ll learn through writing an app, step by step. Each chapter has its own repository. Each step has a branch in that repo, for example branch `0` is the starter template, branch `1` has the code you write in step 1, etc. The branches we link to in the text also have a version number, and have the format: `[step]_[version]`. When this version of the Guide was published, the version of the Chapter 6 code was `0.1.0`, so step 1 links to branch `1_0.1.0`.
 
-So for example, if you’re on r1 (which is on `v0.1.0` of the code), and you skip the beginning of Chapter 6 and go straight to the [Listing reviews](6.md#listing-reviews) section, it says to start with step 9 (`9_0.1.0`). So we can look at the app in that state with these terminal commands:
+If you skip the beginning of Chapter 6 and go straight to the [Listing reviews](6.md#listing-reviews) section, it says to start with step 9 (`9_0.1.0`). So we can look at the app in that state with these terminal commands:
 
 ```sh
 git clone [email protected]:GraphQLGuide/guide.git
@@ -76,7 +87,7 @@ npm start
 
 > Check out the [git](bg.md#git) and [npm](bg.md#npm) background sections if you’re unfamiliar with these commands.
 
-If we get stuck, we can look at the difference between step 9 and step 10 with GitHub’s compare feature:
+If we get stuck, we can look at the diff between step 9 and step 10 with GitHub’s compare feature:
 
 `github.com/[repository]/compare/[tag 1]...[tag 2]`
 
@@ -122,14 +133,18 @@ Another important resource is the docs! Here they are for each library:
 
 # Version
 
-Book version `0.1.0`
+Book version: [`r1`](https://github.com/GraphQLGuide/book/releases)
+
+Published June 11, 2018
 
-Published May 7, 2018
+As we write more of the book, we’ll send you new versions of it (using the email address on the GitHub account you connected when you purchased the book at [graphql.guide](https://graphql.guide)).
+
+## Chapter 6 
+
+Code version: [`0.1.0`](https://github.com/GraphQLGuide/guide/blob/master/CHANGELOG.md)
 
 ```
-graphql @ 0.13
-react-apollo @ 2.1
-react @ 16.3
+react-apollo 2.1
+graphql 0.13
+react 16.3
 ```
-
-As we write more of the book, we’ll send you new versions of it (using the email address of the GitHub account you connected when you purchased the book at [graphql.guide](https://graphql.guide)).