Preface

Redux is a curious little tool. As you’ll discover, there’s not all that much to it. You can familiarize yourself with each of its methods before you finish a cup of coffee.

Not only is Redux well-contained, but it’s also a finished product. How often do you hear that? There’s no roadmap, project manager, or Kanban board. Commits are still added to the GitHub repository, but they’re usually improvements to documentation or the official examples.

How’s that possible? You may find it helpful to think of Redux as an architecture pattern. The package you install from npm is an implementation of that pattern and it provides you with enough functionality to get your application off the ground.

The real kicker is how much you can accomplish with only those few methods. The stark truth is that the Redux pattern can completely untangle a JavaScript application, leaving behind something more predictable, intuitive, and performant. Thanks to the same pattern, the developer tools also provide unprecedented insight into an application’s state and the flow of data through it.

But what’s the catch? All software choices come with tradeoffs, and Redux is no exception. The cost is tremendous flexibility. That may sound like another advantage, but it presents interesting challenges. The Redux pattern isn’t strictly enforced by the library or any other tool, and the small package cannot hope to educate or guide the developer to use the pattern effectively itself.