8 ms·

> As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Tell that to the previo

> As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Tell that to the previous developer. To be blunt, if your library isn't very usable without helper utils or wrappers, it probably isn't really doing its job. This is my first time using Redux, and my experience has been quite negative. This project has so many reams and reams of code that just doesn't clearly _do_ anything. Line after line of throat clearing and pseduostructure. I accept that this may just be a poorly written application. I've looked over the Express code and that's not much better, which is remarkable given that all it does is proxy API requests. But all these action creators and reducers and constants seem to have added a lot of indirection to what is still thoughtless and illiterate code. We are seriously talking about rewriting the whole thing. For a one year old project that's quite damning. Can you point me to an open source codebase that might convince me Redux-done-right makes for readable code?

acemarke 9y ago
I'm sorry to hear that your experience has been negative so far. There's a commonly repeated phrase that "Redux is a pattern, not a framework". Redux doesn't have anything built in for actually updating the state, or defining an application architecture. Redux primarily provides a pattern for separating the write logic from the rest of the app conceptually, and adding centralized behavior on top of that via middleware and store enhancers. So, how you build and organize your application around that pattern is up to you. Similarly, Redux does not _require_ that you use action creators, action type constants, or that you separate everything into multiple files by code type. Those are common _conventions_. It's absolutely legal for a Redux-connected React component to do: this.props.dispatch({type : "ADD_TODO", text : "Buy milk"}) However, there _are_ reasons why those patterns exist in the first place. So, a few thoughts. First, I'd encourage you to take the time to read through my two-part blog post "The Tao of Redux" [0], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. Second, while I don't have a specific Redux codebase to point to as a "shining example of best practices" strictly off the top of my head, I do have a list of some selected Redux applications that may be worth looking at. Some of them are purpose-built examples, and others are "real" apps. See the list at [1] - I know that there's some good codebases in that list. I'll also suggest taking a look at "Project Mini-Mek", the sample application for my own blog tutorial series [2]. My React/Redux links list has a large section of articles discussing good Redux architecture and best practices [3]. Some of those articles might be helpful. Finally, I'd be happy to spend some time discussing your current app's codebase, and perhaps offer some suggestions on ways you can make it better or easier to deal with. HN isn't a good place for that. However, I spend most evenings hanging out in the Reactiflux chat channels on Discord. Please feel free to ping me there, and we can discuss things further. The invite link for Reactiflux is at [4]. [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [4] https://www.reactiflux.com https://www.reactiflux.com
- jbreckmckye 9y ago
  Thank you, I will take a look at those resources. I cannot promise that I will keep using Redux in future, but I will try and give it a fair chance.
  - acemarke 9y ago
    Sure. And please really do feel free to ping me on Reactiflux if you have questions or would like to discuss things. Redux isn't for everybody or every use case. However, I do think it's frequently misunderstood. If it _really_ isn't helping you solve your problems, then you should certainly use something that's more appropriate or useful. But, it's also entirely possible that a better understanding of how it can be used, or how it can be adapted for certain situations, might make it more useful and helpful for your use case. A lot of my time writing about Redux has been spent trying to help clear up misconceptions, answer questions about real-world usage, and help people better understand how it works and can be used, so that they can make more informed decisions about Redux.
    - longsangstan 9y ago
      Do you recommend people to use redux for small scale project for global states? I for example use redux for states like isUserLoggedIn or userName/userId, and not much else. If not what are the alternatives apart from simply passing the state down the component tree? Thanks.
      - acemarke 9y ago
        If that's really all you're tracking, then you're probably not going to get much benefit out of Redux. Then again, it's also possible that there wouldn't be much overhead in simply creating a Redux store, inserting a couple values, and connecting components to retrieve those. Dan's post "The Case for Flux" [0] discusses what kind of use cases would benefit from a Flux architecture. That still very much applies to using Redux as well, and is worth reading. The Redux FAQ also has a section on "When should I use Redux?" [1] There's nothing _wrong_ with passing down values as props, even through multiple levels - it's just that most people dislike doing so. You could make the values available using React's "context" feature, although it's likely that wouldn't be the best choice here. There's also a variety of "not-quite-Redux" libraries out there that try to simplify the interactions with Redux ("no reducers", "no dispatching", "no actions", etc), and perhaps one of those might be useful. [0] https://medium.com/swlh/the-case-for-flux-379b7d1982c6 https://medium.com/swlh/the-case-for-flux-379b7d1982c6 [1] http://redux.js.org/docs/faq/General.html#general-when-to-use http://redux.js.org/docs/faq/General.html#general-when-to-us...
