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

Should act() warnings be deduplicated by component stack? #19416

Open
eps1lon opened this issue Jul 20, 2020 · 0 comments
Open

Should act() warnings be deduplicated by component stack? #19416

eps1lon opened this issue Jul 20, 2020 · 0 comments

Comments

@eps1lon
Copy link
Collaborator

eps1lon commented Jul 20, 2020

React version: 16.13.1 (latest) and 0.0.0-7f28234f8 (next)

Steps To Reproduce

  1. Create component that has multiple effects (i.e. useEffect calls)
  2. Render component in a jest test

Link to code example: https://codesandbox.io/s/long-sound-xhe5w?file=/package.json

The current behavior

A error is logged for each call of useEffect.

The expected behavior

An error per component calling useEffect.

Context

Current errror:

Warning: An update to Component ran an effect, but 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://fb.me/react-wrap-tests-with-act
    at Component (https://xhe5w.csb.app/src/index.test.js:23:20)
    at App (https://xhe5w.csb.app/src/index.test.js:35:20)

The prescription is to wrap the update in act(). The warning may be unintented because a component with an effect rendered unexpectedly. But due to the rules of hooks it's unlikely that we remove a useEffect call: It's easier to prevent rendering a component (wrong branch logic, return early etc) than preventing an effect (which requires moving it to a component we render conditionally).

From my experience most of these cases come down to adding an act() and not changing component implementation. In these cases firing errors for each effect makes the console output unreadable. Especially if you compose custom hooks and end up with 4+ effects per component.

An alternate solution would be to only fire an error if the effect was actually scheduled (see #19318).

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

1 participant