Introduction

Where we discuss why and what is Redux-optimum

What is Redux-optimum

Optimistic REST API calls are becoming a standard in the world of Single Page Applications but managing them is never easy. Where to place the data in the application, how to reconcile server data and client data, what to do during network failures, or how to manage identifiers (tokens in headers or session cookies)? All these questions need to be answered when dealing with a complex front-end application. Yet, there is no easy, nor a one shoe fits all, kind of solution. Nevertheless, why does it need to be so complex and defined at every call level when we can abstract those decisions in a centralized manner with standardized procedures. This is exactly the aim of this library. Of course, it does not cover all the edge-cases but it tries to abstract all the possible implementations for API management in a series of options. It is based on the existing Redux library and the middleware Redux-saga.

This is what Redux-optimum allows you to do:

• Make server calls while notifying the application of the different stages of the call (queue, begin, success or failure).

  • Imagine, you have most of the data you need from the client submission to print a new screen but still need an ID coming back from the server. Well, you can print immediately on screen and reconcile the coming data from the server when it gets to the client. If the call fails, you can revert back to the previous screen, you just have to update what the actions return and how your reducers act accordingly to get your store to reflect the appropriate data.

• Define what constitutes a call failure, or just a temporary outage.

  • Maybe the call returns 502s, as the server is overloaded. You don't want to be prevented from transiting to the next state of the application for so little. Maybe you need tell the queue manager of Redux-optimum to retry the call when you get 502s. With Redux-optimum, you can set, per API endpoints, what constitutes a failure and what is only a setback as well as how many times you want to retry the call.

• Queue up all requests if network is not available.

  • When the network is not available or when an API endpoint keeps failing, you can decide that all subsequent calls will be queued and retried later on.

• Automatic Authorization Token Refresh.

  • A call might return that the Authorization Token is expired. Obviously, you don't want to log out if you are in possession of a refresh token. Define your own methods and the token will be refreshed before retying the call.

• State Persistence on local storage.

  • Close your browser, open it back up, the store will be in the same state, API queues and all.

A config file is all you need to define all the behaviors for your API management system. One place to rule them all!