46 ms·

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,

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... .
- 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.
dhbradshaw 9y ago
For me, there's a peace of mind associated with knowing that all my state is in one place in an organized format. It's like having a db, but on the front end, and it makes testing the front end very nice. It also has other practical benefits. Specifically, 1) it makes rapid iteration simpler because I don't have to click back to the portion of the app that I'm testing but can instead just rehydrate a cached state, and 2) it makes it trivial to save state for the user either by caching it locally in the browser or by sending it over to the back end.
- celim307 9y ago
  > It's like having a db, but on the front end This.
- JonathonW 9y ago
  Why do I need Redux for that, though? I'm working on a fairly small but still nontrivial React app for work (it's the first time we've used React for anything here, and we're partly doing it to evaluate React for future work). I've not used Redux anywhere in my application (it's all vanilla React), but my state is still all in one place in an organized format, and, since I have a single component managing my state, I can still trivially do both (1) and (2) there. What's Redux giving me that I don't already have, aside from another layer to maintain and another piece to break?
  - acemarke 9y ago
    I wrote an article a while back that describes some of the possible benefits for using Redux in a React app: https://www.fullstackreact.com/articles/redux-with-mark-erikson/ https://www.fullstackreact.com/articles/redux-with-mark-erik... . Quick summary: you don't have to pass data as props all the way from the top of your app to the bottom, and it lets you keep your app state if you're doing hot module reloading in development. In addition, time-travel debugging and the action history log really are powerful tools for understanding how your app is behaving over time. My other comment just below this discusses some more benefits, and links to Dan's "You Might Not Need Redux" post. I'd encourage you to read that as well.