interlocutor 9y ago
Ask Redux users what problem it is solving for them and watch them squirm. Eventually they will come up with time travel debugging, or replaying state changes, etc. This is developers working backwards and inventing problems to justify their technical choices. Not coincidentally, most blogs about Redux jump right into how to use it, without prefacing it with why would you want to use it in the first place. A lot of developers think introducing more libraries and more rigor is a good thing even if it drives up the cost of software development. This is the only reason I can think of, for why so many people are using Redux. Another reason may be ReactRouter which makes it harder to supply data to React. But there are other MVC routers that make using React painless and I'd recommend to anyone considering using ReactRouter/Redux to consider better MVC-based alternatives. (And no, using MVC does NOT imply two-way data binding.)
- acemarke 9y ago
  I would flip that first paragraph around. Time travel debugging and replaying state changes are technical solutions that were created to help solve one of Redux's core use cases: making it easier for a developer to understand when, why, and how your state was updated, and what part of the application triggered that state update. In addition, centralizing large portions of your app's state enables a wide variety of useful capabilities. I do agree that many people and articles talk about the "how" rather than the "why", but I'd say that this is a widespread issue rather than being specific to discussions of Redux. Dan Abramov, Redux's creator, has said himself that "Redux is over-hyped". I also agree that many people are being pushed to learn it without understanding why they ought to use it, and that new learners are being told they _must_ start with Redux and React at the same time. That's not what we encourage officially - we suggest that people start with React first, then learn Redux later. However, I think saying "people only use Redux because it's hyped or they're told to" is both inaccurate and unfair. I've talked to many people who have said that Redux is helping them write better-architected applications that are more maintainable and easier to work on. Some people may have chosen it due to hype, but many others have chosen it because it solves their problems. Finally, I'd like to recommend reading Dan's article "You Might Not Need Redux", which discusses the tradeoffs involved with Redux, both the limitations it asks you to follow and some of the potential benefits you get in return: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... .
chairmanwow 9y ago
Redux is unusable without an insane amount of boilerplate. HOWEVER, I think Redux still is an improvement over raw JS, although underpowered compared to Elm. It seems like it is essentially trying to bring functional union type case switching to a language without that feature. As such, actions are insanely laborious to construct. Furthermore React / Redux is far to pedantic in reinforcing it's design decisions without offering a backdoor to work interact with the outside world.
- acemarke 9y ago
  Which design decisions are you thinking of? Also, can you clarify what you mean by "actions are insanely laborious to construct"?
  - chairmanwow 9y ago
    Which design decisions are you thinking of? Mostly that updates can only happen on explicit changes to the state. Also a React application doesn't acknowledge the possibility of a component existing which is not a React component. I most recently ran into this issue when trying to add an OpenLayer map to an application. In a vanilla JS application it's trivial, but React was difficult to coerce into breaking it's own rules to accommodate it. Elm solves this particular issue well with Ports [1]. It respects the possibility that there may be things going on that haven't been explicitly planned for. actions are insanely laborious to construct On a second read through, this is edging on hyperbole. Maybe a more honest presentation of the facts is that Redux actions grow tedious to write. You start with an action type declaration: export const SOME_ACTION = "SOME_ACTION"; Then you create an action creator: export function performSomeAction(data) { return { type: SOME_ACTION, data } } And then of course you need to write a case statement in a reducer to deal with the data and somehow effect the state. It's tedious because it's trying to recreate the pattern matching functionality of passing union types around in functional languages. In SML, Haskell, Elm etc. you can elegantly decompose and consume types with case statements and pattern matching, which are built into the languages [2, 3]. [1] https://guide.elm-lang.org/interop/javascript.html https://guide.elm-lang.org/interop/javascript.html [2] https://stackoverflow.com/a/14604042 https://stackoverflow.com/a/14604042 [3] http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lecture3.htm http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lect...

