paint-brush
Redux Patterns: Caching an API Responseby@justintulk
24,490 reads
24,490 reads

Redux Patterns: Caching an API Response

by Justin TulkJuly 12th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I’m currently experimenting with <a href="https://www.contentful.com/" target="_blank">Contentful</a> as a service to provide data that can be edited and updated without triggering a whole new testing/deployment cycle. Since I’m syndicating my Redux store to local storage, I’m trying to figure out a pattern where I don’t re-request this data more than every [x], where [x] could be a time limit anywhere from milliseconds to days.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Redux Patterns: Caching an API Response
Justin Tulk HackerNoon profile picture

Avoid Duplicating Calls for Stable Data

I’m currently experimenting with Contentful as a service to provide data that can be edited and updated without triggering a whole new testing/deployment cycle. Since I’m syndicating my Redux store to local storage, I’m trying to figure out a pattern where I don’t re-request this data more than every [x], where [x] could be a time limit anywhere from milliseconds to days.

For the purposes of this example I’m using Redux-Thunk to allow me to do async actions.

Actions

The first part will be the actions allowed in my reducer.

  • Abort: the action we’ll run if the cache is “fresh”
  • Error: store the error for whatever use required (this action could be a hook to connect external logging)
  • Start: Set isFetching to true for any kind of user notification of an async process.
  • Update: Set the returned data as the value.

Synchronous Action Creators

The action creators are the functions that will get dispatched over the lifecycle of the async action.

Async Action Creator

This is the function that will get exported to a component and called from a lifecycle hook wherever the fetch needs to be initiated. The internal actions will get dispatched in sequence over the lifecycle of the async call.

Reducer and InitialState

The reducer handles all the synchronous actions dispatched over the lifecycle of the async function, as well as handling setting the isFetching and lastFetched values. You could easily move that bit of logic to the action creators and avoid having any side effects in your reducer (pure function).

Conclusion

There you have it. Assuming you’re syndicating your Redux store to local storage, you can avoid a bunch of unnecessary API requests If you’ve got a better pattern (or know a library that solves this problem more elegantly) leave me a comment.

I know for a fact there’s a typo or two between the gists, but they don’t obscure the logic.


Redux Patterns: Rethinking `byId` and `byHash` Structures_Iterate with Object.keys() and drop byId_medium.com


Redux Patterns: Add/Edit/Remove Objects in an Array_I wrote a post the other day about how to implement a Redux-flavored store and reducer in a single React component…_medium.com


Implement Redux as Vanilla JS in a Single React Component_I’m currently working on a project where I’m patching a few React components piecemeal into an existing ASP.NET build…_medium.com