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. _Modern data-flow patterns_medium.com An Introduction to Redux Implementing this -style architecture has many benefits(if done correctly), but the impact that it has on logging, crash and error reporting is often overlooked. FLUX 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. may look something like this: A traditional console.log() 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 Let’s see how that may look: single definition point. 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 . Keep after it. twitter If you like this article, please recommend it to help others find it!
