15 ms·

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 Redu

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... .

interlocutor 9y ago
>> 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 What percentage of business applications would benefit from this? My guess is, very few. Typical business applications fetch data from the backend and display it, let the user update the data and immediately send the updated data to the backend. There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update". I am not saying nobody needs that kind of capability. I am saying that few business applications do, and yet there is this notion that React and Redux go together and if you're going to use React it would be strange to not use Redux. Practically everyone who uses React also uses ReactRouter and Redux. The end-result of this is that React, which by itself is a simple, elegant and useful technology, has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies.
- acemarke 9y ago
  Why limit this to "business applications"? There's a whole lot more apps out there than just those :) If an app is really _just_ fetching data, displaying it in a row or form, and sending it back, then there might not be a lot of benefit. However, if data is being shared across multiple pieces of a UI, and the user is interacting with that data in multiple ways, then there may be more benefit. And yes, my own estimates are that roughly 55-60% of React apps are using Redux as well.
- shadowmint 9y ago
  Well, what's your solution? I mean, I've seen people drop redux into a single stand alone form for no reason other than they hadn't used react before, so they picked up a tutorial and the first thing it said to do was use redux. So, I'll happily agree that there's a whole lot of people using this without any need for it. ...but there is a need for it for some people, and for those people, what's your alternative? Raw react? Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you. Are there redux alternatives out there that solve the same 'single source of truth' problem I've never heard of? What are you using? > There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update". ...or is that simply not a problem that some people have? I'll certainly agree to that; but then, why are you using react? If your UI isn't dynamic, why are you building an SPA? For fun? The good old MVC tech stack works perfectly well for static data display and forms. You know why react exists? ...because complex interactive forms are hard to do right, and because interactive user interfaces that do something more complicated than CRUD operations are actually quite difficult to do right. The MVVM pattern with data binding is the 'best' solution out there for most UI application framework, and react is successful specifically because it allows you to manage complexity by creating a hierarchy of components instead. That's a really powerful effective technique, there's no question. Redux lets you manage the state for that hierarchy in one place. It lets you build large react hierarchies and know exactly what state the UI is in at any point in time, in one place. Why? ...because managing state in 100 different locations is complicated. What you're seeing is tools to help manage complexity; but you only need to use them when your complexity reaches a threshold that triggers the need to use them. If you don't have a complex problem, you don't need complex tools to manage it. > has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies. What you're seeing is the application of tools to solve a problem that doesn't exist for the specific domain you're looking at. That doesn't mean they don't solve the problem; it just means your problem doesn't require that level of complexity management. It's quite frustrating. I hear the 'its too complex' as an argument from so many people about using libraries and tools, and want 'something simple' instead; but I've hardly ever heard someone pitch a viable alternative instead, just complaints. Too much tooling. Too much complexity. Over engineering. So, tldr: When you do have a big complex react application with complex UI interactions... what's the alternative? If there is one, I'd like to hear about it.

interlocutor 9y ago

>> 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 What percentage of business applications would benefit from this? My guess is, very few. Typical business applications fetch data from the backend and display it, let the user update the data and immediately send the updated data to the backend. There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update". I am not saying nobody needs that kind of capability. I am saying that few business applications do, and yet there is this notion that React and Redux go together and if you're going to use React it would be strange to not use Redux. Practically everyone who uses React also uses ReactRouter and Redux. The end-result of this is that React, which by itself is a simple, elegant and useful technology, has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies.

acemarke 9y ago
Why limit this to "business applications"? There's a whole lot more apps out there than just those :) If an app is really _just_ fetching data, displaying it in a row or form, and sending it back, then there might not be a lot of benefit. However, if data is being shared across multiple pieces of a UI, and the user is interacting with that data in multiple ways, then there may be more benefit. And yes, my own estimates are that roughly 55-60% of React apps are using Redux as well.
shadowmint 9y ago
Well, what's your solution? I mean, I've seen people drop redux into a single stand alone form for no reason other than they hadn't used react before, so they picked up a tutorial and the first thing it said to do was use redux. So, I'll happily agree that there's a whole lot of people using this without any need for it. ...but there is a need for it for some people, and for those people, what's your alternative? Raw react? Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you. Are there redux alternatives out there that solve the same 'single source of truth' problem I've never heard of? What are you using? > There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update". ...or is that simply not a problem that some people have? I'll certainly agree to that; but then, why are you using react? If your UI isn't dynamic, why are you building an SPA? For fun? The good old MVC tech stack works perfectly well for static data display and forms. You know why react exists? ...because complex interactive forms are hard to do right, and because interactive user interfaces that do something more complicated than CRUD operations are actually quite difficult to do right. The MVVM pattern with data binding is the 'best' solution out there for most UI application framework, and react is successful specifically because it allows you to manage complexity by creating a hierarchy of components instead. That's a really powerful effective technique, there's no question. Redux lets you manage the state for that hierarchy in one place. It lets you build large react hierarchies and know exactly what state the UI is in at any point in time, in one place. Why? ...because managing state in 100 different locations is complicated. What you're seeing is tools to help manage complexity; but you only need to use them when your complexity reaches a threshold that triggers the need to use them. If you don't have a complex problem, you don't need complex tools to manage it. > has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies. What you're seeing is the application of tools to solve a problem that doesn't exist for the specific domain you're looking at. That doesn't mean they don't solve the problem; it just means your problem doesn't require that level of complexity management. It's quite frustrating. I hear the 'its too complex' as an argument from so many people about using libraries and tools, and want 'something simple' instead; but I've hardly ever heard someone pitch a viable alternative instead, just complaints. Too much tooling. Too much complexity. Over engineering. So, tldr: When you do have a big complex react application with complex UI interactions... what's the alternative? If there is one, I'd like to hear about it.