I maintain Redux, and I don't think Redux inspired this particular term usage (which came from the "Flux Architecture" pattern.)

As far as I know this usage ultimately derives from HTML `<form action={}>`.

Ah, different “action”, then? The presence of “reducer” had me assuming the action was also analogous.

FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)

Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?).

And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology":

- https://github.com/reduxjs/redux/issues/891#issuecomment-147...

FWIW, as I've revamped the Redux docs over the years, I have specifically made sure we describe the "actions === events" aspect:

- https://redux.js.org/style-guide/#model-actions-as-events-no...

- https://redux.js.org/tutorials/essentials/part-1-overview-co...

That’s great—my experience is years out of date, so my gripes may well be obsolete :-)

Thanks for the work on a project that I got good use out of, and happen to personally like more than I do most software.

Redux is the most over-engineered invention/perception in the history of software development.