Users double-click accidentally, ride the keyboard… one of the most elementary things you can do is throttle server requests for a specific call. Here’s my initial recipe. As a note, while my redux store is still fairly boilerplate heavy, I use redux-starter-kit to improve readability and lessen the pain of getting going.
First, a little something to save us the trouble of repetitive work:
For each api call, we’re going to assume that the call has three stages to take note of in our redux actions:
- request sent
- response received — successfully!
- response received — failure condition :/
We’re going to use the propsByActionType method to generate three properties for each of those situations:
- isFetching
- receivedAt
- success
And from there, we can determine whether an additional call to the same api is ready to fetch.
Before we wire up any api call, let’s look at what a redux store might look like
Notice I threw a little action in there to invalidate/reset that portion of the store as well.
Just to be tidy, here’s what the redux store might look like:
I implement the sent/success/fail/reset actions fairly consistently for api conversations that go to our redux store. It would be possible to further reduce boilerplate by using a different library or creating my own factory to generate these. But to be honest, at that level of abstraction I think my coworkers would be beyond exasperted. Verbose code can serve a storytelling purpose.
Anyway, here’s a very simple example of an async wrapper around an XHR calls (left to your imagination) that uses these actions:
Leave a Reply