maxjhandsome
/
react
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
react/packages/internal-test-utils/enqueueTask.js

20 lines
486 B
JavaScript
Raw Permalink Normal View History

Convert ReactLazy-test to waitFor pattern (#26304) I'm in the process of codemodding our test suite to the waitFor pattern. See #26285 for full context. This module required a lot of manual changes so I'm doing it as its own PR. The reason is that most of the tests involved simulating an async import by wrapping them in `Promise.resolve()`, which means they would immediately resolve the next time the microtask queue was flushed. I rewrote the tests to resolve the simulated import explicitly. While converting these tests, I also realized that the `waitFor` helpers weren't properly waiting for the entire microtask queue to recursively finish — if a microtask schedules another microtask, the subsequent one wouldn't fire until after `waitFor` had resolved. To fix this, I used the same strategy as `act` — wait for a real task to finish before proceeding, such as a message event.
2023-03-05 00:44:41 +08:00
/**
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @flow
*/
Internal test helpers: Use Node's MessageChannel to queue task (#26345) To wait for the microtask queue to empty, our internal test helpers schedule an arbitrary task using `setImmediate`. It doesn't matter what kind of task it is, only that it's a separate task from the current one, because by the time it fires, the microtasks for the current event will have already been processed. The issue with `setImmediate` is that Jest mocks it. Which can lead to weird behavior. I've changed it to instead use a message event, via the MessageChannel implementation exposed by the `node:worker_threads` module. We should consider doing this in the public implementation of `act`, too.
2023-03-09 04:04:38 +08:00
const {MessageChannel} = require('node:worker_threads');
Convert ReactLazy-test to waitFor pattern (#26304) I'm in the process of codemodding our test suite to the waitFor pattern. See #26285 for full context. This module required a lot of manual changes so I'm doing it as its own PR. The reason is that most of the tests involved simulating an async import by wrapping them in `Promise.resolve()`, which means they would immediately resolve the next time the microtask queue was flushed. I rewrote the tests to resolve the simulated import explicitly. While converting these tests, I also realized that the `waitFor` helpers weren't properly waiting for the entire microtask queue to recursively finish — if a microtask schedules another microtask, the subsequent one wouldn't fire until after `waitFor` had resolved. To fix this, I used the same strategy as `act` — wait for a real task to finish before proceeding, such as a message event.
2023-03-05 00:44:41 +08:00
export default function enqueueTask(task: () => void): void {
Internal test helpers: Use Node's MessageChannel to queue task (#26345) To wait for the microtask queue to empty, our internal test helpers schedule an arbitrary task using `setImmediate`. It doesn't matter what kind of task it is, only that it's a separate task from the current one, because by the time it fires, the microtasks for the current event will have already been processed. The issue with `setImmediate` is that Jest mocks it. Which can lead to weird behavior. I've changed it to instead use a message event, via the MessageChannel implementation exposed by the `node:worker_threads` module. We should consider doing this in the public implementation of `act`, too.
2023-03-09 04:04:38 +08:00
const channel = new MessageChannel();
[Internal tests] Close MessageChannel port to prevent leak (#26357) Node's MessageChannel implementation will leak if you don't explicitly close the port. This updates the enqueueTask function we use in our internal testing helpers to close the port once it's no longer needed.
2023-03-10 00:20:07 +08:00
channel.port1.onmessage = () => {
channel.port1.close();
task();
};
Internal test helpers: Use Node's MessageChannel to queue task (#26345) To wait for the microtask queue to empty, our internal test helpers schedule an arbitrary task using `setImmediate`. It doesn't matter what kind of task it is, only that it's a separate task from the current one, because by the time it fires, the microtasks for the current event will have already been processed. The issue with `setImmediate` is that Jest mocks it. Which can lead to weird behavior. I've changed it to instead use a message event, via the MessageChannel implementation exposed by the `node:worker_threads` module. We should consider doing this in the public implementation of `act`, too.
2023-03-09 04:04:38 +08:00
channel.port2.postMessage(undefined);
Convert ReactLazy-test to waitFor pattern (#26304) I'm in the process of codemodding our test suite to the waitFor pattern. See #26285 for full context. This module required a lot of manual changes so I'm doing it as its own PR. The reason is that most of the tests involved simulating an async import by wrapping them in `Promise.resolve()`, which means they would immediately resolve the next time the microtask queue was flushed. I rewrote the tests to resolve the simulated import explicitly. While converting these tests, I also realized that the `waitFor` helpers weren't properly waiting for the entire microtask queue to recursively finish — if a microtask schedules another microtask, the subsequent one wouldn't fire until after `waitFor` had resolved. To fix this, I used the same strategy as `act` — wait for a real task to finish before proceeding, such as a message event.
2023-03-05 00:44:41 +08:00
}