Post ch 11 tech review

Author: lorensr

text/1.md

@@ -117,7 +117,7 @@ module.exports = { User }
 
 We connect to the database and implement a schema for the User that has two fields, `_id` (the default ID field for MongoDB) and `username`, and we turn that schema into a model that lets Mongoose know that users should be stored in the `users` collection (it takes the given model name `'User'` and lowercases and pluralizes).
 
-We’ll need to have some data in our database to start, so we’ll insert a couple of simple documents with string `_id` and `username` fields, looking something like this (in [Robo 3T](https://robomongo.org/), a desktop graphical interface for running MongoDB queries against a database):
+We’ll need to have some data in our database to start, so we’ll insert a couple of simple documents with string `_id` and `username` fields, looking something like this (in [MongoDB Compass](https://www.mongodb.com/products/compass), a desktop graphical interface for running MongoDB queries against a database):
 
 ![users collection in MongoDB](/img/mongo-users.jpg)
 *The two records stored in the “users” collection of the MongoDB database.*

text/11.md

@@ -99,6 +99,8 @@ We can think of the selection set as the left-hand side of a JSON document (with
 
 [fragments](http://graphql.org/learn/queries/#fragments)
 
+[inline fragments](http://graphql.org/learn/queries/#inline-fragments)
+
 # Variables
 
 [variables](http://graphql.org/learn/queries/#variables)

text/2.md

@@ -22,7 +22,7 @@ written these days follows the
 in which one computer is always providing a service (a **server**), and another
 computer is always requesting the service (a **client**, such as a web browser or mobile app). In a GraphQL client–server model, the client
 makes GraphQL requests, and the server provides the service of responding to
-those requests. We’ll code GraphQL clients in the next few chapters and GraphQL servers
+those requests. We’ll code GraphQL clients in the next few chapters and a GraphQL server
 in the [last](11.md).
 
 First we’ll make simple HTTP requests, which we can do from any computer. Most
@@ -38,7 +38,7 @@ libraries are [`Apollo iOS`](https://www.apollographql.com/docs/ios/),
 Native.
 
 For each type of client and the server, the app we’ll go through building is
-[graphql.guide](https://graphql.guide)—a web or mobile app for reading the
+[graphql.guide](https://graphql.guide/Preface)—a web or mobile app for reading the
 GraphQL Guide.
 
 # Anywhere: HTTP
@@ -53,7 +53,7 @@ request.
 ## cURL
 
 When we’re on the command line, we can use
-[cURL](https://en.wikipedia.org/wiki/CURL) ("See URL", a tool for making network
+[cURL](https://en.wikipedia.org/wiki/CURL) (“See URL”, a tool for making network
 requests, including HTTP requests):
 
 ```sh
@@ -171,7 +171,7 @@ languages. Here is some common functionality that the libraries might provide:
 - [Caching](#caching)
 - [DevTools](#devtools)
 
-The first is useful anywhere—whether it’s a script, service, or website that’s mostly static (only displays a small amount of dynamically fetched data). The second is useful when we’re working in a typed programming language. The last three are extremely helpful for building applications: whether we’re making a web app, a mobile app, or a desktop app, we usually need to fetch and display a number of different types of data from the server, and decide which to fetch and display based on user interactions. We also want to remember what we requested in the past, because oftentimes when we need to display it again, we don’t need to fetch it again. Doing all of this ourselves can get really complicated, but advanced client libraries like Apollo can take care of a lot of it for us.
+The first is useful anywhere—whether it’s a script, service, or website that’s mostly static (only displays a small amount of dynamically fetched data). The second is useful when we’re working in a typed programming language. The last three are extremely helpful for building applications: whether we’re making a web app, a mobile app, or a desktop app, we usually need to fetch and display a number of different types of data from the server, and decide which to fetch and display based on user interactions. We also want to remember what we requested in the past, because often when we need to display it again, we don’t need to fetch it again. Doing all of this ourselves can get really complicated, but advanced client libraries like Apollo can take care of a lot of it for us.
 
 ## Streamlined request function
 
@@ -262,11 +262,11 @@ Our query returns:
 
 And our library saves the response in a normalized cache. The key to each object
 in the cache is a string of the format `"[type]:[object id]"`, for instance
-"User:1" for a User object with an id of 1:
+`"User:1"` for a User object with an id of 1:
 
 ```js
 cache = {
-  "User:1" {
+  "User:1": {
     id: "1",
     firstName: "Loren",
     hasRead: [
@@ -275,12 +275,12 @@ cache = {
     ]
   },
   "Section:5_1": {
-    "id": "5_1",
-    "title": "Anywhere: HTTP"
+    id: "5_1",
+    title: "Anywhere: HTTP"
   },
   "Section:5_2": {
-    "id": "5_2",
-    "title": "Client Libraries"
+    id: "5_2",
+    title: "Client Libraries"
   }
 }
 ```
@@ -306,9 +306,9 @@ Which should return:
 }
 ```
 
-But we already know from our first query that "Client Libraries" is the title.
+But we already know from our first query that `"Client Libraries"` is the title.
 Our normalized caching library, instead of sending our second query to the
-server, can find the object with the "Section:5_2" key in the cache and
+server, can find the object with the `"Section:5_2"` key in the cache and
 immediately return it to us.
 
 Sometimes we want to re-request data from the server, because it may have
@@ -317,7 +317,7 @@ us to re-request, but we usually want to immediately display the cached data
 while we wait for the response to arrive. The time it takes to get a value from
 the cache and display it on the screen could be as little as 20ms, whereas
 common response times from GraphQL servers are on the order of hundreds of
-milliseconds or seconds, depending on the user’s network connection [#latency] and
+milliseconds or seconds, depending on the user’s network connection [latency](bg.md#latency) and
 how long the server takes to retrieve their data. Humans
 [perceive delays](https://developers.google.com/web/fundamentals/performance/rail)
 above 100ms, so UX best practice is to show something on the screen within 100ms
@@ -327,20 +327,19 @@ displaying a spinner—or display the cached version of the data.
 
 ## DevTools
 
-Some libraries have browser DevTools extensions for viewing information about an app’s GraphQL operations and the current state of the store. Apollo’s DevTools also has a built-in GraphiQL that uses the same network link as our app, so we don’t have to manually set authentication headers. We can even use it to query the store instead of the server!
+Some libraries have browser DevTools extensions for viewing information about an app’s GraphQL operations and the current state of the store. Apollo’s DevTools also has a built-in GraphiQL that uses the same network link as our app, so we don’t have to manually set authentication headers. We can even use it to query the store instead of the server by checking “Load from cache”:
 
 ![DevTools GraphiQL](img/devtools-graphiql.png)
 
-Using the "Load from cache" feature of the built-in GraphiQL
+Under the Queries tab, we see the current “Watched queries” (queries attached to our components) and what variables they were called with:
 
 ![DevTools Query](img/devtools-query.png)
 
-See the current "Watched Queries" (queries attached to our components) and what variables they were called with.
+Under the Mutations tab, we see a log of all past mutations and their variables:
 
 ![DevTools Mutation](img/devtools-ViewedMutation.png)
 
-See a log of all past mutations and their variables.
+Under the Cache tab, we see the current state of the store/cache. Normalized data objects (any objects for which the `id` was requested) are listed on the left and appear in expandable `<details>` nodes on the right:
 
 ![DevTools Cache](img/devtools-cache.png)
 
-See the current state of the store/cache. Normalized data objects (any objects for which the `id` was requested) are listed on the left and appear in expandable `<details>` nodes on the right.

text/5.md

@@ -60,18 +60,12 @@ Chapter contents:
 
 ---
 
-Background: [single-page application](bg.md#spa), [HTTP](bg.md#http), [Node](bg.md#node-&-npm-&-nvm), [git](bg.md#git), [JSON](bg.md#json), [JavaScript](bg#javascript)
+Background: [single-page application](bg.md#spa), [HTTP](bg.md#http), [Node](bg.md#node-&-npm-&-nvm), [git](bg.md#git), [JSON](bg.md#json), [JavaScript](bg#javascript), [React](bg.md#react)
 
 In this chapter, we’ll learn to use the [`react-apollo`](https://www.apollographql.com/docs/react/) library through building the Guide web app—the code behind the [https://graphql.guide](https://graphql.guide/Preface) site, where we can sign in, read the book, and write reviews. *[Beta note: the site isn’t yet complete, so you’ll see lorem ipsum in place of book content 😄.]* We’ll go through setup, simple queries, complex queries, auth, and mutations for creating, updating, and deleting. Then we’ll cover advanced topics like infinite scrolling, local state, SSR, working offline, and performance. Here’s what it will look like:
 
 ![Guide app](img/guide-app.png)
 
-React was released by Facebook in 2013, and it has since steadily increased in
-popularity, surpassing Angular in GitHub stars in 2016 to become the most
-popular Javascript view library. It continues to be developed by a team at
-Facebook, who have merged in contributions from over one thousand community
-members.
-
 # Setting up
 
 Section contents:
@@ -2529,7 +2523,7 @@ Section.propTypes = {
 
 We give `this.props.viewedSection()` the section id mutation variable. We put it in a timeout so that we have time to scroll down to the bottom of the section to see the count change (End key or Cmd-⬇️ on Mac). And we clear the timeout on unmount (because if we navigate away, for example to our profile, and our timeout still fires, it would call a mutation provided by a `<Mutation>` component that no longer existed, and React would throw an error).
 
-We also need to only trigger the mutation when the section changed. When the mutation result arrives and updates the Apollo store, `<Section>` is going to be given the updated `section` prop, so `componentDidUpdate()` will be called again. And if it always called `viewedSection()`, we’d be in an infinite loop. (Read: Author Loren was stuck in an infinite loop 😆.)
+We also need to only trigger the mutation when the section changed. When the mutation result arrives and updates the Apollo store, `<Section>` is going to be given the updated `section` prop, so `componentDidUpdate()` will be called again. And if it always called `viewedSection()`, we’d be in an infinite loop. (Read: author Loren was stuck in an infinite loop 😆.)
 
 ![Infinite prop-updating loop](/img/infinite-loop.gif)
 [*gif: Infinite prop-updating loop*](http://res.cloudinary.com/graphql/guide/infinite-loop.gif)
@@ -4300,13 +4294,21 @@ Section contents:
   * [Cursors](6.md#cursors)
     * [after](6.md#after)
     * [orderBy](6.md#orderby)
-* [Updating multiple queries]()
-* [Local state]()
-* [withUser]()
-* [Reviews subscription]()
-* [Batching]()
-* [Prefetching]()
-* [Persisting]()
+* [Updating multiple queries](6.md#updating-multiple-queries)
+* [Local state](6.md#local-state)
+  * [Direct writes](6.md#direct-writes)
+  * [Local mutations](6.md#local-mutations)
+* [REST](6.md#rest)
+* [Reviews subscriptions](6.md#reviews-subscriptions)
+  * [Subscription component](6.md#subscription-component)
+  * [Add new reviews](6.md#add-new-reviews)
+  * [Update on edit and delete](6.md#update-on-edit-and-delete)
+* [Prefetching](6.md#prefetching)
+  * [On mouseover](6.md#on-mouseover)
+  * [Cache redirects](6.md#cache-redirects)
+* [Batching](6.md#batching)
+* [Persisting](6.md#persisting)
+* [Multiple endpoints](6.md#multiple-endpoints)
 
 ## Paginating
 
@@ -5268,6 +5270,11 @@ Depending on what the query variables are (`orderBy`, `minStars`, and `minSenten
 
 ## Local state
 
+Section contents:
+
+* [Direct writes](6.md#direct-writes)
+* [Local mutations](6.md#local-mutations)
+
 In most of the apps we build, the majority of our *state* (the data that backs our UI) is *remote state*—it comes from a server and is saved in a database. But some of our state doesn’t come from the server and isn’t stored in a database—it originates locally on the client and stays there. This type of data is called our *local state*. One example of local state is a user setting that for whatever reason we didn’t want to send to the server to persist. Another example is data from a device API: if we were making a navigation app, we would want to display the device’s location and speed. A simple solution would be to put the state in a variable, for instance `window.gps`:
 
 ```js
@@ -6101,6 +6108,13 @@ To recap, we added `@rest` to our query, which made our REST link intercept the
 
 > If you’re jumping in here, `git checkout 21_0.2.0` (tag [21_0.2.0](https://github.com/GraphQLGuide/guide/tree/21_0.2.0), or compare [21...22](https://github.com/GraphQLGuide/guide/compare/21_0.2.0...22_0.2.0))
 
+Section contents:
+
+* [Subscription component](6.md#subscription-component)
+* [Add new reviews](6.md#add-new-reviews)
+* [Update on edit and delete](6.md#update-on-edit-and-delete)
+
+
 Early on in this chapter we set up our [first subscription](#subscriptions) for an updated GitHub star count. That was a very simple example—each event we received from the server contained a single integer:
 
 ```gql
@@ -6430,6 +6444,11 @@ For review updates, we replace the review in the list from the store (`prev`) wi
 
 Background: [browser performance](bg.md#browser-performance)
 
+Section contents:
+
+* [On mouseover](6.md#on-mouseover)
+* [Cache redirects](6.md#cache-redirects)
+
 Prefetching is fetching data from the server before we need it so that when we do need it, we already have it on the client and can use it right away. This is great for UX because the user doesn’t have to look at a loading screen waiting for data to load. It’s a common pattern—both [Gatsby](https://www.gatsbyjs.org/docs/gatsby-link/) and [Next.js](https://nextjs.org/docs/#prefetching-pages) prefetch entire web pages with their `<Link>` components.
 
 The most useful thing to prefetch in our app is the section content! We can prefetch just by making a query with the Apollo client:
@@ -7348,6 +7367,15 @@ We’re done! We can add more SpaceX data to different parts of our app by impor
 
 # Extended topics
 
+Section contents:
+
+* [Linting](6.md#linting)
+  * [Setting up linting](6.md#setting-up-linting)
+  * [Fixing linting errors](6.md#fixing-linting-errors)
+  * [Using linting](6.md#using-linting)
+* [Uploading files](6.md#uploading-files)
+* [Testing](6.md#testing)
+
 ## Linting
 
 > If you’re jumping in here, `git checkout 26_0.2.0` (tag [26_0.2.0](https://github.com/GraphQLGuide/guide/tree/26_0.2.0), or compare [26...27](https://github.com/GraphQLGuide/guide/compare/26_0.2.0...27_0.2.0))
@@ -7842,12 +7870,4 @@ Our server needs to support the [GraphQL multipart request spec](https://github.
 
 We’re holding off on writing this section until the hooks+suspense version of React Apollo comes out. For now, we recommend the built-in [`<MockedProvider>`](https://www.apollographql.com/docs/react/recipes/testing.html) for the easiest setup or [this approach](https://medium.freecodecamp.org/a-new-approach-to-mocking-graphql-data-1ef49de3d491) for the most succinct test code. 
 
-We also recommend using [Jest](https://jestjs.io/) and [`react-testing-library`](https://testing-library.com/react). If you’d like a video introduction to them, as well as testing in general, we recommend [this course](https://testingjavascript.com/).
-
----
-
-That’s all we have for now! We’re currently working on the server chapter. Please drop us a line if you have any suggestions for us 😊.
-
-- <authors@graphql.guide>
-- [GitHub issues: book text](https://github.com/GraphQLGuide/book/issues)
-- [GitHub issues: code](https://github.com/GraphQLGuide/guide/issues)
+We also recommend using [Jest](https://jestjs.io/) and [`react-testing-library`](https://testing-library.com/react). If you’d like a video introduction to them, as well as testing in general, we recommend [this course](https://testingjavascript.com/).

text/6.md

@@ -34,14 +34,19 @@ We have a [Background](bg.md) chapter that provides concise introductions to var
 Here’s a full list of the topics:
 
 * [JavaScript](bg.md#javascript)
+* [JavaScript classes](bg.md#javascript-classes)
 * [JSON](bg.md#json)
 * [Git](bg.md#git)
 * [Node & npm & nvm](bg.md#node-&-npm-&-nvm)
 * [HTTP](bg.md#http)
+* [Server](bg.md#server)
+* [MongoDB](bg.md#mongodb)
 * [SPA](bg.md#spa)
 * [SSR](bg.md#ssr)
+* [React](bg.md#react)
 * [Latency](bg.md#latency)
 * [Webhooks](bg.md#webhooks)  
+* [Testing](bg.md#testing)  
 * [Continuous integration](bg.md#continuous-integration)
 * [Authentication](bg.md#authentication)
   * [Tokens vs. sessions](bg.md#tokens-vs-sessions)
@@ -140,9 +145,9 @@ Another important resource is the docs! Here they are for each library:
 
 # Version
 
-Book version: `r3` ([changelog](https://github.com/GraphQLGuide/book/releases))
+Book version: `r4` ([changelog](https://github.com/GraphQLGuide/book/releases))
 
-Published April 10, 2019
+Published TODO September 13, 2019
 
 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 from [graphql.guide](https://graphql.guide)).
 
@@ -155,3 +160,11 @@ react-apollo 2.5
 graphql 0.14
 react 16.8
 ```
+
+## Chapter 11
+
+Code version: `0.1.0` ([changelog](https://github.com/GraphQLGuide/guide-api/blob/master/CHANGELOG.md))
+
+```
+apollo-server 2.6
+```