A few points to mention:
1. I feel that redux-thunk with async functions are good enough for 98% of async needs... saga and others are just so much overhead and boilerplate to work with.
2. Look at mterial-ui (which uses React-JSS for styles), it's a pretty nice set of tools to work with on that side.
3. I find Redux easier to work with when things get more complicated, you can break things up and combine them as you need.
4. connected-react-router will tie into redux a bit better... you can also write your own redux plugin to deconstruct querystring parameters and append the data in response to your connected router.
5. Writing middleware for redux can fill a lot of gaps, ymmv of course.
It's an idea I had a couple years ago and finally took the time to do... saves around 200kb on a bundle payload if zxcvbn isn't actually used on a screen. Loads asynchronously if/when needed.
-1 for me... extremely simplistic example using request and cheerio modules seen time and again. What would be better would perhaps be an accompanying article surrounding what this project is trying to accomplish and why it was put together. As is, another throwaway repository on github.
I prefer angular-redux, as it feels like the effects are just a lot more overhead as opposed to say async action creators in a service with redux. I know the reasons why, but I absolutely prefer a more unidirectional event/data flow that I get with Redux, even in Angular.
Nothing really applies to angular. If you're developin your app separate from the api, your ouput will probably be straight JS.
If your app is deplying to doker, cool... otherwise you kind of loose the `npm ci` advantages. In the end it's more of an okay primer for docker than angular's use imho.
I like tests flattened into the same directory MyControl.test.js or .spec.js
Also, instead of a package.json, add an index.js re-exports the specific named control.js file... The practice in use may cause complications with build systems or future mjs references.