com.fulcrologic.fulcro.algorithms.denormalize — com.fulcrologic/fulcro 3.7.6

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

*denormalize-time* clj/s

*root-keys-and-idents* clj/s

current-time clj/s

(current-time)

db->tree clj/s

(db->tree query starting-entity state-map)

Pull a tree of data from a fulcro normalized database as a tree corresponding to the given query.

query - EQL. starting-entity - A map of data or ident at which to start. state-map - The overall normalized database from which idents can be resolved.

Returns a tree of data where each resolved data node is also marked with the current denormalize-time (dynamically bound outside of this call). Users of this function that are hydrating the UI should ensure that this time is bound to Fulcro's current internal basis-time using binding.

The state-map needs to be your entire Fulcro database. This database is used to resolve the joins in the EQL query (which are represented as idents).

The starting entity can be state-map as well if your EQL query starts from your root. If not, it can simply be the map (taken from the state-map) of the entity whose query you're using.

For example:

(defsc SomeComponent [this props]
  {:ident :thing/id
   :query [...]})

;; Get the sub-tree of data for thing 1:
(db->tree
  (comp/get-query SomeComponent)
  (get-in state-map [:thing/id 1])
  state-map)

denormalization-time clj/s

(denormalization-time props)

Gets the time at which the given props were processed by db->tree, if known.

denormalize clj/s

(denormalize {:keys [type children] :as top-node}
             current-entity
             state-map
             idents-seen)

Internal implementation of db->tree. You should normally use db->tree instead of this function.

• top-node: an AST for the query.
• current-entity: The entity to start denormalization from.
• state-map: a normalized database.
• idents-seen: a map of the idents seen so far (for recursion loop tracking).

follow-ref clj/s

(follow-ref state-map [table id :as ref])

Returns the value defined by the ref from state-map. Works for link refs and lookup refs.

link-ref? clj/s

(link-ref? v)

Is the given v a link ref query (e.g. `[:table '_]) element.

lookup-ref? clj/s

(lookup-ref? v)

Is the given v a lookup ref query (i.e. ident)?

possibly-stale? clj/s

(possibly-stale? current-state-map prior-props)

Returns true if the given prior-props are likely to be stale with respect to the current-state-map. This function returns true unless the prior-props were generated with traced-db->tree and have not since lost their metadata.

When called with properly-annotated props this function can do a very fast and accurate check to indicate if the props seem out of date. Runs N identical? checks (which are reference compares) where N is the number of root keys and idents that were traversed to originally build prior-props.

This is not proof that the props have changed, but the false indicators will all be true, meaning it is a safe (and faster) replacement for the comparisons that shouldComponentUpdate usually use.

ref-key clj/s

(ref-key [table id :as ref])

Returns the key to use in results for the given ref (ident of lookup ref). For link refs this is just the first element, and for idents it is the ident.

traced-db->tree clj/s

(traced-db->tree state-map root-key-or-ident query)

Similar to db->tree; however, the returned props will have annotated metadata the indicates what root keys and idents were visited during the conversion to a tree, along with the source state map that was used. Such props can be used with possibly-stale? to do very fast checks to see if an update is needed when state-map changes.

with-time clj/s

(with-time props t)

Associates time metadata with the given props. This time can be used by rendering optimizations to decide when stale props are passed to it from a parent in cases where props tunnelling was used for localized refresh.