Alexkrolick patch 1

content/docs/context.md

@@ -45,9 +45,9 @@ Using context, we can avoid passing props through intermediate elements:
 const {Provider, Consumer} = React.createContext(defaultValue);
 ```
 
-Creates a `{ Provider, Consumer }` pair.
+Creates a `{ Provider, Consumer }` pair. When React renders a context `Consumer`, it will read the current context value from the closest matching `Provider` above it in the tree.
 
-Optionally accepts a default value to be passed to Consumers without a Provider ancestor.
+The `defaultValue` argument is the context value React uses if you render a `Consumer` without a matching `Provider` above it in the tree. For example, this is helpful for testing components in isolation without wrapping them.
 
 ### `Provider`
 

content/docs/thinking-in-react.md

@@ -46,7 +46,7 @@ You'll see here that we have five components in our simple app. We've italicized
   1. **`FilterableProductTable` (orange):** contains the entirety of the example
   2. **`SearchBar` (blue):** receives all *user input*
   3. **`ProductTable` (green):** displays and filters the *data collection* based on *user input*
-  4. **`ProductCategoryRow` (turquoise):** displays a heading for each *category*
+  4. **`ProductCategoryRow` (cyan):** displays a heading for each *category*
   5. **`ProductRow` (red):** displays a row for each *product*
 
 If you look at `ProductTable`, you'll see that the table header (containing the "Name" and "Price" labels) isn't its own component. This is a matter of preference, and there's an argument to be made either way. For this example, we left it as part of `ProductTable` because it is part of rendering the *data collection* which is `ProductTable`'s responsibility. However, if this header grows to be complex (i.e. if we were to add affordances for sorting), it would certainly make sense to make this its own `ProductTableHeader` component.