Login block: Accept the user email as a prop

[DanReyLop]

Changes proposed in this Pull Request

In 3bec7b8, added an optional userEmail prop to the LoginBlock. If present, the form will be prefilled with that email instead of relying on the current route querystring.

In 9f540c3, moved the styles for the social divider (this) to the login block styles, since that block can be used outside of wp-login.

How to test

This is just a refactor, there shouldn't be any regression. At this moment, LoginBlock is never called with a userEmail prop. The "social divider" is only used in the WooCommerce login flow, so to test that the styles still look good, go to http://calypso.localhost:3000/log-in?from=woocommerce-onboarding.

Note: This is a required refactor for the new "Woo DNA" flow, implemented in #41798

[matticbot]

Test live: https://calypso.live/?branch=woodna/login-block-enhancements

[matticbot]

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

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

name         parsed_size           gzip_size
entry-login        +41 B  (+0.0%)      +11 B  (+0.0%)

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

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

name                      parsed_size           gzip_size
async-load-design-blocks        +41 B  (+0.0%)       +3 B  (+0.0%)

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.

[v18]

Where is userEmail coming from?

[DanReyLop]

Normally it's coming from the page's querystring (see here). So you'll land in the login flow with an URL like /login?...&email_address=foo@bar.com, and the Email field will be prefilled with foo@bar.com.

What I've made in this PR is to have the possibility to override that value. So the LoginBlock could be rendered like:

<LoginBlock userEmail="asdf@aaa.com" />

And the prefilled Email field will be asdf@aaa.com, regardless of the URL the user landed on. Because the whole login/signup/authorize Woo flow is implemented in a single page (without the URL ever changing), this was a needed addition.