 
   One common operation is to load data in response to a user interaction. Interestingly, the query that you might
   have used in the initial load use case might have included UI queries for data you didn't want to fetch yet. So, we want
-  to note that the initial load use-case supports eliding part of the query. For example, you can load an item without,
-  say, comments. Later, when the user wants to see comments you can supply a button that can load the comments on demand.
-
-  This is directly supported by `load-field`, which derives the query to send to the server from the component itself!
+  to note that the initial load use-case supports eliding part of the query. For example, you can for example load an item without
+  comments. Later, when the user wants to see comments you can supply a button that can load the comments on demand. The earlier
+  use case on startup demonstrated this technique.
+
+  The `load-field` function, which derives the query to send to the server from the component itself, can be used to trigger the 
+  load of the subsequent data:
 
   ```
   (load-field this :comments)

                                   :post-mutation 'app/build-views)))
  ```

  In the above example the client is created (which must be mounted as a separate step). Once mounted the application
  will call the `:started-callback` which in turn will trigger a load. This helper functions are really a call to
  om `transact!` that places `ready-to-load` markers in the app state, which in turn triggers the network plumbing. The
  network plumbing pulls these and processes them via the server and all of the normalization bits of Om (and Untangled).

  The `:without` parameter will elide portions of the query. So for example, if you'd like to lazy load some portion of the
  collection (e.g. comments on each item) at a later time, you can prevent the server from being asked.

  The `:post-mutation` parameter is the name of the mutation you'd like to run on a successful result of the query. If there
  is a failure, then a failure marker will be placed in the app state, which you can have programmed your UI to react to

  We all understand doing these kinds of transforms, so this technique gives some real concrete advantages overall:

  - Simple query to the server (only have to write one query handler)
      - Independent of the server's database structure (do items belong to categories, or just have them? etc).
  - Simple layout in resulting UI database (normalized into tables and a graph)
  - Straightforward data transform into what we want to show

  So, let's assume that the UI really wants to show a Toolbar that contains the items
  grouped by category, but our sample load is as before.

  The Untangled post-mutation can defined as:
