Thanks for the perspective. :)

IMO the only downside to your approach is that it couples your action creators to the calling component. That isn't necessarily a bad thing but it all depends on what your particular goals are. If you intend to have your action creators as a kind of "super prop" that is specific to your caller and disposable and single purpose in nature, I think that works. To be successful (again IMHO) you'd want to segregate your business logic outside of that layer into either the reducer (as the redux team recommends) or in a service layer that the actions can talk to (my preferred approach). As always YMMV.

Oh, the results are handled by the reducer... it's not that far off.. expecting an event with a given shape, as opposed to a direct argument. Can even be split, one for the view specifically another for the more pure actioncreator... with the thunks+async function, it's easy to have a start, await api call and finish/error events dispatched.

Yep! :) Sounds like you've thought it through and I see your point.