mediawiki-extensions-Popups/tests/node-qunit/wait.test.js

60 lines
1.4 KiB
JavaScript
Raw Normal View History

import wait from '../../src/wait';
QUnit.module( 'ext.popups/wait' );
QUnit.test( 'it should resolve after waiting', function ( assert ) {
assert.expect( 1, 'All assertions are executed.' );
Update: cancel unused HTTP requests in flight Whenever an HTTP request sequence is started, i.e. wait for the fetch start time, issue a network request, and return the result, abort the process if the results are known to no longer be needed. This occurs when a user has dwelt upon one link and then abandoned it either during the fetch start wait time or during the fetch network request itself. This change is accomplished by preserving the pending promises in two actions, LINK_DWELL and FETCH_START, and whenever the ABANDON_START action is issued, it now aborts any previously pending XHR-like promise, called a "AbortPromise" which is just a thenable with an abort() method. There is a similar concept in Core: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/ecc812f06e7dff587b3f31dc18189adbf4616351/resources/src/mediawiki.api/index.js. Aborting pending requests has big implications for client and server logging as requests are quickly canceled, especially on slower connections. These differences can be observed on the network tab of DevTools and the log in Redux DevTools. Consider, for instance, the scenario of dwelling upon and quickly abandoning a single link prior to this patch: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_END STATSV_LOGGED ABANDON_END EVENT_LOGGED FETCH_COMPLETE And after this patch when the fetch timer is canceled (prior to an actual network request): BOOT EVENT_LOGGED LINK_DWELL ABANDON_START ABANDON_END EVENT_LOGGED In the above sequence, FETCH_* and STATSV_LOGGED actions never occur. And after this patch when the network request itself is canceled: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_FAILED STATSV_LOGGED FETCH_COMPLETE ABANDON_END EVENT_LOGGED FETCH_FAILED occurs intentionally, STATSV_LOGGED and FETCH_COMPLETE still happen even though the fetch didn't complete successfully, and FETCH_END doesn't. Additionally, since less data is transmitted, it's possible that the timing and success rate of logging will improve on low bandwidth connections. Also, this patch tries to revise the JSDocs where possible to support type checking and fix a call to the missing assert.fail() function in changeListener.test.js. Bug: T197700 Change-Id: I9a73b3086fc8fb0edd897a347b5497d5362e20ef
2018-06-25 13:26:11 +00:00
const then = Date.now();
return wait( 150 ).then( () => {
assert.strictEqual(
Update: cancel unused HTTP requests in flight Whenever an HTTP request sequence is started, i.e. wait for the fetch start time, issue a network request, and return the result, abort the process if the results are known to no longer be needed. This occurs when a user has dwelt upon one link and then abandoned it either during the fetch start wait time or during the fetch network request itself. This change is accomplished by preserving the pending promises in two actions, LINK_DWELL and FETCH_START, and whenever the ABANDON_START action is issued, it now aborts any previously pending XHR-like promise, called a "AbortPromise" which is just a thenable with an abort() method. There is a similar concept in Core: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/ecc812f06e7dff587b3f31dc18189adbf4616351/resources/src/mediawiki.api/index.js. Aborting pending requests has big implications for client and server logging as requests are quickly canceled, especially on slower connections. These differences can be observed on the network tab of DevTools and the log in Redux DevTools. Consider, for instance, the scenario of dwelling upon and quickly abandoning a single link prior to this patch: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_END STATSV_LOGGED ABANDON_END EVENT_LOGGED FETCH_COMPLETE And after this patch when the fetch timer is canceled (prior to an actual network request): BOOT EVENT_LOGGED LINK_DWELL ABANDON_START ABANDON_END EVENT_LOGGED In the above sequence, FETCH_* and STATSV_LOGGED actions never occur. And after this patch when the network request itself is canceled: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_FAILED STATSV_LOGGED FETCH_COMPLETE ABANDON_END EVENT_LOGGED FETCH_FAILED occurs intentionally, STATSV_LOGGED and FETCH_COMPLETE still happen even though the fetch didn't complete successfully, and FETCH_END doesn't. Additionally, since less data is transmitted, it's possible that the timing and success rate of logging will improve on low bandwidth connections. Also, this patch tries to revise the JSDocs where possible to support type checking and fix a call to the missing assert.fail() function in changeListener.test.js. Bug: T197700 Change-Id: I9a73b3086fc8fb0edd897a347b5497d5362e20ef
2018-06-25 13:26:11 +00:00
( Date.now() - then ) > 150,
true,
'It waits for the given duration'
);
} );
} );
Update: cancel unused HTTP requests in flight Whenever an HTTP request sequence is started, i.e. wait for the fetch start time, issue a network request, and return the result, abort the process if the results are known to no longer be needed. This occurs when a user has dwelt upon one link and then abandoned it either during the fetch start wait time or during the fetch network request itself. This change is accomplished by preserving the pending promises in two actions, LINK_DWELL and FETCH_START, and whenever the ABANDON_START action is issued, it now aborts any previously pending XHR-like promise, called a "AbortPromise" which is just a thenable with an abort() method. There is a similar concept in Core: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/ecc812f06e7dff587b3f31dc18189adbf4616351/resources/src/mediawiki.api/index.js. Aborting pending requests has big implications for client and server logging as requests are quickly canceled, especially on slower connections. These differences can be observed on the network tab of DevTools and the log in Redux DevTools. Consider, for instance, the scenario of dwelling upon and quickly abandoning a single link prior to this patch: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_END STATSV_LOGGED ABANDON_END EVENT_LOGGED FETCH_COMPLETE And after this patch when the fetch timer is canceled (prior to an actual network request): BOOT EVENT_LOGGED LINK_DWELL ABANDON_START ABANDON_END EVENT_LOGGED In the above sequence, FETCH_* and STATSV_LOGGED actions never occur. And after this patch when the network request itself is canceled: BOOT EVENT_LOGGED LINK_DWELL FETCH_START ABANDON_START FETCH_FAILED STATSV_LOGGED FETCH_COMPLETE ABANDON_END EVENT_LOGGED FETCH_FAILED occurs intentionally, STATSV_LOGGED and FETCH_COMPLETE still happen even though the fetch didn't complete successfully, and FETCH_END doesn't. Additionally, since less data is transmitted, it's possible that the timing and success rate of logging will improve on low bandwidth connections. Also, this patch tries to revise the JSDocs where possible to support type checking and fix a call to the missing assert.fail() function in changeListener.test.js. Bug: T197700 Change-Id: I9a73b3086fc8fb0edd897a347b5497d5362e20ef
2018-06-25 13:26:11 +00:00
QUnit.test( 'it should not catch after resolving', function ( assert ) {
assert.expect( 1, 'All assertions are executed.' );
return wait( 0 ).catch( () => {
assert.ok( false, 'It never calls a catchable after resolution' );
} ).then( () => {
assert.ok( true, 'It resolves' );
} );
} );
QUnit.test( 'it should not resolve after aborting', function ( assert ) {
assert.expect( 1, 'All assertions are executed.' );
const deferred = wait( 0 );
const chain = deferred.then( () => {
assert.ok( false, 'It never calls a thenable after rejection' );
} ).catch( () => {
assert.ok( true, 'It calls the catchable' );
} );
deferred.abort();
return chain;
} );
QUnit.test( 'it should catch after resolving and aborting', function ( assert ) {
assert.expect( 2, 'All assertions are executed.' );
const deferred = wait( 0 );
const chain = deferred.catch( () => {
assert.ok( true, 'It calls the catchable' );
} );
deferred.then( () => {
assert.ok( true, 'It resolves' );
deferred.abort();
} );
return chain;
} );