 
   ## Om Next Components can use Stock React components
 
-  The first major strength is that Om Next integrates with stock React components. So, if you already
-  understand React you already have a head start. If you know nothing of React, you should eventually
+  The first major strength is that Om Next (and therefore Untangled) integrates with stock React components. So, if you already
+  understand React then you already have a head start. If you know nothing of React, you should eventually
   read more about it. For now, we'll cover everything you need to know.
 
   ## The Rendering Model


  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, and the query indicates which bits of that state are required for the
  current 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.

  Again, the Ident just says where the state for these goes in the database (the table and ID).

  The render is very similar to Counter. Assume 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, the callback is interesting. 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, not because we actually
  needed it (the `transact!` could have been placed in Counter).

  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 is no callback madness
  around processing the results. There is no XhrIO mixed into the UI, nor a controller you have to write to
  accomplish anything.

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



  You'll need to understand a bit more about the structure of the database to completely understand this code, but you
  see it is really quite simple: pull `:all-counters` from the database, and put them on the panel according to the
  location (known via Ident) of the panel data in the database.

  ### Server Implementation

