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.
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.
(data-state? state)
Is the given parameter a load marker?
Is the given parameter a load marker?
(elide-ast-nodes {:keys [key union-key children] :as ast} elision-predicate)
Remove items from a query (AST) that have a key that returns true for the elision-predicate
Remove items from a query (AST) that have a key that returns true for the elision-predicate
(elide-query-nodes query node-predicate)
Remove items from a query when the query element where the (node-predicate key) returns true. Commonly used with a set as a predicate to elide specific well-known UI-only paths.
Remove items from a query when the query element where the (node-predicate key) returns true. Commonly used with a set as a predicate to elide specific well-known UI-only paths.
(failed? marker)
Is the given load marker indicate failed?
WARNING: This function is current unimplemented and will be removed. The new way of dealing with failure is to
define an error-action
for the load in question and modify your own state. You can also override
Is the given load marker indicate failed? WARNING: This function is current unimplemented and will be removed. The new way of dealing with failure is to define an `error-action` for the load in question and modify your own state. You can also override
(finish-load! {:keys [app result transmitted-ast] :as env}
{:keys [query ok-action post-mutation post-mutation-params
post-action target marker source-key]
:as params})
Default processing when a load finishes successfully (called internally).
Removes any load marker, then either:
ok-action
(if defined).Default processing when a load finishes successfully (called internally). Removes any load marker, then either: - Runs the `ok-action` (if defined). - Does normal post-processing (if the was no ok-action): - Merges the load result - Processes desired targets - Runs the post-mutation (if defined) - Runs the post-action (if defined)
(load! app-or-comp server-property-or-ident class-or-factory)
(load! app-or-comp server-property-or-ident class-or-factory config)
Load data from the server.
This function triggers a server interaction and normalizes the server response into your app state database. During
operation it also adds (by default) fetch markers into the app state so you can show busy indicators on the UI
components that are waiting for data. The :target
parameter can be used to place the data somewhere besides app
state root (which is the default).
The server will receive a query of the form: [({server-property (comp/get-query class-or-factory)} params)], which a Fulcro parser will correctly parse as a join on server-property with the given subquery and params. See the AST and instructions on parsing queries in the developer's guide.
Parameters:
app-or-comp
: A component instance or Fulcro applicationserver-property-or-ident
: A keyword or ident that represents the root of the query to send to the server. If this is an ident
you are loading a specific entity from the database into a local app db table. A custom target will be ignored.class-or-factory
: A component that implements IQuery, or a factory for it (if using dynamic queries). This will be combined with server-property
into a join for the server query. Needed to normalize results.
class-or-factory can be nil, in which case the resulting server query will not be a join.config
: A map of load configuration parameters.Config (all optional):
target
- An assoc-in path at which to put the result of the Subquery (as an edge (normalized) or value (not normalized)).
Can also be special targets (multiple-targets, append-to,
prepend-to, or replace-at). If you are loading by keyword (into root), then this relocates the result (ident or value) after load.
When loading an entity (by ident), then this option will place additional idents at the target path(s) that point to that entity.initialize
- REMOVED. Use component pre-merge instead.remote
- Optional. Keyword name of the remote that this load should come from.params
- Optional parameters to add to the generated querymarker
- ID of marker. Normalizes a load marker into app state so you can see progress.refresh
- A list of things in the UI to refresh. Depends on rendering optimization.focus
- Focus the query along a path. See eql/focus-subquery.without
- A set of keys to remove (recursively) from the query.update-query
- A general-purpose function that can transform the component query before sending to remote. See also
the application's :global-eql-transform
option.
For example, to focus a subquery using update-query: {:update-query #(eql/focus-subquery % [:my {:sub [:query]}])}
Removing properties (like previous :without option): {:update-query #(df/elide-query-nodes % #{:my :elisions})}
abort-id
- Set a unique key. If supplied, then the load can be cancelled via that abort ID.parallel
- Send the load out-of-order (immediately) without waiting for other loads in progress.post-mutation
- A mutation (symbol) to run after the data is merged. Note, if target is supplied be sure your post mutation
should expect the data at the targeted location. The env
of that mutation will be the env of the load (if available), but will also include :load-request
.post-mutation-params
- An optional map that will be passed to the post-mutation when it is called.post-action
- A lambda that will get a mutation env parameter (fn [env] ...)
. Called after success, like post-mutation
(and after post-mutation if also defined). env
will include the original :load-params
and raw network layer :result
. If you
want the post behavior to act as a top-level mutation, then prefer post-mutation
. The action can also call transact!
.fallback
- A mutation (symbol) to run if there is a server/network error. The env
of the fallback will be like a mutation env
, and will
include a :result
key with the real result from the server, along with the original :load-params
.Special-purpose config options:
The config options can also include the following things that completely override behaviors of other (respons-processing) options, and should only be used in very advanced situations where you know what you are doing:
ok-action
- WARNING: OVERRIDES ALL DEFAULT OK BEHAVIOR (except load marker removal)! A lambda that will receive an env parameter (fn [env] ...)
that
includes the :result
and original :load-params
.error-action
- WARNING: OVERRIDES ALL DEFAULT ERROR BEHAVIOR (except load marker update). A lambda that will receive an env
that includes the :result
and original :load-params
.Load data from the server. This function triggers a server interaction and normalizes the server response into your app state database. During operation it also adds (by default) fetch markers into the app state so you can show busy indicators on the UI components that are waiting for data. The `:target` parameter can be used to place the data somewhere besides app state root (which is the default). The server will receive a query of the form: [({server-property (comp/get-query class-or-factory)} params)], which a Fulcro parser will correctly parse as a join on server-property with the given subquery and params. See the AST and instructions on parsing queries in the developer's guide. Parameters: - `app-or-comp` : A component instance or Fulcro application - `server-property-or-ident` : A keyword or ident that represents the root of the query to send to the server. If this is an ident you are loading a specific entity from the database into a local app db table. A custom target will be ignored. - `class-or-factory` : A component that implements IQuery, or a factory for it (if using dynamic queries). This will be combined with `server-property` into a join for the server query. Needed to normalize results. class-or-factory can be nil, in which case the resulting server query will not be a join. - `config` : A map of load configuration parameters. Config (all optional): - `target` - An assoc-in path at which to put the result of the Subquery (as an edge (normalized) or value (not normalized)). Can also be special targets (multiple-targets, append-to, prepend-to, or replace-at). If you are loading by keyword (into root), then this relocates the result (ident or value) after load. When loading an entity (by ident), then this option will place additional idents at the target path(s) that point to that entity. - `initialize` - REMOVED. Use component pre-merge instead. - `remote` - Optional. Keyword name of the remote that this load should come from. - `params` - Optional parameters to add to the generated query - `marker` - ID of marker. Normalizes a load marker into app state so you can see progress. - `refresh` - A list of things in the UI to refresh. Depends on rendering optimization. - `focus` - Focus the query along a path. See eql/focus-subquery. - `without` - A set of keys to remove (recursively) from the query. - `update-query` - A general-purpose function that can transform the component query before sending to remote. See also the application's `:global-eql-transform` option. For example, to focus a subquery using update-query: `{:update-query #(eql/focus-subquery % [:my {:sub [:query]}])}` Removing properties (like previous :without option): `{:update-query #(df/elide-query-nodes % #{:my :elisions})}` - `abort-id` - Set a unique key. If supplied, then the load can be cancelled via that abort ID. - `parallel` - Send the load out-of-order (immediately) without waiting for other loads in progress. - `post-mutation` - A mutation (symbol) to run *after* the data is merged. Note, if target is supplied be sure your post mutation should expect the data at the targeted location. The `env` of that mutation will be the env of the load (if available), but will also include `:load-request`. - `post-mutation-params` - An optional map that will be passed to the post-mutation when it is called. - `post-action` - A lambda that will get a mutation env parameter `(fn [env] ...)`. Called after success, like post-mutation (and after post-mutation if also defined). `env` will include the original `:load-params` and raw network layer `:result`. If you want the post behavior to act as a top-level mutation, then prefer `post-mutation`. The action can also call `transact!`. - `fallback` - A mutation (symbol) to run if there is a server/network error. The `env` of the fallback will be like a mutation `env`, and will include a `:result` key with the real result from the server, along with the original `:load-params`. Special-purpose config options: The config options can also include the following things that completely override behaviors of other (respons-processing) options, and should only be used in very advanced situations where you know what you are doing: - `ok-action` - WARNING: OVERRIDES ALL DEFAULT OK BEHAVIOR (except load marker removal)! A lambda that will receive an env parameter `(fn [env] ...)` that includes the `:result` and original `:load-params`. - `error-action` - WARNING: OVERRIDES ALL DEFAULT ERROR BEHAVIOR (except load marker update). A lambda that will receive an `env` that includes the `:result` and original `:load-params`.
(load-failed! {:keys [app] :as env}
{:keys [error-action marker fallback] :as params})
The normal internal processing of a load that has failed (error returned true).
Sets the load marker, if present, to :failed.
If an error-action
was desired, it is used to process the rest of the failure.
The env
will include the network :result
and the original load options as :load-params
.
Otherwise, this function will:
The normal internal processing of a load that has failed (error returned true). Sets the load marker, if present, to :failed. If an `error-action` was desired, it is used to process the rest of the failure. The `env` will include the network `:result` and the original load options as `:load-params`. *Otherwise*, this function will: - Trigger the global error action (if defined on the app) (arg is env as described above) - Trigger any fallback for the load. (params are the env described above)
(load-field! component field-or-fields)
(load-field! component field-or-fields options)
Load a field of the current component. Runs prim/transact!
.
Parameters
component
: The component (instance, not class). This component MUST have an Ident.field
: A field on the component's query that you wish to load. If field
is a vector of keywords then
this function will load all of the fields specified.options
: A map of load options. See load
.WARNING: If you're using dynamic queries, you won't really know what factory your parent is using, nor can you pass it as a parameter to this function. Therefore, it is not recommended to use load-field from within a component that has a dynamic query unless you can base it on the original static query.
Load a field of the current component. Runs `prim/transact!`. Parameters - `component`: The component (**instance**, not class). This component MUST have an Ident. - `field`: A field on the component's query that you wish to load. If `field` is a *vector* of keywords then this function will load all of the fields specified. - `options` : A map of load options. See `load`. WARNING: If you're using dynamic queries, you won't really know what factory your parent is using, nor can you pass it as a parameter to this function. Therefore, it is not recommended to use load-field from within a component that has a dynamic query unless you can base it on the original static query.
(load-marker? x)
Is the given parameter a load marker?
Is the given parameter a load marker?
(load-params* app
server-property-or-ident
class-or-factory
{:keys [target params marker post-mutation post-mutation-params
without fallback focus ok-action post-action error-action
remote abort-id update-query]
:or {remote :remote marker false}})
Internal function to validate and process the parameters of load
and load-action
.
Internal function to validate and process the parameters of `load` and `load-action`.
(loading? marker)
Is the given load marker loading?
Is the given load marker loading?
The name of the table in which fulcro load markers are stored. You must query for this via a link query
[df/marker-table '_]
in any component that needs to use them (and refresh) during loads.
The name of the table in which fulcro load markers are stored. You must query for this via a link query `[df/marker-table '_]` in any component that needs to use them (and refresh) during loads.
(ready? marker)
Is the given load marker ready for loading?
Is the given load marker ready for loading?
(remove-load-marker! app marker)
Removes the load marker with the given marker
id from the df/marker-table.
Removes the load marker with the given `marker` id from the df/marker-table.
(set-load-marker! app marker status)
Adds a load marker at the given marker
id to df/marker-table with the given status.
NOTE: You must query for the marker table in any component that wants to show activity.
Adds a load marker at the given `marker` id to df/marker-table with the given status. NOTE: You must query for the marker table in any component that wants to show activity.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close