lewisl9029 9y ago
The "You Might Not Need Redux" blog post by the author of Redux addresses your points almost directly: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... The TL;DR is Redux tries to place a set of constraints on how and when you're allowed to share state between components and how and when you're allowed mutate that shared state, much like how React and it's virtual DOM abstraction places constraints on how and when you're allowed to manipulate the DOM. These constraints allows the library to make certain assumptions about state and state changes that enables it to perform global performance optimizations across the entire codebase (namely performing only shallow equality checks on all state-mapped props when determining whether or not to rerender, because it can assume all state changes will result in a reference change) that would otherwise have to be performed for each component on a case by case basis, and micro-optimized by each individual developer by hand. These constraints also allows tooling authors to make these same assumptions, which is what enables the best-in-class tooling that Redux developers have access to, like time traveling debugging and state change replays. These tools would simply not be possible to build in a generalizable way if your codebase didn't allow them to make the same assumptions (and adhere to the corresponding constraints when it comes to state sharing and state mutations) as it could for a Redux codebase. The post has a whole list of very compelling use cases/tooling that are either made possible by or at least made completely trivial by the enforcement of these constraints around state mutations: > These limitations are appealing to me because they help build apps that: > Persist state to a local storage and then boot up from it, out of the box. > Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box. > Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors. > Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written. > Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written. > Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD. > Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps. > Provide alternative UIs while reusing most of the business logic. You could certainly make the case that Redux is not necessary for building a React app. Or the case that the additional boilerplate and constraints it places upon you could be a net negative for apps that are not sufficiently complex to warrant them. In fact, that's exactly the case that the linked post tries to make. And yes, the only reason people use Redux is to introduce rigor (constraints) into their codebase and development workflow. But to insinuate that the rigor and constraints introduced by Redux will only ever be a net negative in terms of developer productivity is to display a fundamental ignorance regarding the vital role that rigor and constraints have always played in software architecture, and the fact that the recent advances in frontend architecture that have been proven to reduce complexity and make large codebases easier to reason about (things like the virtual DOM, unidirectional data flow, immutable state trees/caches, functional/reactive programming, and even the MVC pattern itself) have almost always come as a result of placing more constraints on what the developer is allowed to do.
shados 9y ago
I jumped in the Redux bandwagon after spending the decade before that either in jquery hell (or pre-jquery hell), and eventually Backbone, Angular, and React + Flux. I've touched probably 200+ production frontend apps of various sizes by now, ranging from a couple of pages, going to tens of millions of lines of Javascript in a single monolith. Your millage will vary and everyone hits different challenges in their career, but to me, the biggest issues when building apps was never building them from scratch or adding new features. It was always maintaining existing features. So I optimize everything I do for that, as I consider everything else completely trivial except for groundbreaking algorithms designed by PhDs (which is not me) and not worth thinking about. I've spent years trying to nail down why these apps, no matter who works on them, always end up impossible to deal with. No matter how much time is spent trying to figure out the architecture, documentation and design, it always goes to hell given enough time. To me (and its a totally personal analysis), it was always nailed down to figuring out: "Where the F* does this value come from" or "how do I follow what the hell this button does". It should be simple. I can use a debugger, obviously, but as requirements pile on, it invariably goes to hell. Elm, to me, is the panacea of solutions here. A single atomic state, and a UX that is nothing more than a projection (or a map, if you prefer) of state to UX. And to keep the UX "dumb", you then need to externalize all state and side effect logic. Once you have that, you can reason about any bug without even looking at the code. Is the UX wrong? Was the state right? No? Did the event triggered right? yes? Well, the bug HAS to be in the update function. Boom done. Now the question becomes, how do you reproduce this in JavaScript, which doesn't even have an approximation of algebraic effects, doesn't have immutable data structures, doesn't have a good way to play with the dom in a declarative way... React + Redux with a few extras from the ecosystem provide that. Who cares about boilerplate, I get predictability. The more you abstract, the less predictable things get and bugs can come from anywhere. Inevitably as the app grows, you need to add stuff and weave it in the existing features. The decoupling of State <--> Selector <--> Component <---> Action <---> Reducer has a very tightly defined set of semantics where even the most complex requirement fall neatly in these atoms (not quite as neatly as Elm when it comes to side effects, but it's as close as I've found for now). Build an app some other way that does the -exact- same thing? You'll either end up with just as much code (oh, it won't be as repetitive and boring, but it will be there. I LOVE boring code), or you'll end up with something much more rigid that requires more compromises. There's a few alternatives that get close, but they usually do so by tightly coupling concerns and making it harder to figure out where the hell shit is happening. The only obstacle is that the reasons behind "why" things are done this way is almost lost to most people working with Redux, in spite of Mark's best effort to prevent it from happening (there's only so much he can do short of brainwashing the planet). When the "why" gets lost, the community starts building things that neuter Redux, making it seemingly useless vs the alternatives.
mixedCase 9y ago
I like Redux because tracking mutability and specially, side-effects that cause it, is a bitch once your app stops being a special snowflake you alone created and cared for a small purpose. Even for those small applications/prototypes, having a centralized store allows me to code on auto-pilot where I don't have to worry as much about the code and focus on what it does instead. Would X particular piece of UI work better in a different way? Okay, then that UI code can fuck right off; it's not like it's going to affect the rest of my application's state.
jbergens 9y ago
You might also want to look at what people used before redux. There were a lot of Flux libraries and they were not all easy to use. And skipping libraries for state management all together often ends up in writing spaghetti code or reinventing the wheel. A small state management library can help a lot. I used a Flux library before but like mobx now and will default to that unless some specific requirement point to redux or something else.
dangjc 9y ago
React is nice because it encourages encapsulation and componentization. Redux feels like it discards all that. Your OO encapsulation gets disassembled into pure functions and dumb state. Pure functions are great to reason about, but redux applications feel like they have their insides extruded and thrown everywhere.
- acemarke 9y ago
  Globalization and encapsulation are different points on a spectrum, and both have benefits and disadvantages. It's all about tradeoffs! :) I've definitely noted that React devs seem to fall into either a "component-centric" view of the world, or an "app-centric" view. Both are okay. I'll also point out that the Redux FAQ explicitly says it's up to you as a developer to decide what state should live in Redux, and what is better suited for local component state: http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... .

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

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.

dhbradshaw 9y ago

For me, there's a peace of mind associated with knowing that all my state is in one place in an organized format. It's like having a db, but on the front end, and it makes testing the front end very nice. It also has other practical benefits. Specifically, 1) it makes rapid iteration simpler because I don't have to click back to the portion of the app that I'm testing but can instead just rehydrate a cached state, and 2) it makes it trivial to save state for the user either by caching it locally in the browser or by sending it over to the back end.

