Error thrown when using react hooks

[tgandrews]

Description

Given a react component using hooks
When a you attempt to use a user event e.g. type
Then you receive the error below

Warning: An update to %s inside a test was not wrapped in act(...).

Reason

As far as I understand this is because we are using the fireEvent from @testing-library/dom directly and not from @testing-library/react which means that it is not being in act.

Solution

A possible solution would be to allow for the user to provide a fireEvent implementation or allow for this to be configured in test setup

[Gpx]

I'm waiting for testing-library/react-testing-library#281 to be closed to decided what to do here. Also, following #119 we might add support to Vue which would prevent us from importing from @testing-library/react.

For now, I prefer not to address this issue, but it's something I want to get solved in the near future.

Thanks for bringing it up!

[tgandrews]

Yes, I agree adding a direct dependency on react-testing-library is not a good solution.

Would it be possible to expose an API to configure it? Similar to how enzyme exposes a way of defining the react version adapter. So I could set this up once and the tests wouldn't have to care.

[Gpx]

I'd rather not have any configuration if possible. I prefer to wait for the two issues I mention to be resolved before doing anything here

[pietmichal]

How about dividing user-event into multiple flavours? e.g. user-event-react, user-event-vue, user-event-dom etc.?

[pietmichal]

@Gpx, testing-library/react-testing-library#281 has been closed.

[calebeby]

I think now is a good time to reconsider this.

React testing library and Vue testing library both expose their own customized versions of fireEvent that integrate with their libraries to ensure that updates get flushed.

@Gpx would you consider an API like this?

// In test setup file
import user from 'user-event'
import { fireEvent } from 'react-testing-library'

user.customFireEvent(fireEvent)
// or `configureFireEvent`
// or `customizeFireEvent`

// Test file
import user from 'user-event'
import { render } from 'react-testing-library'

test('foo', () => {
  const { getByText } = render(...)
  // React updates are wrapped in `act` automatically!
  user.type(getByText('asdf'), 'invalid text')
  expect(getByText('Submit')).toBeDisabled()
})

cc @kentcdodds @afontcu I'm curious what you think as well

[kentcdodds]

That looks reasonable to me.

[afontcu]

I believe there are three (main) paths here. Some food for thought:

1. Keep user-event as is, trying to provide as much compatibility to different frameworks as possible. They are not that different after all.
2. As @calebeby suggested, provide a way for RTL/VTL/ATL and others to integrate their own fireEvent version into user-event.
3. Bundle user-event with DOM Testing Library. DTL has become the source of truth for the whole Testing Library ecosystem (and that's great), so this option would keep things as consistent as possible.

[calebeby]

@afontcu For option 3, would that mean that RTL/VTL/etc would each re-export their own copy of user-event, just like they currently re-export modified copies of fireEvent?

[kentcdodds]

I'm not sure how I feel about option 3. user-event only exposes 3 methods. I think I'd rather see it more mature and cover more use cases.

I'll add that if you're seeing act warnings, it's not because user-event doesn't handle act. Actually, the fact that fireEvent is wrapped by act is technically unnecessary because React already automatically flushes effects after it calls event handlers.

For example: https://github.com/kentcdodds/user-event-act (no act warnings happen in those tests).

So as long as you're using RTL's async utilities then you should be solid. Often I find that these warnings show up when someone has a test that doesn't wait for side-effects to finish (like having one test that verifies that a loading spinner shows up, but doesn't wait for the loading to actually complete and does that in another test. These tests should be combined... I think I'll blog about this today).

So the urgency for me on this issue is very low because I don't think it should be even necessary.

[Gpx]

So as long as you're using RTL's async utilities then you should be solid. Often I find that these warnings show up when someone has a test that doesn't wait for side-effects to finish

That's what I noticed too. I'm not sure we should do anything in this issue unless someone can provide an example of a test that would be fixed by wrapping fireEvent into act. Once we have that we can consider our alternative. I personally like @calebeby's API.

[bowernite]

I think there's a use case that still necessitates events to be wrapped in act.

If using a third-party library that triggers async logic that you have no method of awaiting, the act warning seems to show up.

As a concrete example, I'm referring to the validate function of react-hook-form. Since the state update that eventually occurs when the library validates an input is asynchronous, the state update eventually happens outside of an act call (or at least that's what my guess is).

I've tested it and this works with no errors:

fireEvent.click(checkbox)

And this console.errors the act warning:

userEvent.click(checkbox)

If there's a RTL async utility that I should be using and am just missing here, I'm all ears 🙂

[mdjastrzebski]

I have same issue of act warnings when using both user-event and react-hook-form with it's async form validation. The only workaround I've found is wrapping userEvent.type() with act() calls. I am not sure whether the issue is actually with user-event or react-hook-forms.

My general observation is that if I use userEvent.type(input, 'some text) early in the test, and later there are couple of other async actions (like mocked network calls, but not other user-event actions) & related await wait() calls then the act warning does NOT appear. However in shorter tests the act warning appears and I actually have to wrap my user-event actions with act() calls.

[kentcdodds]

If someone could make a codesandbox that shows two tests (one that wraps userEvent.click in act and the other that doesn't and shows the warning) that would be helpful :)