Redux Store Doesn't "Store" State?

Tell us what’s happening:
I’ve completed the challenge, and now I’m playing around with dispatch(), getState() to map out its behavior and try to understand what they’re doing.

As you can see in the code, I’ve modified the state returned by the reducer so that each time it returns a state, there’s a key: value pair in it that allows me to log what the Redux store is spitting out. For example, {authenticated: true, a: 123}.

I send out multiple dispatches to the store. I use the getState() on the store and log the outcome. It seems getState() only returns the most recent state that the store processed. My question is: how is this useful?

If the reducer, in principle, should not directly modify the app’s state, instead it spits out a copy of a part of its state, then how does the global state of the app get updated? The Redux store doesn’t keep a copy of everything the reducer churns out. All the “state” objects get lost except for the most recent one. So if multiple users login and logout, all that information is being lost. How is the Redux store a “store” of anything?

Does this get answered in the Redux-React section?

Thanks.

Your code so far


const defaultState = {
  authenticated: false
};

const authReducer = (state = defaultState, action) => {
  // change code below this line
  switch(action.type){
    case "LOGIN":
      return {authenticated: true, a: 123};
    case "LOGOUT":
      return {authenticated: false, b: 321};
    default:
      return state;
  }
  // change code above this line
};

const store = Redux.createStore(authReducer);

const loginUser = () => {
  return {
    type: 'LOGIN'
  }
};

const logoutUser = () => {
  return {
    type: 'LOGOUT'
  }
};

store.dispatch(loginUser());
store.dispatch(logoutUser()); 
store.dispatch(loginUser());
let test = store.getState();
console.log(test.a);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36.

Link to the challenge:

Well if you log each time you dispatch, it logs the change each time. You’re logging once after a series of modifications, so you see the result of that series of modifications.

Edit:

So if multiple users login and logout, all that information is being lost.

It is a store for the state of a front-end app, and this is a very simple (but perfectly realistic) example. If there are multiple users logged into that one frontend that’s a highly complex situation (think Google docs with live multi-user editing capabilities). The example is not trying to simulate that, it’s simulating a normal situation where a user logs into a front end client and has some state relating to them when they are logged in (ie most applications that require authorisation).

I feel like this is the thing that is confusing you most of all, and I think you just are misunderstanding how stuff works. If I log into, say, Facebook, it is using a pattern extremely similar to Redux to store various bits of state relating to what I am currently doing in the app at any one time. The fact that there are a billion other users also logged in is completely irrelevant

In this case, if I have an app where I run login with another set of creds, and it works, and authorises me, it better damn well overwrite the previous creds

1 Like

I send out multiple dispatches to the store. I use the getState() on the store and log the outcome. It seems getState() only returns the most recent state that the store processed.

When you use getState, you are getting the state as in the current state. You are talking about the undo history. There are packages that allow you to deal with that. But most people only care about the current state.

My question is: how is this useful?

I don’t understand that question. That would be like asking: I can’t see how the inside of my car engine works. How is that useful? Or: My car can’t float on water. How is that useful?

If you want to see the inner workings of the store, then you’ll need some kind of package. I haven’t tried them because even though I use redux professionally, I’ve never felt the need.

The Redux store doesn’t keep a copy of everything the reducer churns out.

Yes it does, for it’s own inner workings. Again, don’t confuse the store with the current state.

All the “state” objects get lost except for the most recent one.

Again, no. If your need is to keep track of every interaction - like say every log in - then you ideally would modify your reducer or (better yet) store that info in a DB. Redux is for app state.

1 Like

Ah, I see. It wasn’t making sense to me because the example only has 1 reducer keeping track of 1 state. I was trying to think of how it would handle multiple types of incoming data, not just 1 user: login or logout.

My initial conception of the reducer was that it would contain one giant object containing a log of all the data, and I was trying to figure out how to access this log that I cannot see (and if I can’t see it, I start to wonder what it’s actually doing - simply passing the challenge doesn’t help me understand what it’s doing).

The Redux: Combine Multiple Reducers challenge makes this clearer.