Redux Resource
  • Home
  • Introduction
    • Motivation
    • Core Concepts
    • Similar Projects
    • Examples
  • Resources
    • Resource Reducers
    • Resource Objects
    • Meta
    • Lists
    • Modifying Resources
  • Requests
    • Request Objects
    • Keys
    • Names
    • Statuses
    • Request Actions
      • Updating Lists
      • Reading Resources
      • Updating Resources
      • Creating Resources
      • Deleting Resources
  • Other Guides
    • Usage With React
    • Tracking Request Statuses
    • Using Request Statuses
    • Custom Action Types
    • Migration Guides
  • Recipes
    • Forms
    • Canceling Requests
    • Unauthorized Responses
    • User Feedback
    • Related Resources
    • Caching
  • Ecosystem Extras
    • Redux Resource Action Creators
    • Redux Resource XHR
    • Redux Resource Prop Types
    • Redux Resource Plugins
      • HTTP Status Codes
      • Selection
      • Reset
      • Included Resources
  • FAQ
    • General
    • State Tree
    • Actions
    • Lists
  • API Reference
    • resourceReducer
    • getStatus
    • getResources
    • upsertResources
    • setResourceMeta
    • actionTypes
    • requestStatuses
Powered by GitBook
On this page
  • Request objects
  • Resource Metadata
  • Using Statuses
  1. Other Guides

Tracking Request Statuses

PreviousUsage With ReactNextUsing Request Statuses

Last updated 5 years ago

Displaying feedback about CRUD operations requires knowing the 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 , 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 .

To dispatch actions that create request objects, you need to supply a requestKey to with your request actions. For instance,

{
  type: actionTypes.READ_RESOURCES_PENDING,
  resourceType: 'books',
  requestKey: 'searchBooks'
}

This will update your resource slice to look like the following:

{
  resourceType: 'books',
  requests: {
    searchBooks: {
      requestKey: 'searchBooks',
      status: 'PENDING'
    }
  }
}

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:

{
  type: actionTypes.READ_RESOURCES_PENDING,
  resourceType: 'books',
  resources: [24]
}

When this is dispatched, your slice's metadata will be updated like this:

{
  meta: {
    24: {
      createStatus: 'IDLE',
      readStatus: 'PENDING',
      updateStatus: 'IDLE',
      deleteStatus: 'IDLE'
    }
  }
}

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

For more on request actions, refer to the .

In your view layer, you can then use to access this state in a convenient way.

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

status
request object
the request objects guide
request actions guide
getStatus
Using Request Statuses