How about sending the selected pet along with the pet data in the FETCH_PET_SUCCESS dispatch, and handing this in the reducer, depending on the selected pet stores in the current state?
That way at least you handle the state all in one place (I must I quite like the 3.5 option too)
This way the UI won't update untill we get back the data, which is fine for the info but may get a poor user experience for the drop down.
All in all this is just a verry simple example to show a possible bug, obviously the code could be a lot better, like validations etc 🙂
Fwiw, to me, this feels cleaner than somehow duplicating the selectedPet state into a useRef.
Also, while the local selectedPet variable I used is not actually needed, I feel it reads better, but YMMV, using pets.selectedPet everywhere would work just as well. First diff would be reduced to:
How about sending the selected pet along with the pet data in the
FETCH_PET_SUCCESS
dispatch, and handing this in the reducer, depending on the selected pet stores in the current state?That way at least you handle the state all in one place (I must I quite like the 3.5 option too)
Not sure i follow, can you post a code snippet?
Something like:
and
This way the UI won't update untill we get back the data, which is fine for the info but may get a poor user experience for the drop down.
All in all this is just a verry simple example to show a possible bug, obviously the code could be a lot better, like validations etc 🙂
Hmm, did you try it? codesandbox.io/s/new-e6gpr
Here's the diff:
and
Aw you kept the
onChange
handler. I thought you meant to omit it and instead "listen" to the "FETCH_PET_SUCCESS" in order to update the drop-down.Fwiw, to me, this feels cleaner than somehow duplicating the
selectedPet
state into auseRef
.Also, while the local
selectedPet
variable I used is not actually needed, I feel it reads better, but YMMV, usingpets.selectedPet
everywhere would work just as well. First diff would be reduced to: