0

I've recently started using React and Redux and there 2 issues I can't quite resolve by my own.

  1. I've implemented login and registration forms, when searching for examples online I found a few examples where the typed username and password weren't processed using Redux, but instead were just stored in the component's state (as if the app was a pure React app, without Redux).

In my login form, I process everything through Redux with reducers and everything, was I wrong or was the random example wrong?

  1. Regarding Redux - let's take this reducer for example: https://gist.github.com/avrahams1/ea74cfa7a9361fdd55ad4bea9d59d07e (I couldn't get SO's code function to work :( ).

It's a reducer for a server call to a teachers API, getting all the teachers from the server. As you can see there are 4 states - not called, pending answer from server, success (with data), fail (with error).

My problem is - in each case I have to explicitly reset the other data, because otherwise once the "loading" flag is set to true it's never set to false, same for the error. Even when the data arrives my component gets stuck on "loading", am I doing something wrong here? How should I reset stuff like the loading and error fields otherwise?

Thanks, Avi.

Avi Sasson
  • 666
  • 7
  • 22

1 Answers1

0

  1. Neither you nor the example you saw were wrong. See here for a more detailed answer. Just because you are using Redux doesn't mean every single piece of data you handle has to be stored in Redux. In the case of the example you saw, its author likely decided that keeping the username & password in the global application state was of no use, and merely wanted to use local state to implement controlled inputs.

  2. Being explicit about state is the foundation of a working state machine. There is nothing wrong with detailing how every piece of data stored in your global state should behave/transition in response to any given action. Quite the opposite, really. This ensures that for any given input (i.e. current state, action type & action payload), the outcome will always be exactly the same - a core concept behind Redux. I see nothing wrong with the code you posted in your gist.

Thomas Hennes
  • 9,023
  • 3
  • 27
  • 36
  • Thank you for the quick response. If I'm not using Redux to handle ALL my data, doesn't that defeat the purpose of using Redux at all? As far as I can understand, you "put up" with Redux's extremely tedious boilerplate to have all your data centralized and to enjoy the ability to "time travel" and reproduce bugs somewhat easily, or did I get it completely wrong? I get that using the state would also work fine, I'm asking about the line of thinking. – Avi Sasson Jan 09 '18 at 19:08
  • 1
    You're welcome. No, I don't think it does, especially not when the data in question is not relevant to your application as a whole. Redux is especially useful for (1) managing state at the application level (meaning any component can (a) subscribe/listen to changes to the data held in state and (b) trigger action that might modify the data held in state) and (2) implementing the predictability of state changes. As you can see, your questions touched on what are, imo, the two central concepts behind Redux. Good job! – Thomas Hennes Jan 09 '18 at 19:17
  • 1
    And no, again, the second statement in your comment is perfectly accurate. But consider this in your example: are the username & password of the user *while they are being entered* of any value to the application? Not really, no. We might not want to even have those values in the application state at any point, maybe we want to store a token that will be returned when the user logs in instead. – Thomas Hennes Jan 09 '18 at 19:20