   could have labels, owners, purposes, etc.
   - Ident : Represents the table/ID of the database data for the component. This is a function that, given an example
   of a counter, will return a vector that has two elements: the table and the ID of the entry. This is used
-  to assist in auto-normalization of the browser database.
+  to assist in auto-normalization of the browser database, and also with UI refreshes of components that display the
+  same data.
   - Object/render : This is the (pure) function that outputs what a Counter should look like on the DOM
 
   The incoming data from the database comes in via `om/props`, and things like callbacks come in via a mechanism known
   as the 'computed' data (e.g. stuff that isn't in the database, but is generated by the UI, such as callbacks).
 
-  A `defui` generates a React Component. In order to render an instance of a Counter, we must make an element
+  A `defui` generates a React Component (class). In order to render an instance of a Counter, we must make an element
   factory:
   "
   (dc/mkdn-pprint-source ui-counter)
   "
   If more than one of something can appear in the UI as siblings, you must specify a `:keyfn` that helps React
-  distinguish the DOM elements. You can ignore that for now.
+  distinguish the DOM elements.
 
   The most important point is that you can reason about `Counter` in a totally local way.
 

  ```

  This looks a little hairy at first until you notice the primary guts are just what we talked about earlier in
  the model manipulation: it's just an update-in.

  The wrapping is a pretty consistent pattern: the app state and parameters are passed into a multimethod, which is
  dispatched on the symbol mentioned in the `transact!`. The basics are:

  - You key on a symbol instead of writing a function with that symbol name
  - You return a map
  - The `:action` key indicates a function to run as an optimistic update to the browser database

  When you want to interact with a server, you need merely change it to:



  Lets assume we want to display some arbitrary number of counters together in a panel. We can encode that (and the
  element factory) as:

  "
  (dc/mkdn-pprint-source CounterPanel)
  (dc/mkdn-pprint-source ui-counter-panel)
  "

  Note the mirroring again between the initial state and the query. The initial state provides an initial model
  of what should be in the database *for the component at hand*, and the query indicates which bits of that state are
  required for that same local component.

  In this case the query contains a map, which is the query syntax for a JOIN. You can read this query as
  'Query for :counters, which is a JOIN on Counter'. Note that since initial state is setting up a vector
  of counters, the implied result will be a to-many JOIN. The cardinality of JOINS is derived from the structure
  of the actual database, NOT the query.

  The join is necessary because this component will be rendering Counter components. The panel should not need to
  know anything concrete about the implementation of Counter: only that it has a query, initial state, and a way
  to render.

  The render is very similar to Counter's. The queried data will appear in props: pull it out, and
  then render it. Note the use of `ui-counter`, which is the DOM element factory for `Counter`.

  Finally, we include a callback. The counter has the 'Increment' button, but we've connected that from the
  counter UI back through to an implementation of a callback via 'computed' properties. This is a common pattern. In
  this simple example the callback structure was added to demonstrate what it looks like. One could argue that the
  counter could update itself (while maintaining local reasoning).

  The implementation of the `counter/inc` mutation was shown earlier.

  There are many important points to make here, but we would like to stress the fact that the UI has no idea
  *how* counters are implemented, *if* that logic includes server interactions, etc. There are no nested callbacks
  of callbacks, no XhrIO mixed into the UI, and interestingly: no need for controller at all!

  A simple pattern of updating an abstraction in a database is all you need.

