This refactor provides a redux-aware wrapper for all of our API calls and a reducer that stores our responses.
This sets the groundwork for retrying api requests #16 and for robust offline support.
The concept is a work in progress and I'm open to suggestions.
My goals are:
The services/api functionality remains intact -- that is, a single code block can be both the caller and the response/error handler using the usual promise interface
Caller and response/error handler can optionally be decoupled. An example would be if we have already called GET /users/me somewhere within the last 5 minutes, we don't need to call it again to show the user their profile. In the case of this example, we have the user reducer that does this for us. But the point of this is to have generic caching on http responses so that we don't have to write a new reducer for every type of response we want to share between components.
Failed requests can optionally be retried automatically even if the caller is no longer in the hierarchy. Ideally, the caller would be able to specify a number of retries and a backoff strategy. Then a provider of some sort would periodically go through the queue of api requests and retry the failed ones. Because of point 2, any components awaiting response/error/loading information from this request would still work, regardless of the status of the original caller component.
Lemme know what you think, and branch off this if you're doing any work involving containers.
Oh also looks like you'll need to merge neil.bugfixes before this one so that you can get a clean view of the changes. And there's no gif because there are 0 user facing changes
This refactor provides a redux-aware wrapper for all of our API calls and a reducer that stores our responses.
This sets the groundwork for retrying api requests #16 and for robust offline support.
The concept is a work in progress and I'm open to suggestions.
My goals are:
The
services/api
functionality remains intact -- that is, a single code block can be both the caller and the response/error handler using the usual promise interfaceCaller and response/error handler can optionally be decoupled. An example would be if we have already called
GET /users/me
somewhere within the last 5 minutes, we don't need to call it again to show the user their profile. In the case of this example, we have theuser
reducer that does this for us. But the point of this is to have generic caching on http responses so that we don't have to write a new reducer for every type of response we want to share between components.Failed requests can optionally be retried automatically even if the caller is no longer in the hierarchy. Ideally, the caller would be able to specify a number of retries and a backoff strategy. Then a provider of some sort would periodically go through the queue of api requests and retry the failed ones. Because of point 2, any components awaiting response/error/loading information from this request would still work, regardless of the status of the original caller component.
Lemme know what you think, and branch off this if you're doing any work involving containers.