Add 'continue with user' option when credentials are already present

[kirkbyo]

Closes https://github.com/andymatuschak/orbit/issues/179

What When the credentials are already present on the iframe's domain, a "Continue with " option is shown to confirm with the user that they are already authenticated.

Demo of Before and After behaviour

| Before | After | | --- | --- | |  |  |

How If the userRecord is received before the user has entered their authentication credentials, we'll "double check" that they want to use the account we found. I added a new "ContinueWithUsercomponent to handle this behaviour to avoid bloatingSigninForm` further with conditionals.

Notes I will admit this new flow feels a bit "wonky". It feels weird to ask the user to "continue" without presenting them another option. I attempted to add a button that allows the user to "Use a different account", but to do this flow properly would involve reworking how the overrideEmailAddress is used right now. If we did want this behaviour, I'd be happy to take that on in a separate PR!

[andymatuschak]

Nice work, @kirkbyo! I'll comment at a high level before digging into the code changes.

At first, I thought: oh, boy, I guess we really have to make the sign in flow much more fleshed out to make this reasonable. To your point, it's weird not to have a second option!

But then I realized: hey, wait. In this flow, the user has already entered their email address in the prior screen. This is quite different from other OAuth flows, where they really need to clarify that you intend to sign in using the saved credential. In our case, if the saved credential's email address matches the one you entered, that's what you mean! This lets us simplify the UI language, and also means we don't need an alternative option.

So if the user's signed in, I think the secondary text can say: "Welcome back, EMAIL. We signed you in using a saved password." and the button can say "Continue".

Now, the other thing this makes me realize is that if the stored credential doesn't match the email address they entered, we should discard it, sign out, and show the normal login interface. After all, they asked to sign in with a different address! A fancier flow might say "hey, wait, did you want to sign in with OTHER_EMAIL instead?" (people often forget which email address they use for things), but I think we can skip that for now.

[andymatuschak]

Oh, and probably we should focus() the button on mount, so that people can just hit return / space / whatever to continue.

[kirkbyo]

Makes sense! I have updated the auth flow with the changes you mentioned:

Demo

### Flow for when the `userRecord` and the `overrideEmailAddress` match  ### Flow for when the `userRecord` and the `overrideEmailAddress` __do not__ match 

[kirkbyo]

Done! I will merge once the tests go green.

This patch reminds me that we’re probably just creating pain for ourselves by separating ui into a separate module like this. Perhaps at some point we’ll want to just move it into app. Or maybe just simple components like Button should be in a separate ui module? Or maybe a separate style module just for static bits like color / type hierarchy? Not sure.

My two cents: I personally like the idea of separating the UI from the app since it forces you to not encapsulate API logic within the UI and allows for testable components like SigninForm. However, I do think the folder could be separated into design system components (i.e. Button) vs. views (SigninForm or ReviewArea). Also, I worry that moving the design system bits into a separate package would become tedious at this stage since we'd now have two storybook instances.

[andymatuschak]

Those are all good points! 👍