Since this.setState has a callback, it would be sweet if you could use await this.setState!
Duplicate of https://github.com/facebook/react/issues/2642
@ccorcos Can you please elaborate by giving more possible reason on how much it would be effective using await this.setState()?
Not sure I understand your question.
It would be better to use setState with async/await
@ccorcos I am asking for the reason to use setState with async/await
@be-grittier Can you please give me a advantage of doing so mate?
ในวันที่ พ. 5 มิ.ย. 2019 11:56 น. priyajainSE notifications@github.com
เขียนว่า:
@be-grittier https://github.com/be-grittier Can you please give me a
advantage of doing so mate?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react/issues/6179?email_source=notifications&email_token=AKB7KA3LIKTYDS53LVAGG4TPY5BO3A5CNFSM4B5EAS7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW6S52Y#issuecomment-498937579,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKB7KA7J7D4QXQFMVZZEIQTPY5BO3ANCNFSM4B5EAS7A
.
I just googled this out, since I ran into the same problem / question.
Since I'm here, and a lot people are asking for example, here's mine:
I have a method in which I'm obtaining some data from a service (separate component that talks to some API), and of course, it's going async. Right before I trigger that async call, I'm setting a nonce (random string) in the component's state and the local nonce (in the method's context) with the same value. After the service returns complete from that async call, I check if the local nonce and the nonce from state are the same - because, in case they aren't, I invalidate (do nothing) with that data (since that means that the user triggered another service call in the meantime (while the previous was already happening) - and I don't want to render unwanted data / render twice / or I just want to render data based on the latest user's decision).
So, If I do this.setState({nonce: randomStringValue}) before that service (async) call, and then right below after it finishes I compare the local nonce with that from state, it happens that the state nonce is not yet set (not sure why it took it so long, even though there was an async call in between, and I totally don't care, it's the way React store state asynchronously and I shouldn't dive into the implementation for this cause).
If I want to make sure that the nonce in state is updated, the rest of the code below the service call I'm doing must then be placed into the setState's callback function setState({nonce: randomStringValue}), () => { ... the rest of the code ... }).
If I have a lot of things that happen after that service call, all of that would go into that callback function, and it wouldn't look that much readable as if it would be by using an await in front of the setState.
Of course, I went into making my own wrapper function for handling this with a Promise, for which I'm then using async/await (or I could be using .then), and it works as expected. But the setState function itself could be a Promise itself.
Here's that wrapper function in a separate helpers module:
export function setStateAsync(state, context) {
return new Promise((resolve) => {
context.setState(state, resolve)
});
}
Here I am using it just as I would be using this.setState :
// Nonce to invalidate the API call if multiple async fetches happen.
const localNonce = nonce();
await setStateAsync({
fetchPackagesNonce: localNonce
}, this);
const serviceResponse = await Service.getSomething({key: value});
if (localNonce !== this.state.fetchPackagesNonce) {
LoggingService.log(localNonce, "local nonce: ");
LoggingService.log(this.state.fetchPackagesNonce, "state nonce: ");
return StringMessage.invalidNonce; // "Invalid nonce."
}
// ... the rest of the code that manipulates with the data from the response above.
For me, it's a simple matter of if logic.
myFunc = () => {
if (something) {
this.setState({ mykey: myvalue });
}
anotherFunc();
}
anotherFunc() should be run after the state has updated, but the state may not always be updated before. This is a simple example, but in our application it's a bit more complex and by using the setState callback, the code gets pretty messy. Since setState is async anyway, it might as well be compatible with await..
Most helpful comment
Duplicate of https://github.com/facebook/react/issues/2642