4 ms·

It's such a dead simple solution that it's never been a problem. Certainly doesn't warrant replacing with all the code and complexity of Redux, which introduce

It's such a dead simple solution that it's never been a problem. Certainly doesn't warrant replacing with all the code and complexity of Redux, which introduces its own demand for testing and QA, and I would argue offsets its own value due to its complexity. In software development simple = understandable and reliable.

lhnz 9y ago
But I just demonstrated that it's not understandable or reliable. You are proposing a solution where any badly written code can affect your global state in a way that you can't control for, and in a way that you will not be able to search for. Eventually you are going to get bugs, and you are going to have a hard time tracking them down for the reasons I've described. It might be okay if you work on small projects without many team members, but in larger projects it's extremely annoying to have these kinds of issues.
- forgottenacc57 9y ago
  I wonder if it's maybe the architecture of my application that means I don't need to store much state, and I only store state that doesn't seem to subject my app to the issues you describe. When I hear about these apps with a heavy reliance on client side state I wonder what the heck they are doing... if you've got so much complex data/logic does it really belong in client state? I'd see it as a problem and try to architect it out, or store it somewhere.
  - lhnz 9y ago
    It's absolutely possible to do something that has the issues I'm describing and never see any bugs because you are disciplined and careful. However, as a contractor, I have worked with plenty of teams where due to horrible deadlines and sloppy practices all of the problems I've described have occurred. Basically: once you climb over the learning curve, Redux helps you here.
- hex13 9y ago
  > Eventually you are going to get bugs, I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux. I think the key to the scalable apps is good architecture (and correct design patterns), not framework. And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated. But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js) Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#generating-reducers http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

lhnz 9y ago

But I just demonstrated that it's not understandable or reliable. You are proposing a solution where any badly written code can affect your global state in a way that you can't control for, and in a way that you will not be able to search for. Eventually you are going to get bugs, and you are going to have a hard time tracking them down for the reasons I've described. It might be okay if you work on small projects without many team members, but in larger projects it's extremely annoying to have these kinds of issues.

forgottenacc57 9y ago
I wonder if it's maybe the architecture of my application that means I don't need to store much state, and I only store state that doesn't seem to subject my app to the issues you describe. When I hear about these apps with a heavy reliance on client side state I wonder what the heck they are doing... if you've got so much complex data/logic does it really belong in client state? I'd see it as a problem and try to architect it out, or store it somewhere.
- lhnz 9y ago
  It's absolutely possible to do something that has the issues I'm describing and never see any bugs because you are disciplined and careful. However, as a contractor, I have worked with plenty of teams where due to horrible deadlines and sloppy practices all of the problems I've described have occurred. Basically: once you climb over the learning curve, Redux helps you here.
hex13 9y ago
> Eventually you are going to get bugs, I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux. I think the key to the scalable apps is good architecture (and correct design patterns), not framework. And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated. But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js) Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#generating-reducers http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...