Use step-by-step credentials API (no functional change)

[delan]

• context and past patches
• you are here: #47898 (original data-layer changes, now reverted)
• #47614 (i4 verification screen with progress only)
• #48106 (full i4 verification screen)
• #48492 (data-layer with wpcom-proxy-request fix)

Changes proposed

This patch makes the data layer for the update credentials pages use the new step-by-step credentials API, without actually changing any user-facing behaviour (which will happen in #47614).

Testing instructions

This patch depends on D53562-code and wpcom-xhr-request#31. If either or both have landed, skip the corresponding sections below. The calypso.live link will only work once both have landed.

D53562-code

Check out D53562:

$ arc patch D53562

Update your hosts(5) file to point public-api.wordpress.com to your sandbox (for more details, search the field guide for “Testing APIs in Your Sandbox”), then verify that it worked at ?amisandboxed (you may need to shift-reload).

Ensure that your hosts(5) file also has calypso.localhost and jetpack.cloud.localhost pointing to 127.0.0.1 or similar.

wpcom-xhr-request#31

On your Calypso dev machine, check out and build wpcom-xhr-request#31:

$ git fetch # or clone if necessary
$ git checkout add/streaming-response-support
$ npm install

Check out this patch:

$ git fetch # or clone if necessary
$ git checkout add/credentials-testing-progress-internals

Edit client/package.json to point .dependencies.wpcom-xhr-request to your local copy above:

{
	"dependencies": {
		"wpcom-xhr-request": "link:../../wpcom-xhr-request"
	}
}

Update your node_modules, then spin up either Calypso flavour locally:

$ yarn
$ yarn start # blue
$ yarn start-jetpack-cloud # green

Calypso tests

Open devtools on a patched version of Calypso, then run the following:

localStorage.debug = "calypso:data-layer:update-credentials"

Choose a Rewind-enabled site, then click Settings (green), or Manage → Settings → Jetpack (blue).

Verify that you can save working credentials successfully, with progress records sent to the console:

Now try to save the same credentials except for an incorrect password or private key, and verify that you get the following error exactly once with no retry, and progress records sent to the console:

[matticbot]

Test live: https://calypso.live/?branch=add/credentials-testing-progress-internals

[delan]

this is currently a WPCOM_HTTP_REQUEST option as a proof of concept, but yeah, i think the idea (in my next patch) would be to plumb this through meta like onSuccess + onError + onProgress?

[delan]

(note that i’ve done exactly that in #47614)

[jsnajdr]

Yes, if you want to be compatible with the data layer philosophy, then you don't use onStreamRecord as a callback. It should be a Redux action.

And you'll also need to enhance dispatchRequest to include the onStreamRecord option.

You want to look at how onProgress events flow through the code and implement something very similar for onStreamRecord.

The wpcom.req handler gets a onStreamRecord callback that dispatches an extended Redux action:

const onStreamRecord = ( record ) => {
  dispatch( extendAction( action.onStreamRecord, streamRecordMeta( record ) ) );
}

That dispatches the action.onStreamRecord action (it's an object with type etc.), enhanced with a meta.dataLayer.streamRecord property.

The dispatchRequest handler then intercepts this action, and needs to detect that there is the meta.dataLayer.streamRecord meta (in createRequestAction, with a check similar to getProgress). Then it will call its onStreamRecord action creator callback that receives action and record as arguments, and which returns an app-level action to dispatch and handle the record.

There are three functions/objects called onStreamRecord, and each of them is a different thing 🙁

[delan]

thanks for the detailed walkthrough! i think #47614 should be aligned with every step of this, but let me know if i’ve missed anything.

[dmsnell]

why do we need a boolean and a function? if the function is present, why would need to set the flag?

will processResponseInStreamMode !== ('function' === typeof onStreamRecord) ever?

[delan]

good point! not in this patch, so i’ve dropped the flag from this layer in 1e53809.

but #47614 has to undo this, because we add on­Stream­Record to dispatch­Request. for requests that use dispatch­Request, we point on­Stream­Record to the default action no matter what, and i can’t think of a clean way to convey what this flag ought to be set to through create­Request­Action and the provided fetch function.

i think the only way to get rid of this flag is by also dropping it from wpcom-xhr-request, but i’m reluctant to do that for node.js safety reasons.

[delan]

i’ve since done exactly that in a684912 (thanks to @jsnajdr’s advice in Automattic/wpcom-xhr-request#31 (comment)).

[matticbot]

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

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

name         parsed_size           gzip_size
entry-main        +352 B  (+0.0%)     +111 B  (+0.0%)
entry-login       +352 B  (+0.0%)     +125 B  (+0.1%)

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

Sections (~368 bytes added 📈 [gzipped])

name                    parsed_size           gzip_size
wpcom-xhr-request            +742 B  (+2.2%)     +281 B  (+3.3%)
settings-security            +311 B  (+0.1%)      +87 B  (+0.1%)
settings-jetpack             +311 B  (+0.1%)      +87 B  (+0.1%)
scan                         +311 B  (+0.1%)      +87 B  (+0.1%)
jetpack-cloud-settings       +311 B  (+0.2%)      +87 B  (+0.2%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~87 bytes added 📈 [gzipped])

name                                       parsed_size           gzip_size
async-load-signup-steps-rewind-form-creds       +311 B  (+0.6%)      +87 B  (+0.6%)
async-load-signup-steps-creds-permission        +311 B  (+0.9%)      +87 B  (+0.9%)
async-load-signup-steps-creds-confirm           +311 B  (+0.9%)      +87 B  (+0.9%)
async-load-signup-steps-clone-credentials       +311 B  (+0.5%)      +87 B  (+0.5%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

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.

[delan]

@jsnajdr wpcom-http changes copied from #47614, ok to merge?

[jsnajdr]

Looks good, thanks for all your work here! 👍