 
   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.
 

  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 - Lazy loading

  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

  the code to use the action-suffixed load instead. To learn more about the dangers of loads and lifecycle methods, see
  the [reference on loading data]().

  ### Using the `untangled/load` Mutation Directly

  The helper functions described above simply trigger a built-in Untangled mutation called `untangled/load`, which you are
  allowed (and sometimes encouraged) to use directly. The arguments to this mutation include:

  - `query`: The specific query you'd like to send to the server
  - `post-mutation`: A symbol indicating a mutation to run after the load completes
  - `post-mutation-params` - An optional map  that will be passed to the post-mutation when it is called. May only contain raw data, not code!
  - `without`: A set of keywords that should be (recursively) removed from `query`
  - `refresh`: A vector of keywords that should cause re-rendering after the load.
  - `parallel`: True or false. If true, bypasses the sequential network queue
