Skip to content
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

Closed
mhuebert opened this issue Apr 30, 2019 · 6 comments
Closed

Understanding act behaviour #15543

mhuebert opened this issue Apr 30, 2019 · 6 comments

Comments

@mhuebert
Copy link

mhuebert commented Apr 30, 2019

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 time act 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 a useState hook with a value of 0. After the view is rendered, I use that hook's setter to change its state to 1.

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; and seenByEffect, the last value observed from a useEffect I create in the view.

1. before act/render:   seenByRender: null, calculated: null, seenByEffect: null
2. after act/render:    seenByRender: 0,    calculated: null, seenByEffect: 0
3. ---incrementing with act/setState---
4. after act/increment: seenByRender: 0,    calculated: 1,    seenByEffect: 0
5. after timeout:       seenByRender: 1,    calculated: 1,    seenByEffect: 1

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

@threepointone
Copy link
Contributor

act() isn't concurrent mode compatible yet, I'm afraid. we're working on it.

@mhuebert
Copy link
Author

mhuebert commented May 2, 2019

Ok, thanks. Do you know if there is any short-term solution (other than using a timeout) to test concurrent behaviour?

@threepointone
Copy link
Contributor

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 unstable_ConcurrentMode component. maybe you could write your tests in regular sync mode?

@mhuebert
Copy link
Author

mhuebert commented May 2, 2019

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.

@threepointone
Copy link
Contributor

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.

@threepointone
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants