3 ms·

So what problem does Redux solve? From its doc: "It helps you write applications that behave consistently, run in different environments (client, server, and na

So what problem does Redux solve? From its doc: "It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test." Sorry, I am not sold. Can anyone summarize what problem it solves in a short paragraph?

acemarke 10y ago
It's state storage. If you've got any familiarity with Backbone, all of your Models and Collections define the current set of data for your application. You may also have a lot of UI-related state, like which tab is selected, which pane is open, etc. Redux lets you put all that information into one place (although how much or how little of your state goes in there is up to you). It also defines certain conventions around updating that data. In Backbone, anyone with a reference to a Model can call myModel.set("someField", someValue) at any time. In Redux, "write" logic is isolated to a user-defined set of "reducer functions", which only respond to specific types of messages. This makes it _very_ easy to determine when and why a particular bit of data changed. In addition, it enables scenarios such as storing the entire list of dispatched actions, and then playing back each action step-by-step to allow you to see how you got to a given state in your application (aka "time-travel debugging").
delluminatus 10y ago
Redux tries to enforce a convention that all application state is stored in a single object (the "store") and modified using a single pure function (the "reducer"). These conventions make it easier to reason about the application's current state. Applications behave consistently because all state is stored in a single object, so it can't be desynchronized across components. Because all updates use a single function, it becomes easy to track and respond to any state changes by applying middlewares to that function. Things are more testable because all state is available for stubbing, and because the "reducer" is a testable, pure function typically composed of many other smaller, testable pure functions. Things like time travel become possible because of the purity of the reducing function. Since it's pure, it can't modify the old state object (technically, it can, but it's against the rules). So in theory, we can undo any state change simply by loading the old state object from where it's being stored by some kind of history middleware.
RobertKerans 10y ago
It's a method of dealing with the state that is extremely simple. The state is a single immutable object. The bits of your app emit actions, which are just plain JS objects. The state is updated by running a reduce function [on the bit of it you want to update] it in response to the action. That's basically it. The 'easy to test bit' isn't an exaggeration; there is no magic at all, and every component part is extremely basic. Behavior becomes very predictable. The source of truth for the app is moved almost entirely to this state object, all other state/side effects are discouraged wherever possible. The cons (you may/may not see them as such, but..) are a. for a lot of people it is quite difficult to grok at first, b. it's extremely functional, c. it has quite a lot of boilerplate - it is extremely explicit, d. the app state is held in a single immutable object.

acemarke 10y ago

It's state storage. If you've got any familiarity with Backbone, all of your Models and Collections define the current set of data for your application. You may also have a lot of UI-related state, like which tab is selected, which pane is open, etc. Redux lets you put all that information into one place (although how much or how little of your state goes in there is up to you). It also defines certain conventions around updating that data. In Backbone, anyone with a reference to a Model can call myModel.set("someField", someValue) at any time. In Redux, "write" logic is isolated to a user-defined set of "reducer functions", which only respond to specific types of messages. This makes it _very_ easy to determine when and why a particular bit of data changed. In addition, it enables scenarios such as storing the entire list of dispatched actions, and then playing back each action step-by-step to allow you to see how you got to a given state in your application (aka "time-travel debugging").

delluminatus 10y ago

Redux tries to enforce a convention that all application state is stored in a single object (the "store") and modified using a single pure function (the "reducer"). These conventions make it easier to reason about the application's current state. Applications behave consistently because all state is stored in a single object, so it can't be desynchronized across components. Because all updates use a single function, it becomes easy to track and respond to any state changes by applying middlewares to that function. Things are more testable because all state is available for stubbing, and because the "reducer" is a testable, pure function typically composed of many other smaller, testable pure functions. Things like time travel become possible because of the purity of the reducing function. Since it's pure, it can't modify the old state object (technically, it can, but it's against the rules). So in theory, we can undo any state change simply by loading the old state object from where it's being stored by some kind of history middleware.

RobertKerans 10y ago

It's a method of dealing with the state that is extremely simple. The state is a single immutable object. The bits of your app emit actions, which are just plain JS objects. The state is updated by running a reduce function [on the bit of it you want to update] it in response to the action. That's basically it. The 'easy to test bit' isn't an exaggeration; there is no magic at all, and every component part is extremely basic. Behavior becomes very predictable. The source of truth for the app is moved almost entirely to this state object, all other state/side effects are discouraged wherever possible. The cons (you may/may not see them as such, but..) are a. for a lot of people it is quite difficult to grok at first, b. it's extremely functional, c. it has quite a lot of boilerplate - it is extremely explicit, d. the app state is held in a single immutable object.