The implementation of processing load/mutation result graph targeting.

The algorithm and support functions for converting a normalized Fulcro database to a tree of denormalized props.

Some misc. utility functions. These are primarily meant for internal use, and are subject to
relocation and removal in the future.

You have been warned. Changes to this ns (or its complete removal)
will not be considered breaking changes to the library, and no mention of said changes
will even appear in the changelog.

Functions that assist with supporting form editing/checking/diffing in Fulcro UI.  These functions work
by making a pristine copy of your entity, and tracking what fields have been touched.  You are responsible
for triggering these various states by marking fields as complete (`mark-complete!`), telling it to
copy the data to/from pristine (e.g. `entity->pristine`), and by asking for out-of-date data for the current
vs. pristine copy (`dirty-fields`).

There is also support for detecting which fields have been marked complete and are dirty.

Validation can be done via Clojure spec (not recommended), or by defining your own field validation functions via
`make-validator` (recommended). This general-purpose validation factory function can easily be used to create more
automated validation factories that can be more configuration-driven, but this is left as an exercise for the community.

Specs are not recommended because forms commonly have multi-field dependencies that simply are
not well-supported, and sometimes the use of things like Fulcro tempids leads to specs that you'd
rather not have on your server. Use of spec really boils down to your intention for those
spec (i.e. hard validation of final database value vs. potential runtime look of the data as
it is manipulated). Specs that include "state" information will cause you more pain than
you want, though you can certainly leverage specs anywhere it makes sense using the validator factory.

IMPORTANT: This namespace is about *(possibly recursive) form data management*. Rendering and
such are not part of the stated intention. See Fulcro RAD for more fully-automated,
multi-platform form generation.

See the Developer's Guide for more information.

Functions that implement the query and component indexing. Fulcro keeps indexes of on-screen
components by ident and class. These enable Fulcro to find on-screen components for things
like targeted refresh. You are allowed to use the indexes to find components for whatever
purpose suits your needs (e.g. looking at component options).

Fulcro is quite customizable, and all of the pluggable algorithms are stored on the app. This
very easily leads to a desire to alias the long com.fulcrologic.fulcro.application namespace
to something like `app` for easy access to keyword aliasing, but in Clojure this leads
to circular references. This namespace exists simply to save typing and hassle with
respect to that. It includes `app-algorithm` which can look up a plug-in algorithm on
an app using a simple keyword without having to require the application ns.

Various algorithms that are used for merging trees of data into a normalized Fulcro database.

Functions for dealing with normalizing Fulcro databases. In particular `tree->db`.

Functions that can be used against a normalized Fulcro state database. This namespace also includes some handy aliases
to useful functions that work on normalized state from other namespaces.

Algorithms for delaying some action by a particular amount of time.

Functions for making and consuming Fulcro temporary IDs. Tempids are used when the client is optimistically
creating a new entity and you want to be able to detect that on the server when the data is sent. Additionally,
Fulcro mutations can return a remapping instruction from the server to rewrite all tempids in the client
(state, network queues, etc.) atomically.

This allows the client to safely generate new entities with a temporary ID and let the server remap them to the real
IDs at some future time.  Transit read/write is included, so that (de)serialization of them can be consistent whenever
needed (see the `transit` ns in this package).

