5 ms·

"Redux is a simple library" woah woah stop right there. How is this: const handlers = { [CREATE_NOTE]: (state, action) => { ... }, // ... a tho

"Redux is a simple library" woah woah stop right there. How is this: const handlers = { [CREATE_NOTE]: (state, action) => { ... }, // ... a thousand more of this } simple? This looks horrible. Every time you want to work on code that modifies data, you have to switch to the one file where you keep all the data-modifying functions? Seriously?! Freezer https://github.com/arqex/freezer https://github.com/arqex/freezer is a much, much better experience. You just shove immutable objects down the component tree, and they just come with methods that modify "them" (by actually changing the data tree). It has an event system as well for when you actually want to centralize actions. Works great with Polymer, by the way!

acemarke 9y ago
You're complaining about a couple different things. That particular reducer example is a bit terse, and could be made more readable. That said, yes, Redux (as a Flux Architecture derivative) does ask you to separate all your "write logic" from the rest of the application. This is explicitly part of the design. You may want to read Dan Abramov's article "You Might Not Need Redux", where he discusses the tradeoffs that Redux asks you to make, and the benefits you get as a result: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... . I'm also working on a blog post that will discuss the actual technical limitations Redux requires of you, vs how you are _intended_ to use Redux, vs how it's _possible_ to use Redux. The goal is to clarify where the various common aspects of Redux usage come from and why. I'm hoping to finish the post over the weekend and publish it early next week. If anyone's interested, keep an eye on my blog at http://blog.isquaredsoftware.com http://blog.isquaredsoftware.com .
joevandyk 9y ago
Nothing is stopping you from putting the functions into multiple files.
johnfn 9y ago
> you have to switch to the one file where you keep all the data-modifying functions? Seriously?! Of course not - and I strongly urge you to think through things like this more deeply before writing them off. Redux is a really good and well-thought-out library. I'm sure you could think of multiple solutions to the problem you just proposed, including splitting that file into multiple files. It would be a shame if you never took the time to understand the library because you got caught up on simple trivialities like this.
- floatboth 9y ago
  Sure you can split the file, but you still have to separate it from the actual UI event handler. It might be well thought-out but it's more complicated than it needs to be.
  - johnfn 9y ago
    Of course, and that's the huge win of Redux. Forcing you to separate out state updates wraps them in a layer of indirection and allows you to operate on them at a higher level than otherwise possible. This makes ordinarily difficult operations simple and elegant. You can use the higher level of abstraction to get undo for free, or replay them to find bugs, time travel, or send them across a server to get a multi user app. What you're saying is "more complicated than it needs to be" is in fact the revelatory idea of Redux. I reiterate myself: you should try to understand Redux more deeply before writing it off. You are doing it a disservice.
    - floatboth 9y ago
      Why do you need this separation to get these things? In Freezer, you can do transactions directly in your view event handlers, and one transaction is one update, and .on('update', (currentState, prevState) => {…}) you can save the prevState into your undo log. And when you want to separate a data manipulation action, you can use custom events to do so — but you aren't forced to! It keeps simple operations simple.
      - johnfn 9y ago
        Are you really just opposed to doing things in different files? I'm going to divert the conversation away from Redux entirely if that's the case. You should invest in an editor with good "go to definition" support. I had a similar problem, but as soon as I did this, the pain threshold for switching files dropped to nearly 0. (If that's not the case, do keep on mind that a file separation is totally unnecessary. You could write your state manipulators inline if you wanted. I feel it is a bit organizationally messy, but hey, whatever you like.)
amackera 9y ago
Not a valid criticism of Redux.
- gramstrong 9y ago
  Not a constructive comment :/
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.
untog 9y ago
"simple" and "verbose" are not the same thing. I agree that Redux is overly verbose, but what it's doing is actually very simple. That said, I avoid it because I dislike having to write actions for every single operation I want to do on my data.
ng12 9y ago
There's a critical mass where I switch to using Ducks: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux Yes, you can write bad Redux code. That doesn't mean it's not simple.
jdeal 9y ago
I think it's definitely worth considering other solutions, as Dan himself has mentioned that Redux isn't for everyone. Redux forces you to apply some constraints and make some tradeoffs. I personally like those constraints and tradeoffs, but I can understand it's not for everyone!
mambodog 9y ago
Sounds like you're confusing 'simple' with 'easy'. Rich Hickey does a good job of contrasting the two in Simple Made Easy[0]. The essential part of Redux is only 44 lines of simple code [1]. You can understand everything that it is doing. That is simple. It doesn't mean that it's going to be a great experience to work with (you might want to add some abstraction on top to make it also 'easy'), but it is definitely simple. [0]: https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy [1]: https://gist.github.com/gaearon/ffd88b0e4f00b22c3159#file-slim-redux-js-L56-L99 https://gist.github.com/gaearon/ffd88b0e4f00b22c3159#file-sl...
rhinoceraptor 9y ago
Redux gives you a combineReducers() function for splitting your reducers into separate files. The way I structure it is by which section of the state object they modify, so that I have a reducers/stateA.js, reducers/stateB.js, which correspond to a state object that looks like { stateA: { ... }, stateB: { ... } }.

acemarke 9y ago

You're complaining about a couple different things. That particular reducer example is a bit terse, and could be made more readable. That said, yes, Redux (as a Flux Architecture derivative) does ask you to separate all your "write logic" from the rest of the application. This is explicitly part of the design. You may want to read Dan Abramov's article "You Might Not Need Redux", where he discusses the tradeoffs that Redux asks you to make, and the benefits you get as a result: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... . I'm also working on a blog post that will discuss the actual technical limitations Redux requires of you, vs how you are _intended_ to use Redux, vs how it's _possible_ to use Redux. The goal is to clarify where the various common aspects of Redux usage come from and why. I'm hoping to finish the post over the weekend and publish it early next week. If anyone's interested, keep an eye on my blog at http://blog.isquaredsoftware.com http://blog.isquaredsoftware.com .

joevandyk 9y ago

Nothing is stopping you from putting the functions into multiple files.

johnfn 9y ago

> you have to switch to the one file where you keep all the data-modifying functions? Seriously?! Of course not - and I strongly urge you to think through things like this more deeply before writing them off. Redux is a really good and well-thought-out library. I'm sure you could think of multiple solutions to the problem you just proposed, including splitting that file into multiple files. It would be a shame if you never took the time to understand the library because you got caught up on simple trivialities like this.

floatboth 9y ago
Sure you can split the file, but you still have to separate it from the actual UI event handler. It might be well thought-out but it's more complicated than it needs to be.
- johnfn 9y ago
  Of course, and that's the huge win of Redux. Forcing you to separate out state updates wraps them in a layer of indirection and allows you to operate on them at a higher level than otherwise possible. This makes ordinarily difficult operations simple and elegant. You can use the higher level of abstraction to get undo for free, or replay them to find bugs, time travel, or send them across a server to get a multi user app. What you're saying is "more complicated than it needs to be" is in fact the revelatory idea of Redux. I reiterate myself: you should try to understand Redux more deeply before writing it off. You are doing it a disservice.
  - floatboth 9y ago
    Why do you need this separation to get these things? In Freezer, you can do transactions directly in your view event handlers, and one transaction is one update, and .on('update', (currentState, prevState) => {…}) you can save the prevState into your undo log. And when you want to separate a data manipulation action, you can use custom events to do so — but you aren't forced to! It keeps simple operations simple.
    - johnfn 9y ago
      Are you really just opposed to doing things in different files? I'm going to divert the conversation away from Redux entirely if that's the case. You should invest in an editor with good "go to definition" support. I had a similar problem, but as soon as I did this, the pain threshold for switching files dropped to nearly 0. (If that's not the case, do keep on mind that a file separation is totally unnecessary. You could write your state manipulators inline if you wanted. I feel it is a bit organizationally messy, but hey, whatever you like.)

amackera 9y ago

Not a valid criticism of Redux.

gramstrong 9y ago
Not a constructive comment :/

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.

untog 9y ago

"simple" and "verbose" are not the same thing. I agree that Redux is overly verbose, but what it's doing is actually very simple. That said, I avoid it because I dislike having to write actions for every single operation I want to do on my data.

ng12 9y ago

There's a critical mass where I switch to using Ducks: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux Yes, you can write bad Redux code. That doesn't mean it's not simple.

jdeal 9y ago

I think it's definitely worth considering other solutions, as Dan himself has mentioned that Redux isn't for everyone. Redux forces you to apply some constraints and make some tradeoffs. I personally like those constraints and tradeoffs, but I can understand it's not for everyone!

mambodog 9y ago

Sounds like you're confusing 'simple' with 'easy'. Rich Hickey does a good job of contrasting the two in Simple Made Easy[0]. The essential part of Redux is only 44 lines of simple code [1]. You can understand everything that it is doing. That is simple. It doesn't mean that it's going to be a great experience to work with (you might want to add some abstraction on top to make it also 'easy'), but it is definitely simple. [0]: https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy [1]: https://gist.github.com/gaearon/ffd88b0e4f00b22c3159#file-slim-redux-js-L56-L99 https://gist.github.com/gaearon/ffd88b0e4f00b22c3159#file-sl...

rhinoceraptor 9y ago

Redux gives you a combineReducers() function for splitting your reducers into separate files. The way I structure it is by which section of the state object they modify, so that I have a reducers/stateA.js, reducers/stateB.js, which correspond to a state object that looks like { stateA: { ... }, stateB: { ... } }.