> the "function parameter" approach you're describing is just not how Redux works That's not how redux works internally, and it makes all the sense in the worl

> the "function parameter" approach you're describing is just not how Redux works That's not how redux works internally, and it makes all the sense in the world. My wish is to keep these details buried and not leak into the coding style used by the app. The logic in my function wants two arguments, the fact that those two arguments have been packed into an action (and into a field named 'payload') to work with the redux flow of dispatching & etc is not something that anything in the logic or body of my function needs to know. It is necessary because of how redux works, but everything in the kit is about adding glue between app code and redux, reducing the verbosity and presence of redux internals in app code, so this sounds like a natural way to continue that trend. If I was working with React these days I'd surely set out some time to try and extend the kit in those directions. A few years ago (shortly after redux was first released) I gave it a shot, but there were too many pieces to build. The kit does a great job lifting a lot of newly developed packages like immer.