From c900c5a06353d9d7915ceccc80e89f5e0dd9994e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ernesto=20Garc=C3=ADa?= Date: Thu, 22 Mar 2018 16:56:16 -0300 Subject: [PATCH 1/2] Add FAQ section about how flushPromises work --- README.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README.md b/README.md index 1c1e3228..abaff86a 100644 --- a/README.md +++ b/README.md @@ -345,6 +345,14 @@ That's not to say that there's never a use case for doing those things, so they should be possible to accomplish, just not the default and natural way to test react components. +**How does `flushPromises` work and why would I need it?** + +As mentioned [before](#flushpromises), `flushPromises` uses [`setImmediate`][set-immediate] to schedule resolving a promise after any pending tasks in the message queue are processed. This includes any promises fired before in your test. + +If there are promise callbacks already in javascript's message queue pending to be processed at the time `flushPromises` is called, then these will be processed before the promise returned by `flushPromises` is resolved. So when you `await flushPromises()` the code immediately after it is guaranteed to occur after all the side effects of your async requests have ocurred. This includes any data your test components might have requested. + +This is useful for instance, if your components perform any data requests and update their state with the results when the request is resolved. It's important to note that this is only effective if you've mocked out your async requests to resolve immediately (like the axios mock we have in the examples). It will not `await` for promises that are not already resolved by the time you attempt to flush them. + ## Other Solutions In preparing this project, @@ -421,3 +429,4 @@ MIT [twitter-badge]: https://img.shields.io/twitter/url/https/github.com/kentcdodds/react-testing-library.svg?style=social [emojis]: https://github.com/kentcdodds/all-contributors#emoji-key [all-contributors]: https://github.com/kentcdodds/all-contributors +[set-immediate]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate From 7924562a73ebdb7b598d1f4e4078471b983ad9ca Mon Sep 17 00:00:00 2001 From: "Kent C. Dodds" Date: Thu, 22 Mar 2018 14:04:59 -0600 Subject: [PATCH 2/2] Some subtle changes --- README.md | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index abaff86a..9aca0618 100644 --- a/README.md +++ b/README.md @@ -347,11 +347,24 @@ react components. **How does `flushPromises` work and why would I need it?** -As mentioned [before](#flushpromises), `flushPromises` uses [`setImmediate`][set-immediate] to schedule resolving a promise after any pending tasks in the message queue are processed. This includes any promises fired before in your test. - -If there are promise callbacks already in javascript's message queue pending to be processed at the time `flushPromises` is called, then these will be processed before the promise returned by `flushPromises` is resolved. So when you `await flushPromises()` the code immediately after it is guaranteed to occur after all the side effects of your async requests have ocurred. This includes any data your test components might have requested. - -This is useful for instance, if your components perform any data requests and update their state with the results when the request is resolved. It's important to note that this is only effective if you've mocked out your async requests to resolve immediately (like the axios mock we have in the examples). It will not `await` for promises that are not already resolved by the time you attempt to flush them. +As mentioned [before](#flushpromises), `flushPromises` uses +[`setImmediate`][set-immediate] to schedule resolving a promise after any pending +tasks in +[the message queue](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) +are processed. This includes any promises fired before in your test. + +If there are promise callbacks already in JavaScript's message queue pending to be +processed at the time `flushPromises` is called, then these will be processed before +the promise returned by `flushPromises` is resolved. So when you +`await flushPromises()` the code immediately after it is guaranteed to occur after +all the side effects of your async requests have ocurred. This includes any data +your test components might have requested. + +This is useful for instance, if your components perform any data requests and update +their state with the results when the request is resolved. It's important to note +that this is only effective if you've mocked out your async requests to resolve +immediately (like the `axios` mock we have in the examples). It will not `await` +for promises that are not already resolved by the time you attempt to flush them. ## Other Solutions