Redux middleware logging basics

logs gone wild

I have written previously about REDUX and some of its features, if you are interested in a more general introduction, please check out the post below.

An Introduction to Redux_Modern data-flow patterns_medium.com

Implementing this FLUX-style architecture has many benefits(if done correctly), but the impact that it has on logging, crash and error reporting is often overlooked.

If you have ever worked on, or better yet attempted to troubleshoot a complex web application with complicated data-models, eventing and work flows, you are familiar with the irreproducible bug. Wouldn’t it be great to be able to go back and look at the exact state of the application at the time of the crash and even the actions that led up to the crash? Let’s look at how we might accomplish this.

A traditional console.log() may look something like this:

Above you see a single console.log() line, there is nothing dynamic going on here. You would have to spread these things all over your application to catch your store at different phases of change. When you are working on larger apps however, there are advantages to having a single definition point. Let’s see how that may look:

You can see above that we have combined 3 middleware:

• Our new custom logger
• Redux Thunk for handling asynch calls
• RouterMiddleware that captures and redirects actions to your history

You can combine middleware and they have no need to know about the ‘ware that proceeds or follows them. We wrap the store dispatch method(s) in order to achieve our desired results/functionality.

The moment between the Action and the Reducer is a critical exchange and using middleware to cleanly log state can improve the overall quality of your app.

Further Reading and resources:

• Redux middleware docs
• Redux production logging

Let me know your thoughts on twitter. Keep after it.

If you like this article, please recommend it to help others find it!