Fix doc typos

Thanks Dana :)

Author: rmorshea

docs/source/core-concepts.rst

@@ -13,7 +13,7 @@ Pure Elements
 -------------
 
 As in most programming paradigms, so many of the problems come down to how we manage
-state, and the first tool in encouraging its proper curation is the usage of
+state. The first tool in encouraging its proper curation is the usage of
 `pure functions`_. The benefit of a pure function is that there's no state. Similar to
 the addage "the best code is no code at all," we make the related claim that "the best
 way to manage state is to have no state at all."
@@ -33,7 +33,7 @@ accepted a list of strings and turned it into a series of paragraph elements:
 Stateful Elements
 -----------------
 
-A Stateful Element is one which uses a :ref:`Life Cycle Hook`. These lifecycle hooks
+A Stateful Element is one which uses a :ref:`Life Cycle Hook`. These life cycle hooks
 allow you to add state to otherwise stateless functions. To create a stateful element
 you'll need to apply the :func:`~idom.core.element.element` decorator to a coroutine_
 whose body contains a hook usage. We'll demonstrate that with a simple
@@ -70,11 +70,11 @@ ever be removed from the model. Then you'll just need to call and await a
     async with idom.Layout(ClickCount()) as layout:
         patch = await layout.render()
 
-The layout also handles the triggering event handlers. Normally this is done
-automatically by a :ref:`Renderer <Layout Renderer>`, but for now we'll to it manually.
-To do use we can use a trick to hard-code the ``event_handler_id`` so we can pass it,
-and a fake event, to the layout's :meth:`~idom.core.layout.Layout.dispatch` method. Then
-we just have to re-render the layout and see what changed:
+The layout also handles the triggering of event handlers. Normally this is done
+automatically by a :ref:`Renderer <Layout Renderer>`, but for now we'll do it manually.
+We can use a trick to hard-code the ``event_handler_id`` so we can pass it, and a fake
+event, to the layout's :meth:`~idom.core.layout.Layout.dispatch` method. Then we just
+have to re-render the layout and see what changed:
 
 .. testcode::
 
@@ -118,8 +118,8 @@ Layout Renderer
 An :class:`~idom.core.render.AbstractRenderer` implementation is a relatively thin layer
 of logic around a :class:`~idom.core.layout.Layout` which drives the triggering of
 events and layout updates by scheduling an asynchronous loop that will run forever -
-effectively animating the model. To run the loop the renderer's
-:meth:`~idom.core.render.AbstractRenderer.run` method accepts two callbacks, one is a
+effectively animating the model. To execute the loop, the renderer's
+:meth:`~idom.core.render.AbstractRenderer.run` method accepts two callbacks. One is a
 "send" callback to which the renderer passes updates, while the other is "receive"
 callback that's called by the renderer to events it should execute.
 
@@ -172,10 +172,10 @@ Layout Server
 -------------
 
 The :ref:`Renderer <Layout Renderer>` allows you to animate the layout, but we still
-need to get the models on the screen, and one of the last steps in that journey is to
-send them over the wire. To do that you need an
+need to get the models on the screen. One of the last steps in that journey is to send
+them over the wire. To do that you need an
 :class:`~idom.server.base.AbstractRenderServer` implementation. Right now we have a
-builtin subclass that relies on :mod:`sanic`, an async enabled web server. In principle
+built in subclass that relies on :mod:`sanic`, an async enabled web server. In principle
 though, the base server class is capable of working with any other async enabled server
 framework. Potential candidates range from newer frameworks like
 `vibora <https://vibora.io/>`__, `starlette <https://www.starlette.io/>`__, and
@@ -188,7 +188,7 @@ starting to add support for asyncio like
     an `issue <https://github.com/rmorshea/idom/issues>`__.
 
 In the case of our :class:`~idom.server.sanic.SanicRenderServer` types we have one
-implementation per builtin :ref:`Renderer <Layout Renderer>`:
+implementation per built in :ref:`Renderer <Layout Renderer>`:
 
 - :class:`idom.server.sanic.PerClientStateServer`
 
