Repository navigation
'event was not wrapped in act' warning with React 18, react-datepicker and user.type #1231
Description
Relevant code or config:
describe('ReactDatepicker', () => {
beforeEach(() => (user = userEvent.setup()));
it('should not emit act warnings', async () => {
const now = new Date();
const endOfNextYear = new Date(now.getFullYear() + 1, 11, 31);
const dateFormat = 'M/d/yyyy';
const userFormattedDate = format(endOfNextYear, dateFormat);
const defaultFormattedDate = format(endOfNextYear, defaultDateFormat);
render(<ReactDatepicker />);
const input = screen.getByRole('textbox');
await user.type(input, `${userFormattedDate}{Enter}`);
expect(await screen.findByDisplayValue(defaultFormattedDate)).toBeInTheDocument()
});
it('should pass with fireEvent', async () => {
const now = new Date();
const endOfNextYear = new Date(now.getFullYear() + 1, 11, 31);
const dateFormat = 'M/d/yyyy';
const userFormattedDate = format(endOfNextYear, dateFormat);
const defaultFormattedDate = format(endOfNextYear, defaultDateFormat);
render(<ReactDatepicker />);
const input = screen.getByRole('textbox');
fireEvent.change(input, { target: { value: userFormattedDate } });
fireEvent.keyDown(input, { key: 'Enter' });
expect(await screen.findByDisplayValue(defaultFormattedDate)).toBeInTheDocument()
});
});What you did:
use userEvent.type when targeting react-datepicker to enter a date. The weird thing is the "not wrapped in act" error only appears when a valid date is typed and the {Enter} key is pressed. This is apparency causing some special condition to happen within the implementation of react-datepicker which userEvent isn't act wrapping appropriately.
What happened:
console.error
Warning: An update to r inside a test was not wrapped in act(...).
When testing, code that causes React state updates should be wrapped into act(...):
act(() => {
/* fire events that update state */
});
/* assert on the output */
This ensures that you're testing the behavior the user would see in the browser. Learn more at https://reactjs.org/link/wrap-tests-with-act
at r (C:\git\pzaczkiewicz\forge-contrib-react-datepicker-user-event-test-failure\.yarn\__virtual__\react-datepicker-virtual-69b8f1e761\0\cache\react-datepicker-npm-4.16.0-c94778dc5d-59da0305ca.zip\node_modules\react-datepicker\dist\index.js:1:78951)
at ReactDatepicker (C:\git\pzaczkiewicz\forge-contrib-react-datepicker-user-event-test-failure\packages\react-datepicker-user-event-test-failure\src\ReactDatepicker\ReactDatepicker.tsx:7:45)
Reproduction:
https://github.com/pzaczkiewicz-athenahealth/react-datepicker-user-event-test-failure
Problem description:
Not wrapped in act warnings are usually good indications that what you are testing is not what the user sees. Ignoring them may hide bigger issues in tests.
Suggested solution:
Unknown. I dug into testing-library source code and couldn't completely wrap my head around why asyncWrapper and eventWrapper flip-flopped IS_REACT_ACT_ENVIRONMENT.
Activity
pzaczkiewicz-athenahealth commentedon Aug 10, 2023
Similar issue as #1216, but this happens in the middle of
await user.typeinstead of upon unmount.chawes13 commentedon Sep 14, 2023
I'm experiencing this issue as well after upgrading from @testing-library/react@^12 to @testing-library/react@^14 and react@^17 to react@^18.
Here's my stacktrace:
It looks like the function that calls
setStateis coming fromsetOpenon blur of the input.Could it be possible that their use of nested second args to
setState(e.g., https://github.com/Hacker0x01/react-datepicker/blob/3b6ff0163514facbfd6d38a84e1fe874c4388d77/src/index.jsx#L439) is not getting flushed withact? TBH I'm not exactly sure how I would go about testing that theory.Here's another repro (if that's helpful): LaunchPadLab/lp-components#613
chawes13 commentedon Sep 14, 2023
I also tried this with
waitFor(below) as well as invokingcleanupandunmountat the end of this specific test to no avail.pzaczkiewicz-athenahealth commentedon Sep 14, 2023
Good find! That's definitely some non-standard behavior. Hopefully one of the testing-library maintainers is able to figure out what to do.
The error is definitely coming from within
user.type, because I've mocked console.error as such:I can then check for its usage in my test:
I want my tests to fail if a console error happens because they are usually indicative of behavior I need to correct. This is the only way around the bug while still giving me a clean console.
KutynaMateusz commentedon Apr 25, 2024
Any update on this? I'm having a similar issue
josephdangerstewart commentedon Jul 18, 2024
I think it has something to do with blurring the input in that
setStatecallback. Blurring the input triggers more set state calls, which I don't think are being flushed. I managed this minimal repro. I haven't figured out why that produces the warning, but I have noticed a few thingsFirstly, changing
to
Fixes the issue. So we're flushing
setStatecalls made directly within that callback.Secondly, changing that same line to
Also fixes the issue. So we're flushing
setStatecalls made as a result of blurring the input if we blur the input before the state update is applied.I encountered this issue in the context of my own project, but it looks like it also applies to react-datepicker. Here we call
setBlurin the callback to asetStatewhich then blurs an input which has an event handler which then sets some state.josephdangerstewart commentedon Jul 29, 2024
I managed this hack to force the
setStatecallback to be wrapped inact. It resolves the warning in the minimal repro in my previous comment. Judging by the react-datetime code I skimmed, it may be sufficient for the original issuehowever it unfortunately isn't sufficient for my use case. If
callbacktriggers a state update in an effect in a function component, then I still see the warnings. To give a concrete example, my hack doesn't fix this exampleThe set state in the
MinimalReproeffect appears to not be flushed even with my hack forcing the set state callback to be wrapped inactgithub-actions commentedon Aug 27, 2026
🎉 This issue has been resolved in version 16.3.3 🎉
The release is available on:
Your semantic-release bot 📦🚀
pzaczkiewicz-athenahealth commentedon Sep 1, 2026
Wow, thanks @snowystinger. I wrote this so long ago that I had almost forgotten about it. Also funny running into you again in a completely different repo from react-spectrum.