CLJ HTTP remote for Fulcro. Mirrors the CLJS http-remote middleware API but uses an injected
HTTP driver function instead of Google Closure's XhrIo. This allows headless CLJ apps and tests
to communicate with a real Fulcro server over HTTP.
The :http-driver is a synchronous function with signature:
(fn [{:keys [url method headers body]}]
{:status int, :headers map, :body string, :error nil-or-exception})
IF you have http-kit on your CLASSPATH, you can use the com.fulcrologic.fulcro.networking.http-kit-driver.
The remote runs the driver on a future internally so it does not block the calling thread.
Pass :synchronous? true to fulcro-http-remote to skip the future and run the driver
on the calling thread (required for headless test apps that use synchronous tx processing).
CLJ HTTP remote for Fulcro. Mirrors the CLJS `http-remote` middleware API but uses an injected
HTTP driver function instead of Google Closure's XhrIo. This allows headless CLJ apps and tests
to communicate with a real Fulcro server over HTTP.
The `:http-driver` is a **synchronous** function with signature:
(fn [{:keys [url method headers body]}]
{:status int, :headers map, :body string, :error nil-or-exception})
IF you have http-kit on your CLASSPATH, you can use the `com.fulcrologic.fulcro.networking.http-kit-driver`.
The remote runs the driver on a future internally so it does not block the calling thread.
Pass `:synchronous? true` to `fulcro-http-remote` to skip the future and run the driver
on the calling thread (required for headless test apps that use synchronous tx processing).(error-routine* get-response ok-routine progress-routine raw-error-handler)Returns a (fn [xhrio-evt]) that pulls the progress and reports it to the progress routine and the raw error handler.
Returns a (fn [xhrio-evt]) that pulls the progress and reports it to the progress routine and the raw error handler.
(extract-response edn request driver-response)Convert a driver response map into a Fulcro response shape.
Convert a driver response map into a Fulcro response shape.
(extract-response tx request xhrio)Generate a response map from the status of the given xhrio object, which could be in a complete or error state.
Generate a response map from the status of the given xhrio object, which could be in a complete or error state.
(fulcro-http-remote {:keys [url http-driver request-middleware
response-middleware preprocess-error synchronous?]
:or {url "/api"
response-middleware (wrap-fulcro-response)
request-middleware (wrap-fulcro-request)
preprocess-error (fn [r] (merge r {:status-code 500}))
synchronous? false}
:as options})Create a CLJ remote that communicates over HTTP using an injected driver function.
The options map supports:
:url - The URL to contact (default "/api"):http-driver - (required) A synchronous function with signature
(fn [{:keys [url method headers body]}] {:status int :headers map :body string :error nil}):request-middleware - Middleware chain applied to outgoing requests (default (wrap-fulcro-request)):response-middleware - Middleware chain applied to incoming responses (default (wrap-fulcro-response)):preprocess-error - A (fn [result] result) applied before reporting errors (default adds :status-code 500):synchronous? - When true, runs the HTTP driver on the calling thread instead of a future.
Required for headless test apps that use synchronous tx processing (default false).Create a CLJ remote that communicates over HTTP using an injected driver function.
The `options` map supports:
* `:url` - The URL to contact (default `"/api"`)
* `:http-driver` - **(required)** A synchronous function with signature
`(fn [{:keys [url method headers body]}] {:status int :headers map :body string :error nil})`
* `:request-middleware` - Middleware chain applied to outgoing requests (default `(wrap-fulcro-request)`)
* `:response-middleware` - Middleware chain applied to incoming responses (default `(wrap-fulcro-response)`)
* `:preprocess-error` - A `(fn [result] result)` applied before reporting errors (default adds `:status-code 500`)
* `:synchronous?` - When `true`, runs the HTTP driver on the calling thread instead of a future.
Required for headless test apps that use synchronous tx processing (default `false`).(fulcro-http-remote {:keys [url request-middleware response-middleware
make-xhrio preprocess-error]
:or {url "/api"
response-middleware (wrap-fulcro-response)
request-middleware (wrap-fulcro-request)
preprocess-error (fn [r] (merge r {:status-code 500}))
make-xhrio make-xhrio}
:as options})Create a remote that (by default) communicates with the given url (which defaults to /api).
The options map can contain:
:url - The URL to contact:request-middleware - See below:response-middleware - See below:make-xhrio - A constructor function to build a goog.net.XhrIo object, initialized however you see fit.:preprocess-error - A (fn [xhrio-result] fulcro-result). Defaults to #(merge % {:status-code 500}).The request middleware is a (fn [request] modified-request). The request will have :url, :body, :method, and :headers. The
request middleware defaults to wrap-fulcro-request (which encodes the request in transit+json). The result of this
middleware chain on the outgoing request becomes the real outgoing request. It is allowed to modify the url.
If the the request middleware returns a corrupt request or throws an exception then the remote code
will immediately abort the request. The return value of the middleware will be used to generate a request to :url,
with :method (e.g. :post), and the given headers. The body will be sent as-is without further translation.
response-middleware is a function that returns a function (fn [response] mod-response) and
defaults to wrap-fulcro-response which decodes the raw response and transforms it back to a response that Fulcro can merge.
The response will be a map containing the :outgoing-request which is the exact request sent on the network; :body, which
is the raw data of the response. Additionally, there will be one or more of the following to indicate low-level
details of the result: :status-code, :status-text, :error-code (one of :none, :exception, :http-error, :abort, or :timeout),
and :error-text. Middleware is allowed to morph any of this to suit its needs.
DEPRECATED: If the response middleware includes a :transaction key in the response with EQL, then that EQL will be
used in the resulting Fulcro merge steps. This can seriously screw up built-in behaviors. You are much better off ensuring
that your query matches the shape of the desired response in most cases.
The definition of remote-error? in the application will deterimine if happy-path or error handling will
be applied to the response. The default setting in Fulcro will cause
a result with a 200 status code to cause whatever happy-path logic is configured for that specific
response's processing.
For example, see m/default-result-action! for mutations, and df/internal-load for loads. The :body key
will be considered the response to use, and the optional :transaction key an override to the EQL query used
for any merges.
See the top-level application configuration and Developer's Guide for more details.
Create a remote that (by default) communicates with the given url (which defaults to `/api`).
The options map can contain:
* `:url` - The URL to contact
* `:request-middleware` - See below
* `:response-middleware` - See below
* `:make-xhrio` - A constructor function to build a goog.net.XhrIo object, initialized however you see fit.
* `:preprocess-error` - A `(fn [xhrio-result] fulcro-result)`. Defaults to #(merge % {:status-code 500}).
The request middleware is a `(fn [request] modified-request)`. The `request` will have `:url`, `:body`, `:method`, and `:headers`. The
request middleware defaults to `wrap-fulcro-request` (which encodes the request in transit+json). The result of this
middleware chain on the outgoing request becomes the real outgoing request. It is allowed to modify the `url`.
If the the request middleware returns a corrupt request or throws an exception then the remote code
will immediately abort the request. The return value of the middleware will be used to generate a request to `:url`,
with `:method` (e.g. :post), and the given headers. The body will be sent as-is without further translation.
`response-middleware` is a function that returns a function `(fn [response] mod-response)` and
defaults to `wrap-fulcro-response` which decodes the raw response and transforms it back to a response that Fulcro can merge.
The response will be a map containing the `:outgoing-request` which is the exact request sent on the network; `:body`, which
is the raw data of the response. Additionally, there will be one or more of the following to indicate low-level
details of the result: `:status-code`, `:status-text`, `:error-code` (one of :none, :exception, :http-error, :abort, or :timeout),
and `:error-text`. Middleware is allowed to morph any of this to suit its needs.
DEPRECATED: If the response middleware includes a `:transaction` key in the response with EQL, then that EQL will be
used in the resulting Fulcro merge steps. This can seriously screw up built-in behaviors. You are much better off ensuring
that your query matches the shape of the desired response in most cases.
The definition of `remote-error?` in the application will deterimine if happy-path or error handling will
be applied to the response. The default setting in Fulcro will cause
a result with a 200 status code to cause whatever happy-path logic is configured for that specific
response's processing.
For example, see `m/default-result-action!` for mutations, and `df/internal-load` for loads. The `:body` key
will be considered the response to use, and the optional `:transaction` key an override to the EQL query used
for any merges.
See the top-level application configuration and Developer's Guide for more details.(ok-routine* progress-routine get-response-fn raw-ok-handler error-routine)Returns a (fn [evt] ) that pulls the response, runs it through middleware, and reports the appropriate results to the raw-ok-handler, and progress-routine. If the middleware fails, it will instaed report to the error-routine (which in turn will report to the raw error handler)
Returns a (fn [evt] ) that pulls the response, runs it through middleware, and reports the appropriate results to the raw-ok-handler, and progress-routine. If the middleware fails, it will instaed report to the error-routine (which in turn will report to the raw error handler)
(overall-progress mutation-env)Returns a number between 0 and 100 for the overall progress. Use in a progress-action
section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the overall progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the overall progress. Use in a progress-action section of your mutation
when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the overall progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
(progress% progress)(progress% progress phase)Takes the progress report from the progress network event
and returns a number between 0 and 100. phase can be :overall, :sending, or :receiving. When
set to :overall then the send phase will count for progress points between 0 and 49, and receiving phase
will account for 50 to 100. When set to :sending or :receiving the entire range will count for that phase only
(i.e. once sending is complete this function would return 100 throughout the receiving phase.)
If total is unknown, then this function returns 0.
Takes the progress report from the progress network event and returns a number between 0 and 100. `phase` can be `:overall`, `:sending`, or `:receiving`. When set to `:overall` then the send phase will count for progress points between 0 and 49, and receiving phase will account for 50 to 100. When set to :sending or :receiving the entire range will count for that phase only (i.e. once sending is complete this function would return 100 throughout the receiving phase.) If total is unknown, then this function returns 0.
(progress-routine* get-response-fn raw-update-fn)Return a (fn [phase progress-event]) that calls the raw update function with progress and response data merged together as a response.
Return a (fn [phase progress-event]) that calls the raw update function with progress and response data merged together as a response.
(receive-progress mutation-env)Returns a number between 0 and 100 for the receive progress. Use in a progress-action
section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the receive progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the receive progress. Use in a progress-action section of your mutation
when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the receive progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
(send-progress mutation-env)Returns a number between 0 and 100 for the send progress. Use in a progress-action
section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the send progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the send progress. Use in a progress-action section of your mutation
when using the http-remote to monitor network progress.
Returns a number between 0 and 100 for the send progress. Use in a `progress-action` section of your mutation when using the http-remote to monitor network progress.
(was-network-error? {:keys [status-code error]})Returns true if the given response looks like a low-level network error.
Returns true if the given response looks like a low-level network error.
(wrap-csrf-token csrf-token)(wrap-csrf-token handler csrf-token)Client remote request middleware. Adds an X-CSRF-Token header to the request.
Client remote request middleware. Adds an X-CSRF-Token header to the request.
Client remote request middleware. This middleware can be added to add an X-CSRF-Token header to the request.
Client remote request middleware. This middleware can be added to add an X-CSRF-Token header to the request.
(wrap-fulcro-request)(wrap-fulcro-request handler)(wrap-fulcro-request handler addl-transit-handlers)(wrap-fulcro-request handler addl-transit-handlers transit-transformation)Client remote middleware to add transit encoding for Fulcro requests. Sets the content type and transforms an EDN body to a transit+json encoded body.
addl-transit-handlers is a map from data type to transit handler (the :handlers option of transit).
transit-transformation is a function of one argument returning a transformed transit value
(the :transform option of transit).
Client remote middleware to add transit encoding for Fulcro requests. Sets the content type and transforms an EDN body to a transit+json encoded body. `addl-transit-handlers` is a map from data type to transit handler (the `:handlers` option of transit). `transit-transformation` is a function of one argument returning a transformed transit value (the `:transform` option of transit).
Client Remote Middleware to add transit encoding for normal Fulcro requests. Sets the content type and transforms an EDN
body to a transit+json encoded body. addl-transit-handlers is a map from data type to transit handler (like
you would pass using the :handlers option of transit). The additional handlers are used to encode new data types
into transit. transit-transformation is a function of one argument returning a transformed transit value (like you
would pass using the :transform option of transit). See transit documentation for more details.
Client Remote Middleware to add transit encoding for normal Fulcro requests. Sets the content type and transforms an EDN body to a transit+json encoded body. addl-transit-handlers is a map from data type to transit handler (like you would pass using the `:handlers` option of transit). The additional handlers are used to encode new data types into transit. transit-transformation is a function of one argument returning a transformed transit value (like you would pass using the `:transform` option of transit). See transit documentation for more details.
(wrap-fulcro-response)(wrap-fulcro-response handler)(wrap-fulcro-response handler addl-transit-handlers)Client remote middleware to transform a network response to standard Fulcro form.
Decodes a transit response when the status code is 200 and the body is not empty. For errant status codes or empty body the response body becomes an empty map.
addl-transit-handlers is equivalent to the :handlers option in transit: a map from tag to handler.
Client remote middleware to transform a network response to standard Fulcro form. Decodes a transit response when the status code is 200 and the body is not empty. For errant status codes or empty body the response body becomes an empty map. `addl-transit-handlers` is equivalent to the `:handlers` option in transit: a map from tag to handler.
Client remote middleware to transform a network response to a standard Fulcro form.
This returns a function that will decode a transit response iff the resulting status code is 200 and the body is not empty. For errant status codes and empty body: the response body will become an empty map.
No arguments: Returns a function that can process responses, that is not further chained.
handler: If supplied, the result of this transformation will be passed through the handler.
addl-transit-handlers is equivalent to the :handlers option in transit: a map from data type to handler.
Client remote middleware to transform a network response to a standard Fulcro form. This returns a function that will decode a transit response iff the resulting status code is 200 and the body is not empty. For errant status codes and empty body: the response body will become an empty map. No arguments: Returns a function that can process responses, that is not further chained. handler: If supplied, the result of this transformation will be passed through the `handler`. addl-transit-handlers is equivalent to the :handlers option in transit: a map from data type to handler.
(xhrio-progress event)Given an xhrio progress event, returns a map with keys :loaded and :total, where loaded is the number of bytes transferred in the given phase (upload/download) and total is the total number of bytes to transfer (if known).
Given an xhrio progress event, returns a map with keys :loaded and :total, where loaded is the number of bytes transferred in the given phase (upload/download) and total is the total number of bytes to transfer (if known).
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |