mirror of
https://gerrit.wikimedia.org/r/mediawiki/extensions/Popups
synced 2024-11-15 03:34:03 +00:00
ce8a2d4c3f
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:
ecc812f06e/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
60 lines
1.4 KiB
JavaScript
60 lines
1.4 KiB
JavaScript
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.' );
|
|
|
|
const then = Date.now();
|
|
return wait( 150 ).then( () => {
|
|
assert.strictEqual(
|
|
( Date.now() - then ) > 150,
|
|
true,
|
|
'It waits for the given duration'
|
|
);
|
|
} );
|
|
} );
|
|
|
|
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;
|
|
} );
|