   - However, if you do it, Untangled merges with the following rules:
       - If the query *asks* for an attribute, and the *response does not include it*, then it is always removed from the app state since the
       server has clearly indicated it is gone.
-      - The the query *does not ask* for an attribute (which means the response cannot possibly contain it), then Untangled
+      - If the query *does not ask* for an attribute (which means the response cannot possibly contain it), then Untangled
       will avoid removing it, even if other attributes come back (e.g. it will be a merge leaving the property that was
       not asked for alone). This does indicate that your UI is possibly in a state inconsistent with the server, which
       is the reason for the \"avoid this case\" advice.

  where the tx that failed indicates the app state is invalid...additional network interactions are probably all going to
  fail. What you want to do is trigger some kind of state reload to restore sanity.

  #### Updating an existing item

  TODO: Just like Om

  #### New item creation – Temporary IDs

  TODO: Similar to Om, but `{ :tempids tempidmap }` can be returned from `:action` of server mutation and it will
  just work. The plumbing is pre-written.

  #### Reading results after a mutation

  See notes on built-in call (untangled/load)

  ## Differences from stock Om (Next)

  For those that are used to Om, you may be interested in the differences and rationale behind the way Untangled
  handles server interactions, particularly remote reads.

  In Om, you have a fully customizable experience for reads/writes; however, to get this power you must write
  a parser to process the queries and mutations, including analyzing application state to figure out when to talk
  to a remote. While this is fully general and quite flexible (Untangled is implemented on top of it, after all),
  there is a lot of head scratching to get the result you want.

  Our realization when building Untangled was that remote reads happen in two basic cases: initial load (based on
  initial application state) and event-driven load (e.g. routing, \"load comments\", etc). Then we had a few more
  facts that we threw into the mix:

            [om.dom :as dom]
            [devcards.core :as dc :refer-macros [defcard defcard-doc]]))

; TODO: Explain Om's HATEOS (keyword listing in :keys)
; see: https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29
; TODO: Error handling (UI and server), exceptions, fallbacks, status codes
