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