@@ -201,7 +201,7 @@ two ways - as a standalone application or as an extension to an existing applica
 Standalone Server Usage
 .......................
 
-The implementation constructs a default application that's used to server the renders of
+The implementation constructs a default application that's used to serve the renders of
 the model:
 
 .. code-block:: python
@@ -220,7 +220,7 @@ the model:
 Server Extension Usage
 ......................
 
-The implementation registers hooks into the application to server the model once run:
+The implementation registers hooks into the application to serve the model once run:
 
 .. code-block:: python
 

docs/source/getting-started.rst

@@ -29,7 +29,7 @@ Let's look at the example that you may have seen
     server = idom.server.sanic.PerClientStateServer(Slideshow)
     server.run(host, port)
 
-Since it's likely a lot to take in at once we'll break it down piece by piece:
+Since it's likely a lot to take in at once, we'll break it down piece by piece:
 
 .. code-block::
 
@@ -58,9 +58,9 @@ to the Element's render function.
 
 The ``use_state`` hook returns two values - the *current* state value and a function
 that let's you update that value. In the case of ``Slideshow`` the value of the
-``use_state`` hook determines which image is show to the user, while its update function
-allow us to change it.The one required argument of ``use_state`` is the *initial* state
-value.
+``use_state`` hook determines which image is showm to the user, while its update
+function allow us to change it. The one required argument of ``use_state`` is the
+*initial* state value.
 
 .. note::
 
@@ -71,7 +71,7 @@ value.
         async def next_image(event):
             set_index(index + 1)
 
-The coroutine above will get added as an event handler to the resulting view. Whe it
+The coroutine above will get added as an event handler to the resulting view. When it
 responds to an event it will use the update function returned by the ``use_state`` Hook
 to change which image is shown to the user. Calling the update function will schedule
 the Element to be re-rendered. That is, the Element's render function will be called
@@ -80,8 +80,8 @@ again, and its new result will be displayed.
 .. note::
 
     Even handlers like ``next_image`` which respond to user interactions recieve an
-    ``event`` dictionary that contains different information depending on they type
-    of event that occured. All supported events and the data they contain is listed
+    ``event`` dictionary that contains different information depending on the type of
+    event that occured. All supported events and the data they contain is listed
     `here`__.
 
 __ https://reactjs.org/docs/events.html
@@ -96,12 +96,12 @@ __ https://reactjs.org/docs/events.html
             }
         )
 
-Finally we come the end the ``Slideshow`` body where we return a model for an ``<img/>``
-element that draws its image from https://picsum.photos. Our ``next_image`` event
-handler has been added to the image so that when an ``onClick`` event occurs we can
-respond to it. We've also added a little bit of CSS styling to the image so that when
-the cursor hoverse over the image it will become a pointer so it appears clickable. The
-returned model conforms to the `VDOM mimetype specification`_.
+Finally we come to the end of the ``Slideshow`` body where we return a model for an
+``<img/>`` element that draws its image from https://picsum.photos. Our ``next_image``
+event handler has been added to the image so that when an ``onClick`` event occurs we
+can respond to it. We've also added a little bit of CSS styling to the image so that
+when the cursor hoverse over the image it will become a pointer so it appears clickable.
+The returned model conforms to the `VDOM mimetype specification`_.
 
 .. code-block::
 
@@ -113,7 +113,7 @@ These last steps prepare a simple web server that will send the layout of elemen
 defined in our ``Slideshow`` to the browser and receive any incoming events from the
 browser via a websocket. The server has "per client state" because each client that
 connects to it will see a fresh view of the layout. If clients should see views with a
-common state you can use the ``SharedClientState`` server instead.
+common state you can use the ``SharedClientStateServer`` instead.
 
 To display the layout we can navigate to http://localhost:8765/client/index.html or
 use ``idom.display()`` to show it in a Jupyter Notebook via a widget.

docs/source/index.rst

