 
   Untangled includes a few helper functions that can assist you in invoking the `untangled/load` mutation.
 
-  1. `load-data` and `load-data-action`
-  2. `load-field` and `load-field-action`
+  1. `load` and `load-action` : Newer, preferred API for most loads
+  1. `load-data` and `load-data-action` : Alternate API. Harder to use for some cases.
+  2. `load-field` and `load-field-action` : Field-targeted API (for lazy loading a component field)
 
   The former of each pair are methods that directly invoke a `transact!` to place load requests into a load queue.
 

  own mutations (e.g. you want to switch to a new area of the UI (local mutation), but also trigger a *remote read* to load the
  content of that UI at the same time).

  ### Load Data vs. Load Field

  Both of these function families are calls to the built-in `untangled/load` mutation, so requests made by either function
  go through the same networking layer and have the same customizations through their named parameters (see the doc strings
  in the [data-fetch namespace](https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/data_fetch.cljs)).
  The only difference is that `load-data` must be passed a complete query while `load-field` uses the passed-in component
  to create its query.

  `load-field` is really just a helper for a common use-case: loading a field of some specific thing on the screen. It
   focuses the component's query to the specified field, associates the component's ident with the query,

  from your server when the app initially loads, you must use `load-data` with the reconciler passed to the
  `:started-callback` function when creating a new untangled client application.

  #### Use case - Initial load

  In Untangled, initial load is an explicit step. You simply put calls to `load` or `load-data` in your app start callback.
  State markers are put in place that allow you to then render the fact that you are loading data. Any number of separate
  server queries can be queued, and the queries themselves are used for normalization. Post-processing of the response
  is well-defined and trivial to access.

  ```
  (uc/new-untangled-client
    :initial-state {}
    :started-callback
      (fn [{:keys [reconciler] :as app}]
        (df/load app :items CollectionComponent {:without #{:comments} :post-mutation 'app/build-views})
        ; OR (less preferred)
        (df/load-data reconciler [{:items (om/get-query CollectionComponent)}]
                                   :without #{: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
  (e.g. showing a dialog that has user-driven recovery choices).

  #### Use case - Loading a specific entity from the server

  The `load` function can accept an ident instead of a top-level property:

  ```
  (df/load app [:person/by-id 22] Person)
  ```

  which will load the specific entity (assuming your server responsds with it) into you client database. This could be
  used, for example, to refresh a particular entity in your client database.

  Giving a post mutation would allow you to further integrate that entity into you views.

  NOTE: the `untangled.core/integrate-ident!` function is particularly handy for peppering the resulting ident
  around the views in a post mutation.

  #### Use case - Loading a collection into an entity

  In this case you'd like to send the server some well-defined query, like `[{:all-people (om/get-query Person)}]`, but
  that will place the collection at the root of your app database under the `:all-people` key. The `:target` parameter
  can be used to redirect the result.

  Assume your database has the following state representing some UI Pane in a tab:

  ```
  { :friends { :tab { :people [] }}}
  ```

  The following load would send the desired query, and rewrite the result into the desired location (while also
  normalizing the incoming People):

  ```
  (df/load app :all-people Person {:target [:friends :tab :people]})
  ```

  ```
  { :friends { :tab { :people [[:people/by-id 1] [:people/by-id 2]] }}
    :people/by-id { 1 { ... }
                    2 { ... }}
  ```

  #### Use case - Including parameters on the server query

  Sometimes you'll want to modify the generated client query to include parameters. For example, perhaps you'd like to
  limit the query from the prior example:

  ```
  (df/load app :all-people Person {:params {:limit 10} :target [:friends :tab :people]})
  ```

  would result in `{:limit 10}` being visible in the server query parameters:

  ```
  ;; assuming your server-side read is a multimethod:
  (defmethod api-read :all-people [env k params]
     (let [limit (or (:limit params) 10)] ...))
  ```

  #### Use case - Lazy loading a field

  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
