Query
Representation of a piece of remote data.
Rule of thumb:
- some piece of data is stored in a remote location (like a server)
- its local representation can be be easily deleted and re-fetched from the remote location
So, it is a good candidate for a Query.
Commands
This section describes the Event that can be used to perform actions on the Query. Commands should be called in application code.
start
Unconditionally starts the Query with the given parameters.
refresh since v0.8
Starts the Query with the given parameters if it is $stale. Otherwise, it will be treated as skipped.
reset since v0.2
Resets the Query to the initial state.
Stores
This section describes the Stores that can be used to read the Query state.
$data
Store with the latest data. It must not be changed directly. In case of error, it will contain the initial data.
$error
Store with the latest error. It must not be changed directly. In case of success, it will contain null.
$status
Store with the current status of the Query. It must not be changed directly. Can be one of the following values: "initial", "pending", "done", "fail".
For convenience, there are also the following Stores:
$idlesince v0.8 —trueif the Query is in the"initial"state,falseotherwise.$pending—trueif the Query is in the"pending"state,falseotherwise.$failedsince v0.2 —trueif the Query is in the"fail"state,falseotherwise.$succeededsince v0.2 —trueif the Query is in the"done"state,falseotherwise.$finishedsince v0.9 —trueif the Query is in the"done"or"fail"state,falseotherwise.
$enabled
Store with the current enabled state of the Query. Disabled queries will not be executed, instead, they will be treated as skipped. It must not be changed directly. Can be true or false.
$stale
Store with the current stale state of the Query. Stale queries will be executed on the next call to refresh Event. It must not be changed directly. Can be true or false.
Events
This section describes the Event that can be used to listen to the Query state changes. Events must not be called in application code.
finished.success
Event that will be triggered when the Query is finished with success. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Queryresultwith the result of the Querymetawith the execution metadata
finished.failure
Event that will be triggered when the Query is finished with failure. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Queryerrorwith the error of the Querymetawith the execution metadata
finished.skip
Event that will be triggered when the Query is skipped. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Querymetawith the execution metadata
finished.finally
Event that will be triggered when the Query is finished with success, failure or skip. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Querymetawith the execution metadatastatussince v0.9 with a string"done","fail"or"skip"for success, failure or skip respectivelyresultsince v0.9 if thestatusis"done"with the result of the Queryerrorsince v0.9 if thestatusis"fail"with the error of the Query
aborted since v0.9
Event that will be triggered when the Query is aborted. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Querymetawith the execution metadata
INFO
Aborted Queries are not treated as failed v0.10. This means that .finished.failure will not be triggered in case of abortion.
started since v0.9
Event that will be triggered when the Query is started. Payload will contain the object with the following fields:
paramswith the parameters that were used to start the Querymetawith the execution metadata