I have that talk bookmarked to watch, but my bookmarks queue is like 600+ deep at this point :) Just going by your summary: Yeah, I do find it interesting how

I have that talk bookmarked to watch, but my bookmarks queue is like 600+ deep at this point :) Just going by your summary: Yeah, I do find it interesting how some different parts of the community have chosen to format their action strings differently. Redux itself literally doesn't care, of course - the only requirement is that `action.type` not be undefined. As I said in "The Tao of Redux, Part 1: Implementation and Intent" [0], one of the main intents behind Redux is that the action log should be a literally readable history of what's going on in your app with semantic meaning behind each name. You _could_ have a single `"SET_DATA"` action, but that doesn't tell me anything about what's going on. The Redux docs originally went with the SCREAMING_SNAKE_CASE string format just because that's the common programming world convention for constant values. The naming in the docs also tends towards matching how you would name the action creator, ie, `"TOGGLE_TODO"` -> `toggleTodo()`. Those are perfectly legitimate choices to make, but definitely not the only possible ways to do it. I've seen plenty of other variations over the years, usually in the form of some "domain" string + the "event" name. For Redux Starter Kit, we've gone with a '/'-separated string, such as `"todos/addTodo"`. The end user is still supplying both parts (via the slice `name` field and the user-defined reducer function name). So, the Angular-ish convention of `"[Some Domain] Some Event"` is perfectly fine, and very readable. Either way, it doesn't matter what you actually name the _variable_ that points to that action type. One of the most interesting variations I've seen on this is Slack, which apparently uses entire _sentences_ as their action types, each including a unique numeric ID [1]. Finally, yes, we would generally recommend treating actions semantically as "events in the app", not "setters at a distance". Again, the Redux store itself doesn't care, but the "events" mental modeling promotes dispatching fewer total actions and having multiple reducers independently responding to a given action [2]. We'll emphasize this more in the upcoming docs revamp. Glad to know my writing has helped! Lemme know if you've got any other questions. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://twitter.com/erikras/status/1153350835738468363 https://twitter.com/erikras/status/1153350835738468363 [2] https://redux.js.org/faq/actions#is-there-always-a-one-to-one-mapping-between-reducers-and-actions https://redux.js.org/faq/actions#is-there-always-a-one-to-on...