Comment on page
Tracking Request Statuses
Displaying feedback about CRUD operations requires knowing the status of its request: is it pending, failing, succeeded? This is what we mean by "tracking" a request. The status of a request can be used to display feedback to the user of your application, such as showing loading indicators or error messages.
Typically, you should use request objects, but in some situations you may prefer to use resource metadata instead.
You can use request objects to track any request that your application makes. Request objects are by far the more powerful of the two options for tracking requests, so we recommend using them whenever possible.
To dispatch actions that create request objects, you need to supply a
requestKeyto with your request actions. For instance,
This will update your resource slice to look like the following:
In a limited number of situations, you may not need to specify a
requestKeywith your request actions.
This is true whenever your CRUD operations directly target a resource, or a set of resources, by their ID. For instance, if the user is fetching a book with ID 23, then this action is directly targeting the book with ID of 23. Likewise, deleting books with IDs 100, 101, and 102 is a request that is targeting these three resources directly.
Any time that you have a set of IDs when the request is sent off, then you can track the status of the operation on the resource metadata directly. You can do this by passing a
resourcesarray with the start action.
Let's look at an example. The action that represents beginning a read request of a book with ID 24 looks like the following:
When this is dispatched, your slice's metadata will be updated like this:
The rule of thumb is:
You can track CRUD operation requests on resource metadata anytime you have an ID when you fire the "start" action type.
Although using request objects is optional, we encourage their use because they provide consistency across your code base. Request objects allow you to track the status of every request, whereas resource metadata only works in a subset of situations.