On Friday, May 4, 2018, I finally decided to take a deep dive into Redux. Redux is an application state manager, and is basically a tiny core JavaScript library that is meant to be used with certain idiomatic practices that make it easier to reason about application state changes. A commonly stated goal it achieves is separating "what happened" from "how the state changes".

Having used React for a couple of years by now, I have of course heard about Redux, it being the most popular tool for state management besides having no tool at all. However, I have put off learning it (wisely, I think) because, until now, most of the things I've used React in don't qualify as huge applications - they are simple enough where React's basic state + props approach is good enough without worrying about an enforced pattern for changing state based on user actions. Now, however, having seen some pain points as small projects start to get more complex, I want to see how everybody else is best solving this problem.

https://stateofjs.com's 2017 survey results for state management, as seen here put Redux near the top, apart from using Rest API. I lost the blog article, but comparing the different options, Redux doesn't not assuming a web server being the source of truth, unlike some other tools. Mobx was another strong contender in my mind, proposing to be easier to use, but perhaps the right combination of blog articles I've read steered me to look deep into Redux first. Redux also seems to have nailed down making minimal extensible APIs that encourage the explosion of related libraries and plugins that the Redux project has seen growing around it, which appears to result in best-of-class community-created solutions for many different aspects of the general problem that Redux attacks.

After doing multiple Google searches and reading a few articles, I found my 2 favorite pages so far that explain the purpose of Redux and how to architect an application using it. They are: Idiomatic Redux: The Tao of Redux Part 1 - Implementation and Intent, and Part 2 - Practice and Philosophy. I can imagine that everybody wanting to learn how to use Redux should read those articles. The wide range of links at the end also seem to promise a wealth of knowledge about best practices, different approaches and the tradeoffs involved.

I do believe that Mobx deserves to be looked at, mainly because of its Reactive Programming approach, compared to Redux's Functional Programming philosophies. It seems abundantly clear in my mind that both are generally superior to Object Oriented Programming, in most of our common problems that we as programmers solve, though Object Oriented Programming might be better in some specific cases. What is more unclear to me is whether Reactive Programming's observables are superior to one-way data flow and updates of immutable state. Observables do remind me a lot of Angular.js, which I and my team have had bad experiences with, but I can see how there's something really mathematically beautiful about observables being analogous to iterables, replacing sequences-in-place with sequences-in-time. In summary, Mobx represents an approach that I'm sure I haven't finished researching, but for now, I pick Redux as the one with the largest most active community.

My next steps will be to investigate more projects that use Redux in practice, and start experimenting with it on my own. Since the Redux project is structured with extensibility in mind, there's quite a bundle of other projects I expect to learn to get full use out of this library. And so I'll begin, slowly but thoroughly.