celim307 9y ago
> It's like having a db, but on the front end This.
JonathonW 9y ago
Why do I need Redux for that, though? I'm working on a fairly small but still nontrivial React app for work (it's the first time we've used React for anything here, and we're partly doing it to evaluate React for future work). I've not used Redux anywhere in my application (it's all vanilla React), but my state is still all in one place in an organized format, and, since I have a single component managing my state, I can still trivially do both (1) and (2) there. What's Redux giving me that I don't already have, aside from another layer to maintain and another piece to break?
- acemarke 9y ago
  I wrote an article a while back that describes some of the possible benefits for using Redux in a React app: https://www.fullstackreact.com/articles/redux-with-mark-erikson/ https://www.fullstackreact.com/articles/redux-with-mark-erik... . Quick summary: you don't have to pass data as props all the way from the top of your app to the bottom, and it lets you keep your app state if you're doing hot module reloading in development. In addition, time-travel debugging and the action history log really are powerful tools for understanding how your app is behaving over time. My other comment just below this discusses some more benefits, and links to Dan's "You Might Not Need Redux" post. I'd encourage you to read that as well.

lewisl9029 9y ago

The "You Might Not Need Redux" blog post by the author of Redux addresses your points almost directly: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... The TL;DR is Redux tries to place a set of constraints on how and when you're allowed to share state between components and how and when you're allowed mutate that shared state, much like how React and it's virtual DOM abstraction places constraints on how and when you're allowed to manipulate the DOM. These constraints allows the library to make certain assumptions about state and state changes that enables it to perform global performance optimizations across the entire codebase (namely performing only shallow equality checks on all state-mapped props when determining whether or not to rerender, because it can assume all state changes will result in a reference change) that would otherwise have to be performed for each component on a case by case basis, and micro-optimized by each individual developer by hand. These constraints also allows tooling authors to make these same assumptions, which is what enables the best-in-class tooling that Redux developers have access to, like time traveling debugging and state change replays. These tools would simply not be possible to build in a generalizable way if your codebase didn't allow them to make the same assumptions (and adhere to the corresponding constraints when it comes to state sharing and state mutations) as it could for a Redux codebase. The post has a whole list of very compelling use cases/tooling that are either made possible by or at least made completely trivial by the enforcement of these constraints around state mutations: > These limitations are appealing to me because they help build apps that: > Persist state to a local storage and then boot up from it, out of the box. > Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box. > Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors. > Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written. > Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written. > Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD. > Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps. > Provide alternative UIs while reusing most of the business logic. You could certainly make the case that Redux is not necessary for building a React app. Or the case that the additional boilerplate and constraints it places upon you could be a net negative for apps that are not sufficiently complex to warrant them. In fact, that's exactly the case that the linked post tries to make. And yes, the only reason people use Redux is to introduce rigor (constraints) into their codebase and development workflow. But to insinuate that the rigor and constraints introduced by Redux will only ever be a net negative in terms of developer productivity is to display a fundamental ignorance regarding the vital role that rigor and constraints have always played in software architecture, and the fact that the recent advances in frontend architecture that have been proven to reduce complexity and make large codebases easier to reason about (things like the virtual DOM, unidirectional data flow, immutable state trees/caches, functional/reactive programming, and even the MVC pattern itself) have almost always come as a result of placing more constraints on what the developer is allowed to do.

shados 9y ago

