4 ms·

Having never worked with Redux, what is its point? Is it really so hard to stick app state in a JS object and databind off that?

by tomc1985 8y ago

acemarke 8y ago
Yes and no. The main point of Redux is to make your state updates predictable and traceable throughout the codebase. Sure, you can create a global object and stuff your data in there. But, if any random part of the app is allowed to modify that object at any time, then it's a lot harder to understand how your app got into a particular end situation. Redux is based on the "Flux Architecture" concept, and asks you to follow restrictions on how you structure your logic. Only certain functions are allowed to update the state, and in order to run that logic, you create plain JS objects called "actions" that describe some event or update that needs to occur, and ask the update logic to determine the new state values in response. This adds a level of indirection to your code, but it provides a way to log and trace when, where, why, and how a given piece of state got updated. If you've got about 45 minutes, I did a "Redux Fundamentals" presentation at Reactathon a few months ago that walks through the basic principles of Redux. Here's a link to the video and the slides: https://blog.isquaredsoftware.com/2018/03/presentation-reactathon-redux-fundamentals/ https://blog.isquaredsoftware.com/2018/03/presentation-react...
danenania 8y ago
In a simple app, no. In a really big app with tons of interdependent, asynchronously loaded state? Have fun. Redux definitely has too much boilerplate, but it does an excellent job of keeping functionality decoupled, and on a big project this ends up being way more important. When you do it right, you rarely introduce regressions when working on new features, because almost everything you do is additive: you're adding new state, new actions, new selectors, new sagas, etc., without touching any pre-existing functionality or anything that pre-existing functionality depends on. The alternative is playing an endless game of whack-a-mole as an app gets too large for anyone to keep track of what depends on what.
- molszanski 8y ago
  > The alternative is playing an endless game of whack-a-mole as an app gets too large An alternative is another state management library.
  - danenania 8y ago
    Yeah sorry, I didn't mean to imply that redux is the only option. I meant that whack-a-mole is the alternative to using some sort of robust state management approach.

Having never worked with Redux, what is its point? Is it really so hard to stick app state in a JS object and databind off that?

acemarke 8y ago

Yes and no. The main point of Redux is to make your state updates predictable and traceable throughout the codebase. Sure, you can create a global object and stuff your data in there. But, if any random part of the app is allowed to modify that object at any time, then it's a lot harder to understand how your app got into a particular end situation. Redux is based on the "Flux Architecture" concept, and asks you to follow restrictions on how you structure your logic. Only certain functions are allowed to update the state, and in order to run that logic, you create plain JS objects called "actions" that describe some event or update that needs to occur, and ask the update logic to determine the new state values in response. This adds a level of indirection to your code, but it provides a way to log and trace when, where, why, and how a given piece of state got updated. If you've got about 45 minutes, I did a "Redux Fundamentals" presentation at Reactathon a few months ago that walks through the basic principles of Redux. Here's a link to the video and the slides: https://blog.isquaredsoftware.com/2018/03/presentation-reactathon-redux-fundamentals/ https://blog.isquaredsoftware.com/2018/03/presentation-react...

danenania 8y ago

In a simple app, no. In a really big app with tons of interdependent, asynchronously loaded state? Have fun. Redux definitely has too much boilerplate, but it does an excellent job of keeping functionality decoupled, and on a big project this ends up being way more important. When you do it right, you rarely introduce regressions when working on new features, because almost everything you do is additive: you're adding new state, new actions, new selectors, new sagas, etc., without touching any pre-existing functionality or anything that pre-existing functionality depends on. The alternative is playing an endless game of whack-a-mole as an app gets too large for anyone to keep track of what depends on what.

molszanski 8y ago
> The alternative is playing an endless game of whack-a-mole as an app gets too large An alternative is another state management library.
- danenania 8y ago
  Yeah sorry, I didn't mean to imply that redux is the only option. I meant that whack-a-mole is the alternative to using some sort of robust state management approach.