GitHub connection error

[brianlovin]

Status

• WIP
• Ready for review
• Needs testing

Deploy after merge (delete what needn't be deployed)

• api
• hyperion (frontend)

@mxstbr this feels...hacky. But I'm not quite sure how to else to approach this.

Here's what's happening:

1. User A logs in to Spectrum with GitHub
2. User A creates another Spectrum account accidentally (or intentionally) by logging in with Twitter
3. User A+Twitter tries to connect their GitHub account in their user settings
4. Our auth flow detects that an account already exists with those GitHub credentials
5. We return User A+Twitter back to their user settings, without editing their user object

The problem is people getting redirected back, seeing the 'Connect GitHub' button again, and assuming the app is broken.

This PR addresses this by passing back an error message as a query parameter. When the user settings view mounts, I check for the query param and use it to dispatch a toast and save a class variable with the error to be passed as props down to the GitHub connect button so that we can render this:

I'm open to ideas on this; the only obvious abstraction I can think of here would be to have a global query parser that looks for some generic ?error=foo query param in every url in order to dispatch a toast. But I'm not sure if we want to do that yet, since we don't really have any other use cases for it, nor am I sure that it's the right way for us to handle error messages.

Closes #4668

[spectrum-bot]

	Warnings
⚠️	These modified files do not have Flow enabled: src/components/formElements/style.js

Generated by 🚫 dangerJS

[mxstbr]

I would rather make this something generic like error from the get-go, we might need to reuse that for other auth or similar errors!

[brianlovin]

Fair enough - a good use case I just thought of would be to redirect all email unsubscribe links back to the app instead of that ugly unstyled html page. We could redirect it back with some kind of query params like ?toastType=success&toastText=Unsubscribe successful! and then for this PRs use case it could be ?toastType=error&toastText=Blah...

Then I'll just need an app-level history listener to handle locations with these params.

That seem better?

[mxstbr]

That seems great to me! 💯

[brianlovin]

Okay, I've implemented a generic toast handler component at the global level, and demonstrated a proof of concept implementation for email unsub redirects here: 788143b => everything works that I've tested locally, but I'm going to write some E2E tests to make sure things look good!

[brianlovin]

Okay, this is ready for a test and review @mxstbr! I added some end to end tests as well to make sure this works :)

[mxstbr]

Amazing, this works really well!! Liking the new styling too, much cleaner ✨

Let's shipit!

[mxstbr]

Great catch here 💯

[mxstbr]

I am so shipping this!

[mxstbr]

Restarting e2e tests since failures seem unrelated.

Then I am shipping this.

😅