Skip to content

Conversation

@millmason
Copy link
Contributor

@millmason millmason commented Apr 4, 2023

Because:

  • We're moving the React components to their real routes and wiring them up to receive data

This commit:

  • Adds signin_bounced into the React app
  • Adds a check for the user's email (via localStorage) in the App root file

Closes #FXA-6489

Checklist

Put an x in the boxes that apply

  • My commit is GPG signed.
  • If applicable, I have modified or added tests which pass locally.
  • I have added necessary documentation (if appropriate).
  • I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

Screen Shot 2023-04-04 at 1 16 50 PM

Other information (Optional)

Still needs metrics!!

);
}

async getAccountStatusByEmail(email: string): Promise<any> {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally in Backbone, we would check to make sure the account associated with the email existed. While I opted to simplify the page by omitting this per discussion with @vbudhram, we will need this method.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Does this need to be any or can it be more specific?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm I think it can be a boolean actually, checking!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!


if (currentUser) {
setEmail(currentUser.email);
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✂️

);
}

async getAccountStatusByEmail(email: string): Promise<any> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Does this need to be any or can it be more specific?

<SigninBounced email={props.email} canGoBack={props.canGoBack} />
</AppLayout>
<SigninBounced
emailLookupComplete={true}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I think we can drop the {true} for boolean props.
Meh, it's a *.stories.* file, maybe we don't care too much. 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll clean it up!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

Comment on lines 30 to 31
canGoBack={true}
emailLookupComplete={true}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: same here re: {true} boolean props (although this was already using {true} before), per https://arcticicestudio.github.io/styleguide-javascript/rules/react/props.html#boolean-attributes-notation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

renderWithRouter(
<SigninBounced
email={MOCK_ACCOUNT.primaryEmail.email}
canGoBack={true}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can omit {true}, although it is a *.test.* file. 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

@millmason millmason force-pushed the FXA-6489-signin_bounced--setup branch from 123e5b5 to d3599be Compare April 4, 2023 23:31
@millmason millmason marked this pull request as ready for review April 4, 2023 23:47
@millmason millmason requested a review from a team as a code owner April 4, 2023 23:47
@millmason millmason force-pushed the FXA-6489-signin_bounced--setup branch from d3599be to 44f05dd Compare April 5, 2023 22:25
@millmason millmason requested a review from a team as a code owner April 5, 2023 22:25
@millmason millmason force-pushed the FXA-6489-signin_bounced--setup branch 2 times, most recently from c322f77 to 36d0d38 Compare April 6, 2023 16:10
Copy link
Contributor

@vpomerleau vpomerleau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🎉 I've checked out the branch and tested that I do see the React SigninBounced page when navigating to http://localhost:3030/signin_bounced?showReactApp=true after initiating signin, and get redirected to /signup when trying to hit this route after clearing local storage.

I am right in assuming that the actual check of whether an email has bounced will be happening somewhere else? And if so, is there an existing ticket to implement that? I recall that checking for bounced email was marked as a to-do for some pages.

// clear the session
// clear the form prefill
navigate('/signup');
logViewEvent(viewName, 'link.create-account', REACT_ENTRYPOINT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a separate issue (because I've spotted this in other pages while working on FXA-7100), but the emitted metrics event doesn't have a payload.

@millmason
Copy link
Contributor Author

millmason commented Apr 6, 2023

LGTM! 🎉 I've checked out the branch and tested that I do see the React SigninBounced page when navigating to http://localhost:3030/signin_bounced?showReactApp=true after initiating signin, and get redirected to /signup when trying to hit this route after clearing local storage.

I am right in assuming that the actual check of whether an email has bounced will be happening somewhere else? And if so, is there an existing ticket to implement that? I recall that checking for bounced email was marked as a to-do for some pages.

What I've understood from going through the code is that the user is redirected to the signin_bounced page by the session-verification-poll-mixin, which is used by choose_what_to_sync, confirm_signup_code, confirm, and sign_in_token_code. I know that at least in our existing React version of confirm_signup_code, this is an existing TODO. The session-verification-poll-mixin basically just polls for errors and then determines what to do next based on the incoming errors.
A tentative search of our existing tickets did not indicate to me that this work has been ticketed -- I'll make a ticket 👍
New ticket 🎟️ : https://mozilla-hub.atlassian.net/browse/FXA-7199

# linkExternal is a link to a mozilla support
signin-bounced-help = If this is a valid email address, <linkExternal>let us know</linkExternal> and we can help unlock your account.
# supportButton is button which logs the user's action and navigates them to mozilla support
signin-bounced-help = If this is a valid email address, <supportButton>let us know</supportButton> and we can help unlock your account.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to change <linkExternal> here? If so, we'll need to update the ID for signin-bounced-help to trigger updates for the tag change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ohhh I see -- the HTML component which is being used had to be changed, so I changed the name to be reflective of that, but I can leave it as it was (it does still function as if it were an external link, it just also logs some metrics before redirecting the user.) Does changing the HTML component need to trigger changes (if we don't change the variable?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The short answer is, if its purely a change on the backend and on the there doesn't appear to be any change to the end user, then we wouldn't need to update the string.

If the context as it appears to the end-user doesn't change - as in <linkExternal>/<supportButton> essentially look/function the same on the surface, then we wouldn't need to trigger changes. However, if for example the change here makes the text look like a button instead of a link, then perhaps it would be wise to update the variable and ID.

Variable name changes for existing strings end up requiring a new translation (but text is essentially the same as before), though likely a fairly simple update it still ends up requiring a translator to look at. For some locales, it could ultimately end up in fallback text appearing for some time until a team has the bandwidth to look at it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll just set the var back to what it was in that case -- there will be no change to the appearance of the component on the page

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @bcolsson !

Because:

* We're moving the React components to their real routes and wiring them
  up to receive data

This commit:

* Adds signin_bounced into the React app

Closes #FXA-6489
@millmason millmason force-pushed the FXA-6489-signin_bounced--setup branch from 36d0d38 to 9ef8616 Compare April 7, 2023 21:55
@millmason millmason merged commit 90c1c14 into main Apr 10, 2023
@millmason millmason deleted the FXA-6489-signin_bounced--setup branch April 10, 2023 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants