wpcom-proxy-request: Migrate to TypeScript

[ockham]

Changes proposed in this Pull Request

wpcom-proxy-request: Migrate to TypeScript

Testing instructions

Verify that Calypso still builds and works.

[matticbot]

Test live: https://calypso.live/?branch=update/wpcom-proxy-request-typescript

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~141 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-main                  +100 B  (+0.0%)      +30 B  (+0.0%)
entry-login                 +100 B  (+0.0%)      +32 B  (+0.0%)
entry-gutenboarding         +100 B  (+0.0%)      +47 B  (+0.0%)
entry-domains-landing       +100 B  (+0.0%)      +32 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[ockham]

Rebased (and hopefully updated correctly, now that #39825 is in).

[sirreal]

I polished this up and it's ready for review.

[sarayourfriend]

Is fn optional or was that a mistake in the original JSDoc?

[sirreal]

It was, but apparently didn't need to be. This is an internal/private function that always receives a fn callback.

[sarayourfriend]

Will these overloads not cause an issue when trying to call request(params).then()? I'm curious how TS will negotiate the missing fn callback, which overload does it choose in that case?

[jsnajdr]

When request is called with the fn callback arg, it returns either XmlHttpRequest or null. The latter can be returned by wpcom-xhr-request when used on Node.js, where there's no XHR. request never returns a Promise when the fn callback is supplied.

Without the fn callback, the return value is always a Promise.

The returned XmlHttpRequest object can be used to subscribe to progress event when uploading or downloading something. There's no other API for that in the wpcom-*-request libs.

It would be nice to redesign this API in a major release. Mainly to get rid of exposing the XmlHttpRequest object. It's not supported in Node.js, and in wpcom-proxy-request the returned instance is somewhat synthetic, supporting event listeners but not much else.

And in the variant that returns a Promise, progress event and also aborting requests is not supported at all. XmlHttpRequest can do both.

Last note: the type of the request function should be defined in the wpcom library rather than in wpcom-proxy-request. After all, wpcom-proxy-request is just a "low level driver" for the wpcom library, and wpcom-xhr-request and other drivers are supposed to implement the same interface.

[sarayourfriend]

Why this change?

[sirreal]

Buffered was a nullable array, now it's just an array. The uninstall function handles clearing the array if necessary. It's no longer necessary to set it to an empty array for initialization.

[github-actions]

This PR has been marked as stale due to lack of activity within the last 30 days.