@@ -29,7 +29,7 @@ Try it Now!
 
 - In a Jupyter Notebook - |launch-binder|
 
-- With an online editor - `IDOM Sandbox`_
+- Using working :ref:`examples <Examples>`
 
 
 Early Days
@@ -69,8 +69,8 @@ user clicks an image:
     server.run(host, port)
 
 Running this will serve our slideshow to ``"https://localhost:8765"``. You can try out
-a working example by enabling the widget below - clicking the image should cause it to
-change 🖱️
+a working example by enabling the widget below. Once enabled clicking the image will
+cause the widget to change 🖱️
 
 .. interactive-widget:: slideshow
 

docs/source/installation.rst

@@ -49,14 +49,14 @@ In order to work with IDOM's source code you'll need to install:
 
 - npm_
 
-You'll begin by copy the source from GitHub onto your computer using Git:
+You'll begin by copying the source from GitHub onto your computer using Git:
 
 .. code-block:: bash
 
     git clone https://github.com/rmorshea/idom.git
     cd idom
 
-At this point you should be able to run this install command to:
+At this point you should be able to run the command below to:
 
 - Install an editable version of the Python code
 
@@ -78,8 +78,8 @@ simply run the following to re-evaluate the ``package.json``:
     pip install -e .
 
 
-Running The Test
-----------------
+Running The Tests
+-----------------
 
 The test suite for IDOM is executed using Tox_ and covers:
 
@@ -122,7 +122,7 @@ If you prefer to run the tests using a headless browser:
 Building The Documentation
 --------------------------
 
-Building the documentation as it's is deployed in production requires Docker_. Once you've
+Building the documentation as it's deployed in production requires Docker_. Once you've
 installed ``docker`` you'll need to build and then run a container with the service:
 
 .. code-block:: bash

docs/source/life-cycle-hooks.rst

@@ -32,7 +32,7 @@ use_state
 Returns a stateful value and a function to update it.
 
 During the first render the ``state`` will be identical to the ``initial_state`` passed
-as the first argument. However in subsiquent renders ``state`` will take on the value
+as the first argument. However in subsequent renders ``state`` will take on the value
 passed to ``set_state``.
 
 .. code-block::
@@ -41,7 +41,7 @@ passed to ``set_state``.
 
 The ``set_state`` function accepts a ``new_state`` as its only argument and schedules a
 re-render of the element where ``use_state`` was initially called. During these
-subsiquent re-renders the ``state`` returned by ``use_state`` will take on the value
+subsequent re-renders the ``state`` returned by ``use_state`` will take on the value
 of ``new_state``.
 
 .. note::
@@ -56,7 +56,7 @@ Functional Updates
 
 If the new state is computed from the previous state, you can pass a function which
 accepts a single argument (the previous state) and returns the next state. Consider this
-simple use case of a counter where we've pulled out logic for incrementing and
+simply use case of a counter where we've pulled out logic for incrementing and
 decrementing the count:
 
 .. literalinclude:: examples/use_state_counter.py
@@ -65,7 +65,7 @@ decrementing the count:
 
 We use the functional form for the "+" and "-" buttons since the next ``count`` depends
 on the previous value, while for the "Reset" button we simple assign the
-``initial_count`` since it's independent of the prior ``count``. This is a trivial
+``initial_count`` since it is independent of the prior ``count``. This is a trivial
 example, but it demonstrates how complex state logic can be factored out into well
 defined and potentially reuseable functions.
 
@@ -103,19 +103,17 @@ use_effect
 
     use_effect(did_render)
 
-The ``use_effect`` hook accepts a function which is may be imperative, or mutate state.
-The function will be called once the element has rendered, that is, when the
-element's render function and those of any child elements it produces have rendered
-successfully.
+The ``use_effect`` hook accepts a function which may be imperative, or mutate state. The
+function will be called immediately after the layout has fully updated.
 
