fulcro.client.impl.application
-enqueueclj/s
(-enqueue q v)Enqueue a send to the network queue. This is a standalone function because we cannot mock core async functions.
Enqueue a send to the network queue. This is a standalone function because we cannot mock core async functions.
-send-payloadclj/s
(-send-payload network reconciler payload send-complete)Sends a network payload. There are two kinds of payloads in Fulcro. The first is for reads, which are tracked by load descriptors in the app state. These load descriptors tell the plumbing how to handle the response, and expect to only be merged in once. Mutations do not have a payload, and can technically receive progress updates from the network. The built-in networking does not (currently) give progress events, but plugin networking can. It is currently not supported to give an update on a load, so this function is careful to detect that a payload is a send and turns all but the last update into a no-op. The send-complete function comes from the network sequential processing loop, and when called unblocks the network processing to allow the next request to go. Be very careful with this code, as bugs will cause applications to stop responding to remote requests.
Sends a network payload. There are two kinds of payloads in Fulcro. The first is for reads, which are tracked by load descriptors in the app state. These load descriptors tell the plumbing how to handle the response, and expect to only be merged in once. Mutations do not have a payload, and can technically receive progress updates from the network. The built-in networking does not (currently) give progress events, but plugin networking can. It is currently not supported to give an update on a load, so this function is careful to detect that a payload is a send and turns all but the last update into a no-op. The send-complete function comes from the network sequential processing loop, and when called unblocks the network processing to allow the next request to go. Be very careful with this code, as bugs will cause applications to stop responding to remote requests.
enqueue-mutationsclj/s
(enqueue-mutations {:keys [reconciler send-queues] :as app} remote-tx-map cb)Splits out the (remote) mutations and fallbacks in a transaction, creates an error handler that can trigger fallbacks, and enqueues the remote mutations on the network queue. If duplicate mutation names appear, then they will be separated into separate network requests.
NOTE: If the mutation in the tx has duplicates, then the same fallback will be used for the
resulting split tx. See split-mutations (which is used by this function to split dupes out of txes).
Splits out the (remote) mutations and fallbacks in a transaction, creates an error handler that can trigger fallbacks, and enqueues the remote mutations on the network queue. If duplicate mutation names appear, then they will be separated into separate network requests. NOTE: If the mutation in the tx has duplicates, then the same fallback will be used for the resulting split tx. See `split-mutations` (which is used by this function to split dupes out of txes).
enqueue-readsclj/s
(enqueue-reads {:keys [send-queues reconciler networking]})Finds any loads marked parallel and triggers real network requests immediately. Remaining loads
are pulled into a single fetch payload (combined into one query) and enqueued behind any prior mutations/reads that
were already requested in a prior UI/event cycle. Thus non-parallel reads are processed in clusters grouped due to UI
events (a single event might trigger many reads which will all go to the server as a single combined request).
Further UI events that trigger remote interaction will end up waiting until prior network request(s) are complete.
This ensures that default reasoning is simple and sequential in the face of optimistic UI updates (real network traffic characteristics could cause out of order processing, and you would not want a 'create list' to be processed on the server after an 'add an item to the list').
Finds any loads marked `parallel` and triggers real network requests immediately. Remaining loads are pulled into a single fetch payload (combined into one query) and enqueued behind any prior mutations/reads that were already requested in a prior UI/event cycle. Thus non-parallel reads are processed in clusters grouped due to UI events (a single event might trigger many reads which will all go to the server as a single combined request). Further UI events that trigger remote interaction will end up waiting until prior network request(s) are complete. This ensures that default reasoning is simple and sequential in the face of optimistic UI updates (real network traffic characteristics could cause out of order processing, and you would not want a 'create list' to be processed on the server *after* an 'add an item to the list').
fallback-handlerclj/s
(fallback-handler {:keys [reconciler]} query)This internal function is responsible for generating and returning a function that can accomplish calling the fallbacks that appear in an incoming transaction, which is in turn used by the error-handling logic of the plumbing.
This internal function is responsible for generating and returning a function that can accomplish calling the fallbacks that appear in an incoming transaction, which is in turn used by the error-handling logic of the plumbing.
generate-reconcilerclj/s
(generate-reconciler {:keys [send-queues mutation-merge] :as app}
initial-state
parser
{:keys [migrate] :as reconciler-options})The reconciler's send method calls FulcroApplication/server-send, which itself requires a reconciler with a send method already defined. This creates a catch-22 / circular dependency on the reconciler and :send field within the reconciler.
To resolve the issue, we def an atom pointing to the reconciler that the send method will deref each time it is called. This allows us to define the reconciler with a send method that, at the time of initialization, has an app that points to a nil reconciler. By the end of this function, the app's reconciler reference has been properly set.
The reconciler's send method calls FulcroApplication/server-send, which itself requires a reconciler with a send method already defined. This creates a catch-22 / circular dependency on the reconciler and :send field within the reconciler. To resolve the issue, we def an atom pointing to the reconciler that the send method will deref each time it is called. This allows us to define the reconciler with a send method that, at the time of initialization, has an app that points to a nil reconciler. By the end of this function, the app's reconciler reference has been properly set.
read-localclj/s
(read-local user-read {:keys [query target state ast] :as env} dkey params)Read function for the built-in parser.
*** NOTE: This function only runs when it is called without a target -- it is not triggered for remote reads. To
trigger a remote read, use the fulcro/data-fetch namespace. ***
If a user-read is supplied, it will be allowed to trigger remote reads. This is not recommended, as you
will probably have to augment the networking layer to get it to do what you mean. Use load instead. You have
been warned. Triggering remote reads is allowed, but discouraged and unsupported.
Returns the current locale when reading the :ui/locale keyword. Otherwise pulls data out of the app-state.
Read function for the built-in parser. *** NOTE: This function only runs when it is called without a target -- it is not triggered for remote reads. To trigger a remote read, use the `fulcro/data-fetch` namespace. *** If a user-read is supplied, *it will be allowed* to trigger remote reads. This is not recommended, as you will probably have to augment the networking layer to get it to do what you mean. Use `load` instead. You have been warned. Triggering remote reads is allowed, but discouraged and unsupported. Returns the current locale when reading the :ui/locale keyword. Otherwise pulls data out of the app-state.
real-sendclj/s
(real-send net {:keys [reconciler tx on-done on-error on-load abort-id]})(real-send net tx on-done on-error on-load)Do a properly-plumbed network send. This function recursively strips ui attributes from the tx and pushes the tx over the network. It installs the given on-load and on-error handlers to deal with the network response. DEPRECATED: If you're doing something really low-level with networking, use send-with-history-tracking.
Do a properly-plumbed network send. This function recursively strips ui attributes from the tx and pushes the tx over the network. It installs the given on-load and on-error handlers to deal with the network response. DEPRECATED: If you're doing something really low-level with networking, use send-with-history-tracking.
send-with-history-trackingclj/s
(send-with-history-tracking net
{:keys [reconciler payload tx on-done on-error
on-load]})(send-with-history-tracking payload net tx on-done on-error on-load)Does a real send but includes history activity tracking to prevent the gc of history that is related to active network requests. If you're doing something really low level in the networking, you want this over real-send.
Does a real send but includes history activity tracking to prevent the gc of history that is related to active network requests. If you're doing something really low level in the networking, you want this over real-send.
server-sendclj/s
(server-send app remote-tx-map merge-result-callback)Puts queries/mutations (and their corresponding callbacks) onto the send queue. The networking code will pull these off one at a time and send them through the real networking layer. Reads are guaranteed to follow writes.
Puts queries/mutations (and their corresponding callbacks) onto the send queue. The networking code will pull these off one at a time and send them through the real networking layer. Reads are guaranteed to *follow* writes.
split-mutationsclj/s
(split-mutations tx)Split a tx that contains mutations.
Examples: [(f) (g)] => [[(f) (g)]] [(f) (g) (f) (k)] => [[(f) (g)] [(f) (k)]] [(f) (g) (f) (k) (g)] => [[(f) (g)] [(f) (k) (g)]]
This function splits any mutation that uses the same dispatch symbol more than once (since returns from server go into a map, and that is the only way to get return values from both), and also when the mutations do not share abort IDs (so that mutations do not get grouped into a transaction that could cause them to get cancelled incorrectly).
Returns a sequence that contains one or more transactions.
Split a tx that contains mutations. Examples: [(f) (g)] => [[(f) (g)]] [(f) (g) (f) (k)] => [[(f) (g)] [(f) (k)]] [(f) (g) (f) (k) (g)] => [[(f) (g)] [(f) (k) (g)]] This function splits any mutation that uses the same dispatch symbol more than once (since returns from server go into a map, and that is the only way to get return values from both), and also when the mutations do not share abort IDs (so that mutations do not get grouped into a transaction that could cause them to get cancelled incorrectly). Returns a sequence that contains one or more transactions.
start-network-sequential-processingclj/s
(start-network-sequential-processing
{:keys [networking reconciler send-queues response-channels] :as app})Starts a async go loop that sends network requests on networking object's request queue. Gives the appearance of a separate networking 'thread' using core async.
Starts a async go loop that sends network requests on networking object's request queue. Gives the appearance of a separate networking 'thread' using core async.
write-entry-pointclj/s
(write-entry-point env k params)This is the entry point for writes. In general this is simply a call to the multi-method
defined by Fulcro (mutate); however, Fulcro supports the concept of a global post-mutate
function that will be called anytime the general mutate has an action that is desired. This
can be useful, for example, in cases where you have some post-processing that needs
to happen for a given (sub)set of mutations (that perhaps you did not define).
This is the entry point for writes. In general this is simply a call to the multi-method defined by Fulcro (mutate); however, Fulcro supports the concept of a global `post-mutate` function that will be called anytime the general mutate has an action that is desired. This can be useful, for example, in cases where you have some post-processing that needs to happen for a given (sub)set of mutations (that perhaps you did not define).
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close