acemarke 9y ago

I'm sorry to hear that your experience has been negative so far. There's a commonly repeated phrase that "Redux is a pattern, not a framework". Redux doesn't have anything built in for actually updating the state, or defining an application architecture. Redux primarily provides a pattern for separating the write logic from the rest of the app conceptually, and adding centralized behavior on top of that via middleware and store enhancers. So, how you build and organize your application around that pattern is up to you. Similarly, Redux does not _require_ that you use action creators, action type constants, or that you separate everything into multiple files by code type. Those are common _conventions_. It's absolutely legal for a Redux-connected React component to do: this.props.dispatch({type : "ADD_TODO", text : "Buy milk"}) However, there _are_ reasons why those patterns exist in the first place. So, a few thoughts. First, I'd encourage you to take the time to read through my two-part blog post "The Tao of Redux" [0], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. Second, while I don't have a specific Redux codebase to point to as a "shining example of best practices" strictly off the top of my head, I do have a list of some selected Redux applications that may be worth looking at. Some of them are purpose-built examples, and others are "real" apps. See the list at [1] - I know that there's some good codebases in that list. I'll also suggest taking a look at "Project Mini-Mek", the sample application for my own blog tutorial series [2]. My React/Redux links list has a large section of articles discussing good Redux architecture and best practices [3]. Some of those articles might be helpful. Finally, I'd be happy to spend some time discussing your current app's codebase, and perhaps offer some suggestions on ways you can make it better or easier to deal with. HN isn't a good place for that. However, I spend most evenings hanging out in the Reactiflux chat channels on Discord. Please feel free to ping me there, and we can discuss things further. The invite link for Reactiflux is at [4]. [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [4] https://www.reactiflux.com https://www.reactiflux.com

jbreckmckye 9y ago
Thank you, I will take a look at those resources. I cannot promise that I will keep using Redux in future, but I will try and give it a fair chance.
- acemarke 9y ago
  Sure. And please really do feel free to ping me on Reactiflux if you have questions or would like to discuss things. Redux isn't for everybody or every use case. However, I do think it's frequently misunderstood. If it _really_ isn't helping you solve your problems, then you should certainly use something that's more appropriate or useful. But, it's also entirely possible that a better understanding of how it can be used, or how it can be adapted for certain situations, might make it more useful and helpful for your use case. A lot of my time writing about Redux has been spent trying to help clear up misconceptions, answer questions about real-world usage, and help people better understand how it works and can be used, so that they can make more informed decisions about Redux.
  - longsangstan 9y ago
    Do you recommend people to use redux for small scale project for global states? I for example use redux for states like isUserLoggedIn or userName/userId, and not much else. If not what are the alternatives apart from simply passing the state down the component tree? Thanks.
    - acemarke 9y ago
      If that's really all you're tracking, then you're probably not going to get much benefit out of Redux. Then again, it's also possible that there wouldn't be much overhead in simply creating a Redux store, inserting a couple values, and connecting components to retrieve those. Dan's post "The Case for Flux" [0] discusses what kind of use cases would benefit from a Flux architecture. That still very much applies to using Redux as well, and is worth reading. The Redux FAQ also has a section on "When should I use Redux?" [1] There's nothing _wrong_ with passing down values as props, even through multiple levels - it's just that most people dislike doing so. You could make the values available using React's "context" feature, although it's likely that wouldn't be the best choice here. There's also a variety of "not-quite-Redux" libraries out there that try to simplify the interactions with Redux ("no reducers", "no dispatching", "no actions", etc), and perhaps one of those might be useful. [0] https://medium.com/swlh/the-case-for-flux-379b7d1982c6 https://medium.com/swlh/the-case-for-flux-379b7d1982c6 [1] http://redux.js.org/docs/faq/General.html#general-when-to-use http://redux.js.org/docs/faq/General.html#general-when-to-us...