-Mutations, subscriptsion, delayed actions, and other `side effects`_ can cause
+Mutations, subscriptions, delayed actions, and other `side effects`_ can cause
 unexpected bugs if placed in the main body of an element's render function. Thus the
 ``use_effect`` hook provides a way to safely escape the purely functional world of
 element render functions.
 
 .. note::
 
-    Normally in react the ``did_render`` function is called once an update has been
+    Normally in React the ``did_render`` function is called once an update has been
     commited to the screen. Since no such action is performed by IDOM, and the time
     at which the update is displayed cannot be known we are unable to achieve parity
     with this behavior.
@@ -124,15 +122,16 @@ element render functions.
 Cleaning Up Effects
 ...................
 
-If the effect you wish to enact creates resources you'll probably need to clean them up.
-In such cases you may simply return a function the addresses this from the function
-which created the resource. Consider the case of opening and then closing a connection:
+If the effect you wish to enact creates resources, you'll probably need to clean them
+up. In such cases you may simply return a function that addresses this from the
+``did_render`` function which created the resource. Consider the case of opening and
+then closing a connection:
 
 .. code-block::
 
     def establish_connection():
         connection = open_connection(url)
-        return connection.close
+        return lambda: close_connection(connection)
 
     use_effect(establish_connection)
 
@@ -145,7 +144,7 @@ time an element renders.
 Conditional Effects
 ...................
 
-By default effects are triggered after ever successful render to ensure that all state
+By default, effects are triggered after every successful render to ensure that all state
 referenced by the effect is up to date. However you can limit the number of times an
 effect is fired by specifying exactly what state the effect depends on. In doing so
 the effect will only occur when the given state changes:
@@ -154,7 +153,7 @@ the effect will only occur when the given state changes:
 
     def establish_connection():
         connection = open_connection(url)
-        return connection.close
+        return lambda: close_connection(connection)
 
     use_effect(establish_connection, [url])
 
@@ -210,12 +209,12 @@ use_callback
 
 A derivative of :ref:`use_memo`, the ``use_callback`` hook teturns a
 `memoized <memoization>`_ callback. This is useful when passing callbacks to child
-elements which check reference equality to prevent unnecessary renders. The of the
+elements which check reference equality to prevent unnecessary renders. The of
 ``memoized_callback`` will only change when the given depdencies do.
 
 .. note::
 
-    The list of "dependencies" are not passed as arguments to the function ostensibly
+    The list of "dependencies" are not passed as arguments to the function. Ostensibly
     though, that is what they represent. Thus any variable referenced by the function
     must be listed as dependencies. We're working on a linter to help enforce this
     [GH202]_.
@@ -243,9 +242,9 @@ after) and should not incur side effects.
 
 .. warning::
 
-    Remember that you shouldn't optimize something else you know it's a performance
-    bottleneck. Write your code without ``use_memo`` first and then add it to later
-    to targeted sections that need a speed-up.
+    Remember that you shouldn't optimize something unless you know it's a performance
+    bottleneck. Write your code without ``use_memo`` first and then add it to targeted
+    sections that need a speed-up.
 
 .. note::
 
@@ -267,9 +266,9 @@ Returns a mutable :class:`~idom.core.hooks.Ref` object that has a single
 ``initial_state``. The identity of the ``Ref`` object will be preserved for the lifetime
 of the element.
 
-A ``Ref`` is most useful if you need to incur side effect since updating its
+A ``Ref`` is most useful if you need to incur side effects since updating its
 ``.current`` attribute doesn't trigger a re-render of the element. You'll often use this
-hook alongside :ref:`use_effect` or in response to element event handlers. The
+hook alongside :ref:`use_effect` or in response to element event handlers.
 :ref:`The Game Snake` provides a good use case for ``use_ref``.
 
 

idom/core/element.py

@@ -60,7 +60,7 @@ class Element(AbstractElement):
     From there an element instance will communicate its needs to the layout. For example
     when an element wants to re-render it will call :meth:`idom.core.layout.Layout.element_updated`.
 
-    The lifecycle of an element typically goes in this order:
+    The life cycle of an element typically goes in this order:
 
     1. The element instance is instantiated.