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.
There are two ways to track CRUD operation requests in Redux Resource: using a request object, or tracking the status on resource metadata.
Typically, you should use request objects, but in some situations you may prefer to use resource metadata instead.

Request objects

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 learn about the shape of request objects, refer to the request objects guide.
To dispatch actions that create request objects, you need to supply a requestKey to with your request actions. For instance,
1
{
2
type: actionTypes.READ_RESOURCES_PENDING,
3
resourceType: 'books',
4
requestKey: 'searchBooks'
5
}
Copied!
This will update your resource slice to look like the following:
1
{
2
resourceType: 'books',
3
requests: {
4
searchBooks: {
5
requestKey: 'searchBooks',
6
status: 'PENDING'
7
}
8
}
9
}
Copied!
For more on request actions, refer to the request actions guide.

Resource Metadata

In a limited number of situations, you may not need to specify a requestKey with 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 resources array 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:
1
{
2
type: actionTypes.READ_RESOURCES_PENDING,
3
resourceType: 'books',
4
resources: [24]
5
}
Copied!
When this is dispatched, your slice's metadata will be updated like this:
1
{
2
meta: {
3
24: {
4
createStatus: 'IDLE',
5
readStatus: 'PENDING',
6
updateStatus: 'IDLE',
7
deleteStatus: 'IDLE'
8
}
9
}
10
}
Copied!
In your view layer, you can then use getStatus to access this state in a convenient way.
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.

Using Statuses

You now know how to store the request statuses in your store. There is a separate guide on Using Request Statuses in your view layer.