Not the Author... that said, one advantage of using a reducer to respond to events is that you can process your logic as a pure function which is easier to test both state and changes. It also is better in terms of separating state management from render.
If course it's at the cost of a slightly more complex implementation and requires that separation of responsibilities in a clean way, which isn't always the case in practice.
It's part of why I've been such a fan of straight Redux for state management. It's easier to compare/contrast with a state checker system such as the original Angular where projects and implementations have tended to have many bugs related to state management in practice.
Much like tdd, it doesn't make the code cleaner or better, but does make it more painful to not do it cleanly.
Dexie.js definitely looks interresting as a client side abstraction.
Not sure on the dexie cloud... pricing may be fine for some use cases, but could get expensive for popular hobby sites, and tend to prefer self-host options myself. Relatively cool all the same.
While interesting, the main source is obfuscated/minified, and there's no link to anything that can serve as a point of informational reference in terms of this site's main topic (JavaScript).
Generally, not a huge fan of templates for node, this is far more ready than most. One change I would suggest is adding a test coverage requirement to the jest config, then maybe adding git action(s) preventing merge for PRs that don't meet the coverage requirement, and maybe another upping the coverage config to the new level when it's raised.
As a carnivore, I find the messaging offensive.
Don't mind the abstraction over Redux too offensive, though one might consider making this (or something similar) work along with redux-micro-frontend [1].
1. https://www.npmjs.com/package/redux-micro-frontend