-
Notifications
You must be signed in to change notification settings - Fork 46.4k
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
Understanding act
behaviour
#15543
Comments
act() isn't concurrent mode compatible yet, I'm afraid. we're working on it. |
Ok, thanks. Do you know if there is any short-term solution (other than using a timeout) to test concurrent behaviour? |
we're still fleshing out what the concurrent mode story will be, so I hesitate to make any recommendation. We're not sure whether we'll even support the |
Ok. I am working on some state-management tools and wanted to make sure they would be compatible with concurrent mode; maybe it is just too early for that. |
I have a PR open that sort of unifies act's behaviour in sync and concurrent mode #15591 you'll probably have to mock the scheduler for it (docs incoming), but most tests should just work. I'll leave this issue open till we land/release it. |
We have a clearer idea now of how we want to treat this (but no official documentation yet). tl;dr you should use a mocked scheduler (and you'll see instructions if you try using act() with a concurrent mode tree). I'm going to close this, but we will have more to say in the near future. |
I have been trying to use
act
for the first time, and having some issues, and so I'm wondering if my expectations are wrong about what it is supposed to do, or if I am "doing it wrong".What is the current behavior?
The only way I can observe the results of state changes I initiate is by using a timeout.
Paste the link to your JSFiddle or CodeSandbox example below:
https://codesandbox.io/s/k5zmln6w83?expanddevtools=1&fontsize=14&hidenavigation=1
What is the expected behavior?
What I expect is that by wrapping a state change or render operation in
act
, all of the resulting state changes / side-effects / re-renders will be complete by the timeact
returns, so that the operation appears (or is coerced to be) synchronous.I created an example (https://codesandbox.io/s/k5zmln6w83?expanddevtools=1&fontsize=14&hidenavigation=1) wherein I render a view via
unstable_ConcurrentMode
. In the view, I create auseState
hook with a value of0
. After the view is rendered, I use that hook's setter to change its state to1
.Below is a log of the steps I take, showing three values at each time:
seenByRender
, the last state-value that appeared within the render body;calculated
, the last value returned from my state-update function; andseenByEffect
, the last value observed from auseEffect
I create in the view.What I am wanting/expecting is for step 4 to look like step 5, ie, I can somehow test the full consequences of my setState call.
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
16.8.6, using unstable_ConcurrentMode
The text was updated successfully, but these errors were encountered: