6 ms·

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redu

> These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably. 3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild. While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.

MuffinFlavored 8y ago
What are some "costs" you think it has?
- mawburn 8y ago
  Redux definitely adds an extra layer of complexity to a project and a lot more boilerplate. That is what lead to Dan's famous blog post "You Might Not Need Redux" from 2016. https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
kokokokoko 8y ago
I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation. The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces. With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance. What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.
- qudat 8y ago
  > I have yet to see a long term project built with Redux that was maintainable. The only maintainable projects I have worked on in terms of web apps have been with Redux. Redux is not great for simple projects, it is great for medium and large scale projects. > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose. React, redux, redux-saga -> this is the recipe for large scale applications that I have used, built, and helped maintain with success. One of the strongest benefits of redux is being able to see every single event in a debugger that displays current state, action payload, next state. It really does make tracking down state changes a matter of reading a global log. Furthermore, because redux is not dependent on react and under the hood it is simply and event emitter, it becomes relatively easy to use the same exact business logic for one web app and use it for some other delivery. We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
  - kerkeslager 8y ago
    > Redux is not great for simple projects, it is great for medium and large scale projects. I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable. > > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. > That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose. I don't need a way to manage side-effects, if I don't use Redux... I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem. > We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic. Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).
kerkeslager 8y ago
1. You're conflating a bunch of terms here, but I think you're referring to global application state changes being treated as a pure function which takes in the global state and event parameters, and returns a new global state. There's nothing stopping you from doing that without Redux; the state = function(state, event) pattern is supported by native JavaScript. If that's not what you're talking about, please clarify. 2. This is only marginally more powerful than a debugger. 3. I would consider this allowing you to shoot yourself in the foot. Explicit is better than implicit, and explicitly defining your dependency tree is a benefit, not a downside. When you're feel the small pain of having to explicitly define a data dependency, that prevents you from introducing it if you don't have to, thereby avoiding the much larger pain of having an overly complex dependency graph. By adding Redux you're adding hours of debugging time on complex global dependencies to save yourself a few seconds worth of keystrokes.
tracker1 8y ago
As an addendum to #3, it's a single state that is passed down as a global/app state. If you break it up with the context api, it can get messy quickly. As to other comments about logic in the View or State, it's bound to happen... the two aren't actually divisive concerns. Personally, I'm happier to use Redux than seeing prop drilling everywhere.

MuffinFlavored 8y ago

What are some "costs" you think it has?

mawburn 8y ago
Redux definitely adds an extra layer of complexity to a project and a lot more boilerplate. That is what lead to Dan's famous blog post "You Might Not Need Redux" from 2016. https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

kokokokoko 8y ago

I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation. The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces. With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance. What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.

qudat 8y ago
> I have yet to see a long term project built with Redux that was maintainable. The only maintainable projects I have worked on in terms of web apps have been with Redux. Redux is not great for simple projects, it is great for medium and large scale projects. > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose. React, redux, redux-saga -> this is the recipe for large scale applications that I have used, built, and helped maintain with success. One of the strongest benefits of redux is being able to see every single event in a debugger that displays current state, action payload, next state. It really does make tracking down state changes a matter of reading a global log. Furthermore, because redux is not dependent on react and under the hood it is simply and event emitter, it becomes relatively easy to use the same exact business logic for one web app and use it for some other delivery. We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
- kerkeslager 8y ago
  > Redux is not great for simple projects, it is great for medium and large scale projects. I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable. > > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. > That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose. I don't need a way to manage side-effects, if I don't use Redux... I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem. > We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic. Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).

kerkeslager 8y ago

1. You're conflating a bunch of terms here, but I think you're referring to global application state changes being treated as a pure function which takes in the global state and event parameters, and returns a new global state. There's nothing stopping you from doing that without Redux; the state = function(state, event) pattern is supported by native JavaScript. If that's not what you're talking about, please clarify. 2. This is only marginally more powerful than a debugger. 3. I would consider this allowing you to shoot yourself in the foot. Explicit is better than implicit, and explicitly defining your dependency tree is a benefit, not a downside. When you're feel the small pain of having to explicitly define a data dependency, that prevents you from introducing it if you don't have to, thereby avoiding the much larger pain of having an overly complex dependency graph. By adding Redux you're adding hours of debugging time on complex global dependencies to save yourself a few seconds worth of keystrokes.

tracker1 8y ago

As an addendum to #3, it's a single state that is passed down as a global/app state. If you break it up with the context api, it can get messy quickly. As to other comments about logic in the View or State, it's bound to happen... the two aren't actually divisive concerns. Personally, I'm happier to use Redux than seeing prop drilling everywhere.