-
Notifications
You must be signed in to change notification settings - Fork 47.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
setState( obj, callback) - callback called before state has mutated #6455
Comments
@wdiechmann Could you explain why do you want to report the state? I don't see any race condition? |
Does not create a setState-call with a callback that calls console.log, it actually calls setState, then calls console.log and returns the result of console.log as the callback for setState (which is obviously not a calback). So you're doing |
no @syranide - it's not the problem! The state does get updated - eventually but anyways - I'll get by (and @RaitoBezarius - I'm setting state and depending on it in a few instructions later - that's why) ;) the code provided is merely to demo the effect :) |
@wdiechmann Yes, the state gets updated, but your console.log is effectively called before setState is even called. @setState {wurl: w, args: arg}, console.log 'sooner ' + @state.args transpiles to this.setState({
wurl: w,
args: arg
}, console.log('sooner ' + this.state.args)); which is equivalent to var r = console.log('sooner ' + this.state.args);
this.setState({
wurl: w,
args: arg
}, r); or just console.log('sooner ' + this.state.args);
this.setState({
wurl: w,
args: arg
}); |
https://jsfiddle.net/6zed7uuh/ (click on the div) shows the expected behavior, or are you expecting something else? |
hmmm - I see the 'fiddle' - but this snippet does not show the expected behaviour -
I cannot explain the difference - but like I replied - no big deal, I'll just have to setTimer and wait for the enqueuedCallback to finish :) thx for sharing anyway! cheers, |
Somehow a 'scope' change is enough - or whatever it is called - try this for measure:
weird, right?! |
@wdiechmann Your problem is explained in my comments above, you're not providing a callback to setState, you're calling the function and returning the value to be used as a callback (which it isn't). Two wildly different things. |
waooo - !! so a lambda like this
works - I'm not sure I quite see the difference - calling the function or asking setTimer to call it or asking eval to do it inline (the lambda thing) - of which the latter two works - thx again! |
I am fighting what used to be called 'a race condition' - I'm not sure what you guys call it in the React world :)
calling this snippet in a component
proves my point - I trust.
Either it is a 'noob observation - go do this instead' or a documentation glitch (as the docs says that the callback is called once the state is mutated) or, eventually, a bug
Obviously I'm rooting for #1 which would have me on my way in a jiffy - providing someone with a lot more knowledge of React would "stick it to me" so to speak :)
cheers,
Walther
The text was updated successfully, but these errors were encountered: