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

Having to use an empty act immediately after render to avoid warning #1066

Closed
leepowellnbs opened this issue Aug 18, 2022 · 7 comments
Closed
Labels
question Further information is requested

Comments

@leepowellnbs
Copy link

leepowellnbs commented Aug 18, 2022

I have a component, which does some async loading of data from various sources - some coming from within the component itself, and some coming from a wrapped context - all take place in useEffect hooks. I'm finding I'm having to use empty act calls to avoid the act warning - contrived example:

const screen = render(<MyComponent />, { wrapper: <MyContextProviders />});

expect(await screen.findByText('Hello')).toBeTruthy();

In this example I get the "not wrapped in an act" warning from where one of the context providers is fetching data on mount. The odd thing, is the component doesn't render Hello until this data fetching is finished and the fetched data is available.

To suppress the error I am having to add an empty act:

const screen = render(<MyComponent />, { wrapper: <MyContextProviders />});

await act(async () => {});

expect(await screen.findByText('Hello')).toBeTruthy();

I have no idea why but this seems to work. Could anyone help me understand why this works, or if there is a better way of doing this - as it feels a bit hacky. Thanks.

EDIT: Just remembered, the data loading function called by the provider is async - and once the data resolves it sets state, which is what is seemingly triggering the act warning.

@leepowellnbs leepowellnbs added the question Further information is requested label Aug 18, 2022
@mdjastrzebski
Copy link
Member

@leepowellnbs can you post a minimal repro repository that showcases the issue & fix?

@leepowellnbs
Copy link
Author

@mdjastrzebski sure I'll try to pull one together - I was trying to do so yesterday when I came across this strange behaviour #1067

@mdjastrzebski
Copy link
Member

@leepowelldev could you check if this issue still occurs with RNTL v11.2.0?

@jake-carpenter
Copy link

I'm also seeing this issue in RNTL v9.1.0 with Jest 26.6.3 after upgrading to RN 0.69 (using Expo SDK 46). I don't mean to hijack this discussion - let me know if this warrants discussion and another ticket.

We've previously moved away from queries like await waitForElementToBeRemoved(() => view.getByLabelText('Loading')) in favor of await view.findByLabelText('Foo') which would wait for loading state go go away. Now a huge chunk of tests that do this are actually failing, not just throwing the warning about using act(). This hack solves the problem, but clearly it's not ideal.

Is there a workaround for older versions of RNTL? I'm unable to upgrade at the moment thanks to a package using RN Reanimated.

@AugustinLF
Copy link
Collaborator

Is there a workaround for older versions of RNTL

That's going to be complicated, because RN 0.69 comes with react 18 which uses a different model for act, and we had to change quite a bit of things for it. You could try using a patch package and reimplement the changes, but that sounds like quite a hassle.

Regarding you RN reanimated issue, could a global mock work?

@jake-carpenter
Copy link

That's going to be complicated, because RN 0.69 comes with react 18 which uses a different model for act, and we had to change quite a bit of things for it. You could try using a patch package and reimplement the changes, but that sounds like quite a hassle.

Regarding you RN reanimated issue, could a global mock work?

That's what I was afraid of. I'll move forward with using this act() hack to hide my problem for now, but probably get started on removing my dependency on react-native-reanimated, unless their fix gets merged soon.

@mdjastrzebski
Copy link
Member

Closing as original issue hasn't seen any action since August.

@leepowellnbs if the issue still occurs to you pls create a new issue with minimal repro repo based on our examples/basic.

@jake-carpenter Pls create a separate issue with minimal repro repo if needed.

@mdjastrzebski mdjastrzebski closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants