reword "for example" phrases

Author: rmorshea

docs/source/adding-interactivity/dangers-of-mutability/index.rst

@@ -15,7 +15,7 @@ What is a Mutation?
 In Python, values may be either "mutable" or "immutable". Mutable objects are those
 whose underlying data can be changed after they are created, and immutable objects are
 those which cannot. A "mutation" then, is the act of changing the underlying data of a
-mutable value. For example, a :class:`dict` is a mutable type of value. In the code
+mutable value. In particular, a :class:`dict` is a mutable type of value. In the code
 below, an initially empty dictionary is created. Then, a key and value is added to it:
 
 .. code-block::

docs/source/adding-interactivity/index.rst

@@ -124,7 +124,7 @@ which owns the state.
 
 This behavior of IDOM means that each render of a component is like taking a snapshot of
 the UI based on the component's state at that time. Treating state in this way can help
-reduce subtle bugs. For example, in the code below there's a simple chat app with a
+reduce subtle bugs. For instance, in the code below there's a simple chat app with a
 message input and recipient selector. The catch is that the message actually gets sent 5
 seconds after the "Send" button is clicked. So what would happen if we changed the
 recipient between the time the "Send" button was clicked and the moment the message is

docs/source/adding-interactivity/multiple-state-updates/index.rst

@@ -41,9 +41,9 @@ handlers have finished running.
 
 This behavior of IDOM to "batch" state changes that take place inside a single event
 handler, do not extend across event handlers. In other words, distinct events will
-always produce distinct renders. For example, if clicking a button increments a counter
-by one, no matter how fast the user clicks, the view will never jump from 1 to 3 - it
-will always display 1, then 2, and then 3.
+always produce distinct renders. To give an example, if clicking a button increments a
+counter by one, no matter how fast the user clicks, the view will never jump from 1 to 3
+- it will always display 1, then 2, and then 3.
 
 
 Incremental Updates

docs/source/adding-interactivity/state-as-a-snapshot/index.rst

@@ -3,9 +3,9 @@ State as a Snapshot
 
 When you watch the user interfaces you build change as you interact with them, it's easy
 to imagining that they do so because there's some bit of code that modifies the relevant
-parts of the view directly. For example, you may think that when a user clicks a "Send"
-button, there's code which reaches into the view and adds some text saying "Message
-sent!":
+parts of the view directly. As an illustration, you may think that when a user clicks a
+"Send" button, there's code which reaches into the view and adds some text saying
+"Message sent!":
 
 .. image:: _static/direct-state-change.png
 

docs/source/creating-interfaces/html-with-idom.rst

@@ -52,7 +52,7 @@ what the HTML would look like if displayed:
 
 What this shows is that you can recreate the same HTML layouts with IDOM using functions
 from the :mod:`idom.html` module. These function share the same names as their
-corresponding HTML tags. For example, the ``<h1/>`` element above has a similarly named
+corresponding HTML tags. For instance, the ``<h1/>`` element above has a similarly named
 :func:`~idom.html.h1` function. With that said, while the code above looks similar, it's
 not very useful because we haven't captured the results from these function calls in a
 variable. To do this we need to wrap up the layout above into a single

docs/source/creating-interfaces/rendering-data.rst

@@ -277,7 +277,7 @@ to work with data that already exists. In those cases, how should we pick what v
 use for each ``key``?
 
 - If your data comes from your database you should use the keys and IDs generated by
-  that database since these are inherently unique. For example, you might user the
+  that database since these are inherently unique. For example, you might use the
   primary key of records in a relational database.
 
 - If your data is generated and persisted locally (e.g. notes in a note-taking app), use

docs/source/getting-started/running-idom.rst

@@ -173,13 +173,13 @@ Specific Server Settings
 The ``Config`` :ref:`described above <Common Server Settings>` is meant to be an
 implementation agnostic - all ``Config`` objects support a similar set of options.
 However, there are inevitably cases where you need to set up your chosen server using
-implementation specific details. For example, you might want to add an extra route to
+implementation specific details. For instance, you might want to add an extra route to
 the server your using in order to provide extra resources to your application.
 
 Doing this kind of set up can be achieved by passing in an instance of your chosen
-server implementation into the ``app`` parameter of the ``run()`` function. For example,
-if I'm making my application with ``sanic`` and I want to add an extra route I would
-do the following:
+server implementation into the ``app`` parameter of the ``run()`` function. To
+illustrate, if I'm making my application with ``sanic`` and I want to add an extra route
+I would do the following:
 
 .. code-block::