I jumped in the Redux bandwagon after spending the decade before that either in jquery hell (or pre-jquery hell), and eventually Backbone, Angular, and React + Flux. I've touched probably 200+ production frontend apps of various sizes by now, ranging from a couple of pages, going to tens of millions of lines of Javascript in a single monolith. Your millage will vary and everyone hits different challenges in their career, but to me, the biggest issues when building apps was never building them from scratch or adding new features. It was always maintaining existing features. So I optimize everything I do for that, as I consider everything else completely trivial except for groundbreaking algorithms designed by PhDs (which is not me) and not worth thinking about. I've spent years trying to nail down why these apps, no matter who works on them, always end up impossible to deal with. No matter how much time is spent trying to figure out the architecture, documentation and design, it always goes to hell given enough time. To me (and its a totally personal analysis), it was always nailed down to figuring out: "Where the F* does this value come from" or "how do I follow what the hell this button does". It should be simple. I can use a debugger, obviously, but as requirements pile on, it invariably goes to hell. Elm, to me, is the panacea of solutions here. A single atomic state, and a UX that is nothing more than a projection (or a map, if you prefer) of state to UX. And to keep the UX "dumb", you then need to externalize all state and side effect logic. Once you have that, you can reason about any bug without even looking at the code. Is the UX wrong? Was the state right? No? Did the event triggered right? yes? Well, the bug HAS to be in the update function. Boom done. Now the question becomes, how do you reproduce this in JavaScript, which doesn't even have an approximation of algebraic effects, doesn't have immutable data structures, doesn't have a good way to play with the dom in a declarative way... React + Redux with a few extras from the ecosystem provide that. Who cares about boilerplate, I get predictability. The more you abstract, the less predictable things get and bugs can come from anywhere. Inevitably as the app grows, you need to add stuff and weave it in the existing features. The decoupling of State <--> Selector <--> Component <---> Action <---> Reducer has a very tightly defined set of semantics where even the most complex requirement fall neatly in these atoms (not quite as neatly as Elm when it comes to side effects, but it's as close as I've found for now). Build an app some other way that does the -exact- same thing? You'll either end up with just as much code (oh, it won't be as repetitive and boring, but it will be there. I LOVE boring code), or you'll end up with something much more rigid that requires more compromises. There's a few alternatives that get close, but they usually do so by tightly coupling concerns and making it harder to figure out where the hell shit is happening. The only obstacle is that the reasons behind "why" things are done this way is almost lost to most people working with Redux, in spite of Mark's best effort to prevent it from happening (there's only so much he can do short of brainwashing the planet). When the "why" gets lost, the community starts building things that neuter Redux, making it seemingly useless vs the alternatives.

mixedCase 9y ago

I like Redux because tracking mutability and specially, side-effects that cause it, is a bitch once your app stops being a special snowflake you alone created and cared for a small purpose. Even for those small applications/prototypes, having a centralized store allows me to code on auto-pilot where I don't have to worry as much about the code and focus on what it does instead. Would X particular piece of UI work better in a different way? Okay, then that UI code can fuck right off; it's not like it's going to affect the rest of my application's state.

jbergens 9y ago

You might also want to look at what people used before redux. There were a lot of Flux libraries and they were not all easy to use. And skipping libraries for state management all together often ends up in writing spaghetti code or reinventing the wheel. A small state management library can help a lot. I used a Flux library before but like mobx now and will default to that unless some specific requirement point to redux or something else.

dangjc 9y ago

React is nice because it encourages encapsulation and componentization. Redux feels like it discards all that. Your OO encapsulation gets disassembled into pure functions and dumb state. Pure functions are great to reason about, but redux applications feel like they have their insides extruded and thrown everywhere.

acemarke 9y ago
Globalization and encapsulation are different points on a spectrum, and both have benefits and disadvantages. It's all about tradeoffs! :) I've definitely noted that React devs seem to fall into either a "component-centric" view of the world, or an "app-centric" view. Both are okay. I'll also point out that the Redux FAQ explicitly says it's up to you as a developer to decide what state should live in Redux, and what is better suited for local component state: http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... .