4 ms·

Great tutorial. I recently published an overview of Redux here - https://medium.com/@guptagaruda/introduction-to-redux-and-mobx-e6fa98b6479 https://medium.com/

Great tutorial. I recently published an overview of Redux here - https://medium.com/@guptagaruda/introduction-to-redux-and-mobx-e6fa98b6479 https://medium.com/@guptagaruda/introduction-to-redux-and-mo...

krishanath 9y ago
Holding application state in a tree is nothing new. It is as old as software development itself. You don't need Redux for that. Actions and reducers are not solving any problems. If your application needs undo/redo then that's understandable otherwise get/set methods are all you need.
- guptagaruda 9y ago
  Redux is just one piece of the puzzle. Let me try to explain the problem it solves. Let's say if you are building a complex SPA with lot of UI components in the view and state changes impacts several parts of the view. You can build this view in several ways: * Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters. * AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows. * React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable. I am not saying all these things are needed for every SPA app out there. But these optimizations are needed for complex and performance sensitive applications. Check this out - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... Also, I know keeping application state as a single state tree is nothing new. I started this side project (https://github.com/guptag/FinCharts https://github.com/guptag/FinCharts) almost four years ago with React/Immutable.js without any state management libraries (recently moved to electron from nodewebkit). But this code won't scale in large teams (entire ui state is declared in one file, cannot extend the functionality like Redux's middleware support etc).
  - whitefish 9y ago
    None of these problems are unique to web development. How do you solve these problems in iOS? In iOS you use MVC, and the Application object holds the state as a tree. MVC has a better solution to all these problems.
    - eropple 9y ago
      I'll ask you the same question I asked the sibling: how do you trace and replay state changes during debugging? ('Cause this is why we use Redux.)
      - allover 9y ago
        Being able to do so is certainly a cool feature. But I've built a lot of apps prior to Redux and never felt like state replays were a must for debugging. There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
        eropple 9y ago
        Yeah, you can use breakpoints, but...that's awful. Like, it feels like crap to do, you end up stuck in half-transactions and other nonsense because you have no better options. The use of Redux (or any other functionally-oriented action-based state system, I was writing them in Java and C# long before I ever used Redux) enables powerful stuff that, yeah, might not be a "must"--but being a "must" and being a transformatively powerful tool that requires very little cognitive overhead to leverage aren't that far off.
  - krishanath 9y ago
    No, if you get/set methods that doesn't imply javascript with jquery! I am using React, but not ReactRouter or Redux. I hold my application state in a tree, and the tree nodes have get/set methods. My state tree is not immutable. I think "immutable way of changing state" is an oxymoron.

krishanath 9y ago

Holding application state in a tree is nothing new. It is as old as software development itself. You don't need Redux for that. Actions and reducers are not solving any problems. If your application needs undo/redo then that's understandable otherwise get/set methods are all you need.

guptagaruda 9y ago
Redux is just one piece of the puzzle. Let me try to explain the problem it solves. Let's say if you are building a complex SPA with lot of UI components in the view and state changes impacts several parts of the view. You can build this view in several ways: * Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters. * AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows. * React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable. I am not saying all these things are needed for every SPA app out there. But these optimizations are needed for complex and performance sensitive applications. Check this out - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... Also, I know keeping application state as a single state tree is nothing new. I started this side project (https://github.com/guptag/FinCharts https://github.com/guptag/FinCharts) almost four years ago with React/Immutable.js without any state management libraries (recently moved to electron from nodewebkit). But this code won't scale in large teams (entire ui state is declared in one file, cannot extend the functionality like Redux's middleware support etc).
- whitefish 9y ago
  None of these problems are unique to web development. How do you solve these problems in iOS? In iOS you use MVC, and the Application object holds the state as a tree. MVC has a better solution to all these problems.
  - eropple 9y ago
    I'll ask you the same question I asked the sibling: how do you trace and replay state changes during debugging? ('Cause this is why we use Redux.)
    - allover 9y ago
      Being able to do so is certainly a cool feature. But I've built a lot of apps prior to Redux and never felt like state replays were a must for debugging. There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
      - eropple 9y ago
        Yeah, you can use breakpoints, but...that's awful. Like, it feels like crap to do, you end up stuck in half-transactions and other nonsense because you have no better options. The use of Redux (or any other functionally-oriented action-based state system, I was writing them in Java and C# long before I ever used Redux) enables powerful stuff that, yeah, might not be a "must"--but being a "must" and being a transformatively powerful tool that requires very little cognitive overhead to leverage aren't that far off.
- krishanath 9y ago
  No, if you get/set methods that doesn't imply javascript with jquery! I am using React, but not ReactRouter or Redux. I hold my application state in a tree, and the tree nodes have get/set methods. My state tree is not immutable. I think "immutable way of changing state" is an oxymoron.