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.
The first part will be the actions allowed in my reducer.
isFetching
to true
for any kind of user notification of an async process.The action creators are the functions that will get dispatched over the lifecycle of the async action.
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.
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).
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