Update docs (#1893)

docs/walkthroughs/saving-and-loading-html-content.md

@@ -35,7 +35,7 @@ Now... we need to add the [`Html`](../reference/serializers/html.md) serializer.
 * A `quote` block for quotes...
 * And `bold`, `italic` and `underline` formatting.
 
-By default, the `Html` serializer, knows nothing about our schema just like Slate itself. To fix this, we need to pass it a set of `rules`. Each rule defines how to serialize and deserialize a Slate object.
+By default, the `Html` serializer knows nothing about our schema, just like Slate itself. To fix this, we need to pass it a set of `rules`. Each rule defines how to serialize and deserialize a Slate object.
 
 To start, let's create a new rule with a `deserialize` function for paragraph blocks.
 
@@ -287,11 +287,11 @@ class App extends React.Component {
     const { mark, attributes } = props
     switch (mark.type) {
       case 'bold':
-        return <strong {...{ attributes }}>{props.children}</strong>
+        return <strong {...attributes}>{props.children}</strong>
       case 'italic':
-        return <em {...{ attributes }}>{props.children}</em>
+        return <em {...attributes}>{props.children}</em>
       case 'underline':
-        return <u {...{ attributes }}>{props.children}</u>
+        return <u {...attributes}>{props.children}</u>
     }
   }
 }

docs/walkthroughs/saving-to-a-database.md

@@ -147,7 +147,7 @@ class App extends React.Component {
 
 Now you should be able to save changes across refreshes!
 
-However, if you inspect the change handler, you'll notice that it's actually saving the Local Storage value on _every_ change to the editor, even when only the selection changes! This is because `onChange` is called for _every_ change. For Local Storage this doesn't really matter, but if you're saving things to a database via HTTP request this would result in a lot of unnecessary requests. You can fix this by checking against the previous `document` value.
+However, if you inspect the change handler, you'll notice that it's actually saving the Local Storage value on _every_ change to the editor, even when only the selection changes! This is because `onChange` is called for _every_ change. For Local Storage, this doesn't really matter, but if you're saving things to a database via HTTP request, this would result in a lot of unnecessary requests. You can fix this by checking against the previous `document` value.
 
 ```js
 const existingValue = JSON.parse(localStorage.getItem('content'))

docs/walkthroughs/using-plugins.md

@@ -4,11 +4,11 @@
 
 # Using Plugins
 
-Up to now, everything we've learned has been about how to write one-off logic for your specific Slate editor. But one of the most beautiful things about Slate is actually its plugin system, and how it lets you write less one-off code.
+Up until now, everything we've learned has been about how to write one-off logic for your specific Slate editor. But one of the most beautiful things about Slate is actually its plugin system and how it lets you write less one-off code.
 
 In the previous guide, we actually wrote some pretty useful code for adding **bold** formatting to ranges of text when a key is pressed. But most of that code wasn't really specific to **bold** text; it could just as easily have applied to _italic_ text or `code` text if we switched a few variables.
 
-So let's break that logic out into it's a reusable plugin that can toggle _any_ mark on _any_ key press.
+So let's break that logic out into a reusable plugin that can toggle _any_ mark on _any_ key press.
 
 Starting with our app from earlier:
 
@@ -43,13 +43,13 @@ class App extends React.Component {
   renderMark = props => {
     switch (props.mark.type) {
       case 'bold':
-        return <strong {...{props.attributes}}>{props.children}</strong>
+        return <strong {...props.attributes}>{props.children}</strong>
     }
   }
 }
 ```
 
-Let's write a new function, that takes a set of options: the mark `type` to toggle and the `key` to press.
+Let's write a new function that takes a set of options: the mark `type` to toggle and the `key` to press.
 
 ```js
 function MarkHotkey(options) {
@@ -60,9 +60,9 @@ function MarkHotkey(options) {
 
 Okay, that was easy. But it doesn't do anything.
 
-To fix that, we need our plugin function to return a "plugin object" that Slate recognizes. Slate's plugin objects are just plain objects that have properties that map to the same handler on the `Editor`.
+To fix that, we need our plugin function to return a "plugin object" that Slate recognizes. Slate's plugin objects are just plain JavaScript objects whose properties map to the same handlers on the `Editor`.
 
-In this case our plugin object will have one property: a `onKeyDown` handler, with its logic copied right from our current app's code:
+In this case, our plugin object will have one property, an `onKeyDown` handler, with its logic copied right from our current app's code:
 
 ```js
 function MarkHotkey(options) {
@@ -87,7 +87,7 @@ function MarkHotkey(options) {
 
 Boom! Now we're getting somewhere. That code is reusable for any type of mark.
 
-Now that we have our plugin, let's remove the hard-coded logic from our app, and replace it with our brand new `MarkHotkey` plugin instead, passing in the same options that will keep our **bold** functionality intact:
+Now that we have our plugin, let's remove the hard-coded logic from our app and replace it with our brand new `MarkHotkey` plugin instead, passing in the same options that will keep our **bold** functionality intact:
 
 ```js
 // Initialize our bold-mark-adding plugin.
@@ -181,7 +181,7 @@ class App extends React.Component {
 }
 ```
 
-And there you have it! We just added a ton of functionality to the editor with very little work. And we can keep all of our mark hotkey logic tested and isolated in a single place, making maintaining the code easier.
+And there you have it! We just added a ton of functionality to the editor with very little work. And we can keep all of our mark hotkey logic tested and isolated in a single place, making the code easier to maintain.
 
 That's why plugins are awesome. They let you get really expressive while also making your codebase easier to manage. And since Slate is built with plugins as a primary consideration, using them is dead simple!