Merge pull request #32 from stevenharman/patch-1

Fix typo

guides/concepts/backends-and-models.md

@@ -86,7 +86,7 @@ class EmployeeResource < ApplicationResource
     scope[:sort] = { name: direction }
   end
 
-  # 'scope' here is out hash
+  # 'scope' here is our hash
   # We pass it to Backend.query, and return Models
   def resolve(scope)
     results = Backend.query(scope)
@@ -96,7 +96,7 @@ end
 {% endhighlight %}
 
 As you see above, a **scope** can be anything from an
-`ActiveRecord::Relation` to a plain ruby hash. We want to adjust
+`ActiveRecord::Relation` to a plain Ruby Hash. We want to adjust
 *something* based on the request parameters and pass it to our backend.
 From the raw backend results, we can instantiate Models.
 
@@ -124,7 +124,7 @@ From the [ActiveRecord Guides](https://guides.rubyonrails.org/active_record_basi
 In other words, ActiveRecord is **combines** a Backend and Model.
 Opinions on this [vary](https://blog.lelonek.me/why-is-your-rails-application-still-coupled-to-activerecord-efe34d657c91),
 but Graphiti supports either approach: we can separate data and business layers, or
-combine them. See the ActiveRecord doppleganger of the above at our
+combine them. See the ActiveRecord doppelgänger of the above at our
 [Resource cheatsheet]({{site.github.url}}/cheatsheet).
 
 ### 1.2 Model Requirements
@@ -148,7 +148,7 @@ attribute :name, :string do
 end
 {% endhighlight %}
 
-If your Model does not respond to an attribute name, either pass a block to `attribute` or
+If your Model does not respond to `#name`, either pass a block to `attribute` or
 look into [aliasing](https://blog.bigbinary.com/2012/01/08/alias-vs-alias-method.html).
 
 #### 1.2.1 Validations
@@ -192,7 +192,7 @@ class Employee
 end
 {% endhighlight %}
 
-This is a common ruby example. `attr_accessor` defines getters and
+This is a common Ruby example. `attr_accessor` defines getters and
 setters for our properties, and we assign those properties in the
 constructor:
 

guides/concepts/endpoints.md

@@ -47,7 +47,7 @@ And Resources connect to other Resources. Our graph of data is defined
 Endpoints expose this graph to the world. We might choose to have a `/employees`
 endpoint that can eager load comments (`?include=comments`), but never expose
 `/comments` directly. Or, we could do the opposite: expose lazy-loading `/comments`,
-but disallow eager loading from `/employees.` We can add caching rules,
+but disallow eager loading from `/employees`. We can add caching rules,
 or add an `/exemplary_employees` endpoint with special query overrides.
 
 Finally, Endpoints are in charge of the [HTTP specification](https://tools.ietf.org/html/rfc2616):
@@ -131,7 +131,7 @@ filters, sorts, etc - while only returning "Top Posts".
 ### Sideload Allowlist
 
 Resources define relationships to other resources. But we may not want
-all those relationships exposed at a given endpoint.
+all of those relationships exposed at a given endpoint.
 
 Let's say we've defined relationships:
 

guides/concepts/links.md

@@ -35,7 +35,7 @@ might **eager load** the data like so:
 
 This fetches all the data in a single request. But after some UI
 testing, we decide to add a "show comments" button. This way our
-page can load quicker - it only needs to load the Post
+page can load more quickly - it only needs to load the Post
 initially, and loading Top Comments can be deferred. We
 want to **lazy load** the relationship.
 
@@ -45,7 +45,7 @@ How would we do this? We *could* bake this logic into our next request:
 
 But this requires the client to have knowledge of what a "Top Comment"
 is. If this logic ever changed, we'd have to update every client - our
-desktop app, mobile apps, reports, etc. Not to mention, third parties who
+desktop app, mobile apps, reports, etc… Not to mention, third parties who
 just want to display Top Comments are required to have this knowledge
 and update their implementations as well.
 

guides/concepts/resources.md

@@ -172,7 +172,7 @@ The built-in Types are:
 * `hash`
 * `array`
 
-All but the last 3 have Array dopplegangers: `array_of_integers`,
+All but the last 3 have Array doppelgängers: `array_of_integers`,
 `array_of_dates`, etc.
 
 ##### 2.5 Custom Types
@@ -508,7 +508,7 @@ multiple values. These filters will be `single: true` by default.
 ##### 3.5.3 Hash Filter
 
 Filters with type `hash` will automatically parse JSON when passed in a
-url query string:
+URL query string:
 
 {% highlight ruby %}
 # GET /employees?filter[metadata]={ "foo": 100 }
@@ -786,7 +786,7 @@ PostResource.all(includes: 'comments')
 # Under the hood:
 # CommentResource.all(filter: { post_id: array_of_post_ids })
 
-CommentResource.all(inclues: 'post')
+CommentResource.all(includes: 'post')
 # Under the hood:
 # PostResource.all(filter: { id: array_of_comment_ids })
 {% endhighlight %}
@@ -1136,7 +1136,7 @@ for further querying.
 
 ##### 5.6 polymorphic_has_many
 
-Continuing from the proir section, the corresponding association of a
+Continuing from the prior section, the corresponding association of a
 `polymorphic_belongs_to` is a `polymorphic_has_many`:
 
 {% highlight ruby %}
@@ -1280,7 +1280,7 @@ end
 ### 7.2 Sideposting
 
 The act of persisting multiple Resources in a single request is called
-**Sideposting**. The payload mirrors the side**loading** payload for
+**Sideposting**. The payload mirrors the **sideloading** payload for
 read operations, with minor additions.
 
 Let's create a Post and associate it to an existing Blog in a single
@@ -1354,7 +1354,7 @@ To accomodate this, send an ephemeral `temp-id` (any UUID):
 This random UUID:
 
 * Connects relevant sections of the payload.
-* Rells clients how to associate their in-memory objects with the ids returned from the server.
+* Tells clients how to associate their in-memory objects with the ids returned from the server.
 
 #### 7.2.2 Expanded Example
 

guides/concepts/testing.md

@@ -54,7 +54,9 @@ Test first.
 
 Wait, hear me out!
 
-[Even if you're not a fan of TDD](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html), Graphiti *integration* tests are simply the easiest, most pleasant way to develop. In fact, most Graphiti development can happen without even opening a browser...and as a side effect, you get a reliable test suite.
+[Even if you're not a fan of TDD](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html), Graphiti *integration* tests are simply the easiest, most pleasant way to develop.
+In fact, most Graphiti development can happen without even opening a browser.
+And as a side effect, you get a reliable test suite.
 
 Let's say we want to filter Employees by `title`, which comes from
 the `positions` table. Start with a spec:
@@ -108,21 +110,21 @@ There are two types of Graphiti tests: **API tests** and **Resource
 tests**.
 
 This is because the same Resource logic can be re-used at multiple
-endpoints. PostResource can be referenced at `/posts` and `/top_posts`
+endpoints. PostResource can be referenced at `/posts`, `/top_posts`,
 and `/admin/posts`, but we shouldn't have to test the same filtering and
-sorting logic over and over. Querying, Persistence and Serialization are
+sorting logic over and over. Querying, persistence, and serialization are
 all Resource responsibilities, tested in Resource tests.
 
 We still want API tests, though, to test everything outside of the
-Resource: routing, middleware, cache rules, response codes, etc.
+Resource: routing, middleware, cache rules, response codes, etc…
 
 Typically, you'll write the API test **once** and not have to touch it
 again.
 
 ### 1.2 Factories
 
 > Note: Factories are not **required**, but they are considered a best
-> practice used by the Graphiti test generator. Read Thoughtbot's
+> practice used by the Graphiti test generator. Read thoughtbot's
 > [Why Factories?](https://robots.thoughtbot.com/why-factories) for more
 > information.
 
@@ -213,7 +215,7 @@ expect(sideload.body).to eq('body')
 {% endhighlight %}
 
 The `sideload` method accepts the *name of the relationship*. It returns
-a normal `jsonapi_data` Node containing the `included` data.
+a normal `jsonapi_data` `GraphitiSpecHelpers::Node` containing the `include`-ed data.
 
 #### 2.3 Accessing Links
 
@@ -228,7 +230,7 @@ link URL.
 
 ### 2.2 `#json`
 
-To see the raw JSON response, just type `json`.
+To see the raw JSON response, use `json`.
 
 ### 2.3 `#datetime`
 
@@ -302,8 +304,7 @@ end
 
 ### 2.6 API Test Helpers
 
-When executing an API test request, always use the `jsonapi_`
-dopplegangers:
+When executing an API test request, always use the `jsonapi_` doppelgänger:
 
 * `jsonapi_get(url, params:)` instead of `get`
 * `jsonapi_post(url, payload)` instead of `post`
@@ -593,9 +594,8 @@ end
 
 You have 3 options here:
 
-* Turn off this validation in test mode. Add `config.active_record.belongs_to_required_by_default = true` to `config/environments/test.rb`.
-* Turn off the validation for this specific relationship: `belongs_to
-:department) optional: true`
+* Turn off this validation in test mode. Add `config.active_record.belongs_to_required_by_default = false` to `config/environments/test.rb`.
+* Turn off the validation for this specific relationship: `belongs_to :department, optional: true`.
 * Associate as part of the request.
 
 We recommend the third option to preserve real-world end-to-end