(ns app.development-preload
  (:require
    [taoensso.timbre :as log]
    [com.fulcrologic.fulcro.algorithms.timbre-support :refer [console-appender prefix-output-fn]))

(log/set-level! :debug)
(log/merge-config! {:output-fn prefix-output-fn
                    :appenders {:console (console-appender)}})

(try
  ...
  (catch :default ex
    (log/error ex ...))

Logging helpers to make js console logging more readable. The recommended use of these functions is as follows:

- Make sure you're using Binaryage devtools (on classpath. shadow-cljs will auto-add it when detected).
- IMPORTANT: Enable custom formatters in console settings for Chrome. This will print cljs data as cljs (instead of raw js).
- Make a development preload cljs file, and tell shadow-cljs to preload it.
- In the preload file, add something like this:

```
(ns app.development-preload
  (:require
    [taoensso.timbre :as log]
    [com.fulcrologic.fulcro.algorithms.timbre-support :refer [console-appender prefix-output-fn]))

(log/set-level! :debug)
(log/merge-config! {:output-fn prefix-output-fn
                    :appenders {:console (console-appender)}})
```

and you'll get much more readable error messages in the js console.

NOTE: when logging errors, be sure to log the exception first. This is documented in timbre, but easy to miss:

```
(try
  ...
  (catch :default ex
    (log/error ex ...))
```

See the development_preload.cljs and shadow-cljs.edn files in the latest Fulcro 3 template for an example.

Transit functions for the on-the-wire EDN communication to common remotes. Includes support for Fulcro tempids,
and can be extended to support additional application-specific data types.

The transaction processing in Fulcro is (intended to be) pluggable. This namespace is the
implementation for the default transaction processing . At the present time there is no documentation on how
such an override would be written, nor is it necessarily recommended since many of the desirable and built-in
behaviors of Fulcro are codified here. 

Helper functions for debugging tx processing.  Uses pprint, which adds
a lot to build size, so it is in a separate ns to keep it out of prod builds.

Functions for issuing loads of subgraphs of data for your application. The primary functions of interest are
`load!` and `load-field!`. Fulcro's composed queries and idents allow these loads to automatically be normalized
and merged into your database. The data targeting support allows you to then *join* that new subgraph to the
existing UI data graph. This process is the central topic to understand in Fulcro, and it is to your advantage
to study the concepts of Fulcro idents and query composition carefully.

Support for rendering DOM from CLJ. Must be separate to enable same-named macros in CLJS for performance.

Usage: Create your UI in CLJC files, and require with conditional reader tags:

(ns app.ui
  (:require
    #?(:clj [com.fulcrologic.fulcro.dom-server :as dom] :cljs [com.fulcrologic.fulcro.dom :as dom])))

Utility functions for working with low-level synthetic js events on the DOM

(ns my.ui
  (:require
    [com.fulcrologic.fulcro.dom.html-entities :as ent]))
    
...
   (dom/div ent/nbsp ent/copy)
...

Defs of the proper unicode characters so you can use html entities in your DOM functions without having to
look them up (or type out silly things like "\u00C6"

For example:

```
(ns my.ui
  (:require
    [com.fulcrologic.fulcro.dom.html-entities :as ent]))
    
...
   (dom/div ent/nbsp ent/copy)
...
```

SVG-encoded material UI icons.

See https://material-ui.com/components/icons

A namespace for dealing with inputs in HTML DOM when you wish to control a value in the data model
that cannot be directly represented by normal HTML inputs (which always use strings). For example, you want to have an int in
your data model, but HTML5 number inputs return a string. The primary utility is `StringBufferedInput` which generates
a new React class that wraps an HTML `input`. The namespace also includes a few uses that are handy (at least as
examples): `ui-int-input` and `ui-keyword-input`. See the source of those for examples.

;; The unquote on the parameters is typically needed because you'll use surrounding binding values in them.
(let [x 3
      some-local-value 42]
  (comp/transact! this `[(f ~{:x x}) (g ~{:y some-local-value})]))
;; or, if pre-declared and required:
(let [x 3
      some-local-value 42]
  (comp/transact! this [(f {:x x}) (g {:y some-local-value})]))

(defn func [x] (inc x))
(defmutation f [params] ...)

;; A regular function runs when called...
(func 3)
;; => 4

;; A mutation simply returns its expression when called:
(f {:x 1})
;; => (f {:x 1})

Mutations are the central mechanism of getting things done in Fulcro. The term mutation refers to two things:

* The literal data that stands for the operation. These are lists with a single symbol and a map of parameters. In
earlier version, you had to quote them: `'[(f {:x 1})]`, but Fulcro 3 includes a way to declare them so that they
auto-quote themselves for convenience. This can be confusing to new users. Remember that a mutation call is nothing
more than a *submission* of this data via `comp/transact!` (i.e. call `f` with the parameter `{:x 1}`).
* One or more definitions of what to do when the mutation is requested.

The former are submitted with `transact!` and can be written like so:

```
;; The unquote on the parameters is typically needed because you'll use surrounding binding values in them.
(let [x 3
      some-local-value 42]
  (comp/transact! this `[(f ~{:x x}) (g ~{:y some-local-value})]))
;; or, if pre-declared and required:
(let [x 3
      some-local-value 42]
  (comp/transact! this [(f {:x x}) (g {:y some-local-value})]))
```

This works because a mutation *definition* actually builds a record that response to function calls. This means

```
(defn func [x] (inc x))
(defmutation f [params] ...)

;; A regular function runs when called...
(func 3)
;; => 4

;; A mutation simply returns its expression when called:
(f {:x 1})
;; => (f {:x 1})
```

This allows you to embed a mutation expression without quoting in your calls to transact (if desired) or with
quoting if you have something like a circular reference problem.

See the Developer's Guide for more information.

Support for converting binary network responses to a usable File URL in a browser. This
file is CLJC so the functions exist for SSR, but they do nothing in CLJ.

Simple adapter code that allows you to use a generic parser 'as if' it were a client remote in CLJS.

A render optimization algorithm for refreshing the UI via props tunnelling (setting new props on a component's
state in a pre-agreed location). This algorithm analyzes database changes and on-screen components to update
components (by ident) whose props have changed.

Prop change detection is done by scanning the database in *only* the locations that on-screen components are querying
(derived by the mounted component idents, and any ident-joins in the queries).

The keyframe optimized render.

Just like keyframe render, but supports `:only-refresh` option.

(defonce app (app/fulcro-app {:optimized-render! mroot/render!}))

(defsc AltRoot [this {:keys [alt-child]}]
  ;; query is from ROOT of the db, just like normal root.
  {:query                 [{:alt-child (comp/get-query OtherChild)}]
   :componentDidMount     (fn [this] (mroot/register-root! this {:app app}))
   :componentWillUnmount  (fn [this] (mroot/deregister-root! this {:app app}))
   :shouldComponentUpdate (fn [] true)
   :initial-state         {:alt-child [{:id 1 :n 22}
                                       {:id 2 :n 44}]}}
  (dom/div
    (mapv ui-other-child alt-child)))

;; For use in the body of normal defsc components.
(def ui-alt-root (mroot/floating-root-factory AltRoot))

;; For use as plain React class
(def PlainAltRoot (mroot/floating-root-react-class AltRoot app))

...

(some-js-library #js {:thing PlainAltRoot})

(defsc NormalFulcroClass [this props]
  {:query [:stuff]
   :ident (fn [] [:x 1])
   ...}
  (dom/div
    ;; ok to use within defsc components:
    (ui-alt-root)
    ;; how to use the plain react class, which is how js libs would use it:
    (dom/create-element PlainAltRoot)))

Like keyframe-render2, but also supports free-floating roots.

WARNING: THIS RENDERER IS ALPHA. Lightly tested, but not heavily used yet.

General usage:

1. Set this nses `render!` as your application's optimized render function.
2. Create a class that follows all of the normal rules for a Fulcro root (no ident, has initial state,
composes children queries/initial-state, etc.
   a. Add mount/unmount register/deregister calls
2. Use floating-root-factory to generate a Fulcro factory, or floating-root-react-class to generate
a vanilla React wrapper class that renders the new root.
   a. Use the factory in normal Fuclro rendering, but don't pass it props, or
   b. Use `(dom/create-element ReactClass)` to render the vanilla wrapper, or
   c. Use the vanilla wrapper class when a js library controls rendering (like routing).

Example:

```
(defonce app (app/fulcro-app {:optimized-render! mroot/render!}))

(defsc AltRoot [this {:keys [alt-child]}]
  ;; query is from ROOT of the db, just like normal root.
  {:query                 [{:alt-child (comp/get-query OtherChild)}]
   :componentDidMount     (fn [this] (mroot/register-root! this {:app app}))
   :componentWillUnmount  (fn [this] (mroot/deregister-root! this {:app app}))
   :shouldComponentUpdate (fn [] true)
   :initial-state         {:alt-child [{:id 1 :n 22}
                                       {:id 2 :n 44}]}}
  (dom/div
    (mapv ui-other-child alt-child)))

;; For use in the body of normal defsc components.
(def ui-alt-root (mroot/floating-root-factory AltRoot))

;; For use as plain React class
(def PlainAltRoot (mroot/floating-root-react-class AltRoot app))

...

(some-js-library #js {:thing PlainAltRoot})

(defsc NormalFulcroClass [this props]
  {:query [:stuff]
   :ident (fn [] [:x 1])
   ...}
  (dom/div
    ;; ok to use within defsc components:
    (ui-alt-root)
    ;; how to use the plain react class, which is how js libs would use it:
    (dom/create-element PlainAltRoot)))

```

A router that uses Fulcro dynamic queries to optimize query performance on rendering and provides a number of useful
features such as easy composition, control over route targeting, on-screen component vetoes of routing requests, etc.

NOTE: This router is *not* concerned with HTML5 history events or URL management. This router is intended to be usable
in server-side rendering, React Native, and anywhere else Fulcro might be used. Therefore it is not tied to a particular
rendering platform's idea of location management (i.e. URLs).

The structure of the route composition (and its representation as a sequence of string path components) is intended to
be easy to integrate with HTML5 history and URL control.

Routers from Fulcro 2. These are a bit harder to use than the new dynamic router, and should probably not be used
in new applications; however, they will be supported for the forseeable future.

Standard Ring middleware for setting up servers to handle Fulcro requests. These assume you will be using a library
like Pathom to create a parser that can properly dispatch resolution of requests. See the Developer's Guide or
the Fulcro template for examples of usage.

Utilities for managing server configuration via EDN files.

The general design requirements of this support are that you should be able to:

* Specify your configuration as EDN.
* Specify a reasonable set of server config values as "defaults" so that specific environments can override
just what matters.
* Override the defaults by deep-merging an environment-specific config file over the defaults.
* Specify individual overrides via environment variables.
** Support rich data types from environment variables, like maps, numerics, etc.

So the basic operation is that you create a default EDN file and one or more environment files (e.g.
`dev.edn`, `prod.edn`, `joes-test-env.edn`, etc. You can then use a combination of runtime parameters,
JVM properties, and environment variables to end up with your runtime configuration.

See `load-config!` for more detailed usage.

Support for structuring the logic of component interactions as a state machine. Useful when
the logic of a group of components becomes non-trivial, which is often. Note that it is not
recommended that you try to structure large parts of your application as a state machine
(since this implementation is closer to FSM than state charts), but it turns out that
most applications work very well with groups of components under separate state machines
as somewhat larger modules of the overall application. See the Developer's Guide for
more information on working with this namespace.