interlocutor 9y ago

Ask Redux users what problem it is solving for them and watch them squirm. Eventually they will come up with time travel debugging, or replaying state changes, etc. This is developers working backwards and inventing problems to justify their technical choices. Not coincidentally, most blogs about Redux jump right into how to use it, without prefacing it with why would you want to use it in the first place. A lot of developers think introducing more libraries and more rigor is a good thing even if it drives up the cost of software development. This is the only reason I can think of, for why so many people are using Redux. Another reason may be ReactRouter which makes it harder to supply data to React. But there are other MVC routers that make using React painless and I'd recommend to anyone considering using ReactRouter/Redux to consider better MVC-based alternatives. (And no, using MVC does NOT imply two-way data binding.)

acemarke 9y ago
I would flip that first paragraph around. Time travel debugging and replaying state changes are technical solutions that were created to help solve one of Redux's core use cases: making it easier for a developer to understand when, why, and how your state was updated, and what part of the application triggered that state update. In addition, centralizing large portions of your app's state enables a wide variety of useful capabilities. I do agree that many people and articles talk about the "how" rather than the "why", but I'd say that this is a widespread issue rather than being specific to discussions of Redux. Dan Abramov, Redux's creator, has said himself that "Redux is over-hyped". I also agree that many people are being pushed to learn it without understanding why they ought to use it, and that new learners are being told they _must_ start with Redux and React at the same time. That's not what we encourage officially - we suggest that people start with React first, then learn Redux later. However, I think saying "people only use Redux because it's hyped or they're told to" is both inaccurate and unfair. I've talked to many people who have said that Redux is helping them write better-architected applications that are more maintainable and easier to work on. Some people may have chosen it due to hype, but many others have chosen it because it solves their problems. Finally, I'd like to recommend reading Dan's article "You Might Not Need Redux", which discusses the tradeoffs involved with Redux, both the limitations it asks you to follow and some of the potential benefits you get in return: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... .

chairmanwow 9y ago

Redux is unusable without an insane amount of boilerplate. HOWEVER, I think Redux still is an improvement over raw JS, although underpowered compared to Elm. It seems like it is essentially trying to bring functional union type case switching to a language without that feature. As such, actions are insanely laborious to construct. Furthermore React / Redux is far to pedantic in reinforcing it's design decisions without offering a backdoor to work interact with the outside world.

acemarke 9y ago
Which design decisions are you thinking of? Also, can you clarify what you mean by "actions are insanely laborious to construct"?
- chairmanwow 9y ago
  Which design decisions are you thinking of? Mostly that updates can only happen on explicit changes to the state. Also a React application doesn't acknowledge the possibility of a component existing which is not a React component. I most recently ran into this issue when trying to add an OpenLayer map to an application. In a vanilla JS application it's trivial, but React was difficult to coerce into breaking it's own rules to accommodate it. Elm solves this particular issue well with Ports [1]. It respects the possibility that there may be things going on that haven't been explicitly planned for. actions are insanely laborious to construct On a second read through, this is edging on hyperbole. Maybe a more honest presentation of the facts is that Redux actions grow tedious to write. You start with an action type declaration: export const SOME_ACTION = "SOME_ACTION"; Then you create an action creator: export function performSomeAction(data) { return { type: SOME_ACTION, data } } And then of course you need to write a case statement in a reducer to deal with the data and somehow effect the state. It's tedious because it's trying to recreate the pattern matching functionality of passing union types around in functional languages. In SML, Haskell, Elm etc. you can elegantly decompose and consume types with case statements and pattern matching, which are built into the languages [2, 3]. [1] https://guide.elm-lang.org/interop/javascript.html https://guide.elm-lang.org/interop/javascript.html [2] https://stackoverflow.com/a/14604042 https://stackoverflow.com/a/14604042 [3] http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lecture3.htm http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lect...