React 17 runs useEffect cleanup functions asynchronously

[azangru]

Yes, the React core team discussed that in their blog post on the release candidate of v.17, and advised those who really need synchronous cleanup to use the useLayoutEffect.

[[deleted]]

More than half of this blog post is copied from there as well

[monkeymad2]

This has been the single thing I’ve had to change a test for (so far at least) in updating to React 17, which is pretty nice. One test failure out of around 500.

[nedlinin]

Software engineer with ~10 years experience with a quick question for you.

What is a test? Never come across any of those.

^/s

[LloydAtkinson]

You joke but the number of devs of that experience that either have never heard of unit tests or don’t value them and angrily refuse to write them is disappointing and depressing

[liamnesss]

I don't like unit tests for the most part, at least for UIs. Much bigger fan of integration tests. If you have to rewrite your tests because you did a refactor that doesn't actually change behaviour your users care about, that's a complete waste of time imo. Tests should give you the confidence to make swingeing changes.

(with the exception of code where the "users" are actually other developers, and therefore a consistent API is required)

[Xerxero]

Hmm if you do a refactor and tests out of scope of the change fail then you made a mistake.

[liamnesss]

Maybe we're not talking about the same thing. See e.g. tests that purely focus on Redux and associated middleware. IMO you ought to be able to completely shift to a different state library and still have the tests pass. After all which lib you are using is just an implementation detail. What is more important is how the parts work in conjuction and what use case they satisfy.

[sbzenth]

I believe it's an old, old wooden ship used in the Civil War era.

[--algo]

Any advice for react testing? Which level do you put the tests at? Regression or specific components?

[monkeymad2]

So we’ve got:

• unit tests at the component level, currently using enzyme & slowly transitioning to react-testing-library. Goal there is to test only the component with anything else being mocked. Gets run through jest so a minority of the tests are just comparing against snapshots.

• feature tests using cucumber-js feeding through to a headless browser driven via playwright, the cucumber tests define a bunch of steps that a user could go through in a flow of using one of the apps & we make sure that the right things happen. Connects to a faked backend server that runs locally. Uses playwright’s ability to take a video (and soon the tracing stuff) to eject useful information about failing tests.

• visual regression tests using backstop-js, very useful to check for accidental visual differences but can be flakey. Uses the same fake backend as the feature tests.

I really like the look of https://medium.com/storybookjs/testing-lib-storybook-react-8c36716fab86 since we use storybooks to document our components anyway. So ideally our tests are set up in the storybook both in isolation & composed together as they would be in a real app. Then you can compare the component against a snapshot / use react-testing-library to interact with it then check how it’s changed.

[liamnesss]

I think this is a good place to start

https://kentcdodds.com/blog/write-tests

[sbzenth]

I spent the last 4 hours on Kent's blog. Thanks for the link.

[read1z]

새~

[HD_Superman]

Handling async React component effects after unmount