Somebody familiar with React is probably going to have to help you.
useState thing creates some magical framework-managed box that persists values across what Angular would call “change detection cycles”. You are apparently populating various incarnations of these boxes with the results of asynchronous events and yet trying to make definitive choices based on snapshots at arbitrary points in time.
To my amateur eyes, that would seem fraught with peril. Unless React provides some sort of guarantee otherwise, I would think that the previous value of each of these “state boxes” would still be in play until some code comes along to overwrite it.
To rephrase what I’m worried about, imagine we have three “sticky” booleans:
delivered. A combination of asynchronous operations populates each. Then, on each successive iteration, the old values are still in there.
Every time I write an arrow function, I mentally think of it as a message in a bottle. That helps me remember that I have ceded control of when it will be executed relative to anything outside its bottle. You have five arrow functions, which I’ll letter A-E in order of appearance. On each run of A, there will theoretically be a point in time where B has resolved, changed
true, C has resolved, set
personalInfo could be absolutely anything, because D hasn’t resolved yet. Your console log won’t tell you anything, unless you know precisely when it is being rendered.
This is why I do my best to flatten future chains, instead of nesting them like you have here. While you wait for better answers from somebody who actually understands React, perhaps it would be worthwhile to try to rearchitect the code so that every single
then is at the same indentation level - no nesting. It might seem harder to write, but I bet it would turn out easier to read, and may expose some implicit assumptions that are burning you.