4 ms·

To be fair, you can (and should—I really don't get the appeal of the typically-presented way of using Redux) do things very differently if you like. It's not ha

by ashark 9y ago

To be fair, you can (and should—I really don't get the appeal of the typically-presented way of using Redux) do things very differently if you like. It's not hard to group actionCreators (actions), actions (events/messages—Redux terminology is pointlessly n00b-hostile), and reducers, and even stick them somewhere closer to (in if you really want to) your views.

johnfn 9y ago
If there is one valid criticism of Redux, it is that the names for everything are obtuse and hard to understand.
- acemarke 9y ago
  For what it's worth, most of that comes directly from the Flux heritage. For example, the Flux docs at https://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html#actions-and-actioncreators https://facebook.github.io/react/blog/2014/07/30/flux-action... explicitly describe the terms "actions" and "action creators" . There was a lot of discussion and bikeshedding in the early Redux issues over whether to use terms like "events", "commands", or even "facts" instead, but Dan and Andrew opted to keep "actions" for consistency with Flux. (Really, a very large percentage of questions about "Why does Redux do $THING?" can be answered with "Because the Flux Architecture, or other existing Flux libs, did things that way first".) "Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.
  - johnfn 9y ago
    It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :) It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand. For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state". Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.
    - ashark 9y ago
      It's lovely how counterintuitive it is that (in this case) "map" reduces state and "reduce" modifies and/or enlarges state.
    - eropple 9y ago
      FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better. Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.
- ashark 9y ago
  That, and that the tutorials/beginner-docs don't all start, "look, it's pretty much just two really really simple event dispatchers stuck together, so don't panic" followed by an implementation-focused walkthrough like this. Redux is way too simple to justify the amount of writing there is trying to teach people to use it[0]. It's two event/message dispatchers. Events/messages move through them thusly. Here's the tiny interface by which you interact with them. Don't do this or this unless you want bugs to happen, and here's why. Done. [0] a sure sign FP-fans are involved [rimshot]
  - johnfn 9y ago
    I couldn't agree more strongly. Something weird happens to FP proponents such that once they get very good at it, they lose all ability to explain or empathize with beginners. :)
    - ashark 9y ago
      One of the most frustrating thing about FP land is that I never feel confident I actually understand anything. Every time I think I might the explanation I arrive at is so damn simple that I can't convince myself it's truly correct because there's this mountain of confusing explanations in my wake, and why would anyone have tried to explain it that way if it were actually this simple?
  - acemarke 9y ago
    Docs PRs welcome! :) (Seriously, I mean it - most of my work as a Redux maintainer has involved improving the docs, and I genuinely am interested in having people help improve them.)

by ashark 9y ago

johnfn 9y ago

If there is one valid criticism of Redux, it is that the names for everything are obtuse and hard to understand.

acemarke 9y ago
For what it's worth, most of that comes directly from the Flux heritage. For example, the Flux docs at https://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html#actions-and-actioncreators https://facebook.github.io/react/blog/2014/07/30/flux-action... explicitly describe the terms "actions" and "action creators" . There was a lot of discussion and bikeshedding in the early Redux issues over whether to use terms like "events", "commands", or even "facts" instead, but Dan and Andrew opted to keep "actions" for consistency with Flux. (Really, a very large percentage of questions about "Why does Redux do $THING?" can be answered with "Because the Flux Architecture, or other existing Flux libs, did things that way first".) "Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.
- johnfn 9y ago
  It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :) It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand. For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state". Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.
  - ashark 9y ago
    It's lovely how counterintuitive it is that (in this case) "map" reduces state and "reduce" modifies and/or enlarges state.
  - eropple 9y ago
    FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better. Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.
ashark 9y ago
That, and that the tutorials/beginner-docs don't all start, "look, it's pretty much just two really really simple event dispatchers stuck together, so don't panic" followed by an implementation-focused walkthrough like this. Redux is way too simple to justify the amount of writing there is trying to teach people to use it[0]. It's two event/message dispatchers. Events/messages move through them thusly. Here's the tiny interface by which you interact with them. Don't do this or this unless you want bugs to happen, and here's why. Done. [0] a sure sign FP-fans are involved [rimshot]
- johnfn 9y ago
  I couldn't agree more strongly. Something weird happens to FP proponents such that once they get very good at it, they lose all ability to explain or empathize with beginners. :)
  - ashark 9y ago
    One of the most frustrating thing about FP land is that I never feel confident I actually understand anything. Every time I think I might the explanation I arrive at is so damn simple that I can't convince myself it's truly correct because there's this mountain of confusing explanations in my wake, and why would anyone have tried to explain it that way if it were actually this simple?
- acemarke 9y ago
  Docs PRs welcome! :) (Seriously, I mean it - most of my work as a Redux maintainer has involved improving the docs, and I genuinely am interested in having people help improve them.)