Having been through the two Dan’s Redux Egghead tutorial, lived in React / Redux development for month (been in Backbone, AngularJS for years prior), and having robust conversations with colleagues on the topic, have the following comments on the use of Redux.

First, I strongly believe that Redux is transformative in much the same way that AJAX (back in 2005) transformed how web applications are built. In particular, both seek to create an API (in the case of Redux, internal to the browser application) that provides for a controlled and testable point in the overall application. As such, outside of the most trivial applications, I see value in paying the price of the “dreaded” boilerplate code.

Also, much like AJAX got REST, I see that Redux could stand for some code organization conventions to make creating boilerplate code quicker and make the API (the one exposed via the Redux action creators and accessors) more consistent (and thus readily guessable).

As a matter of fact, I have a fairly strong opinion on one such approach and that is to model the verbiage of REST itself, i.e., expose APIs (action creators) for GET (collection or element), POST, PUT, and DELETE (following REST naming and API signature conventions). Also, much like REST’s limitations, we need to expose more complex transactions, i.e,. updating multiple entities as a unit, as special purpose action creators that either match up with a matching server API transaction (or gets implemented in the action creator in the case of local state).

If any of this synchronized with you I have created a boilerplate (and somewhat rambling discussion in the README) that builds off of Dan Abramov’s Todos sample application and explains this approach.


Written by

Broad infrastructure, development, and soft-skill background

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store