Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor close account page to use Form #12534

Merged
merged 15 commits into from
Nov 18, 2022
Merged

Refactor close account page to use Form #12534

merged 15 commits into from
Nov 18, 2022

Conversation

Puneet-here
Copy link
Contributor

@Puneet-here Puneet-here commented Nov 7, 2022

Details

We are refactoring close account page to use Form
#11341 (comment)

Fixed Issues

$ #11341
PROPOSAL: #11341 (comment)

Tests

  1. Go to settings > Security > Close account
  2. Try submitting the form without typing anything, verify you see error
  3. Add correct contact method, verify the error goes away
  4. Add wrong contact method and tap on screen to remove focus, verify you see error
  5. Verify the button is red and is not disabled
  6. Verify the button gets disabled when your are offline
  • Verify that no errors appear in the JS console

QA Steps

  1. Go to settings > Security > Close account
  2. Try submitting the form without typing anything, verify you see error
  3. Add correct contact method, verify the error goes away
  4. Add wrong contact method and tap on screen to remove focus, verify you see error
  5. Verify the button is red and is not disabled
  6. Verify the button gets disabled when your are offline
  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist

The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots

Web

Screen.Recording.2022-11-08.at.4.01.59.PM.mov

Mobile Web - Chrome

Screenshot 2022-11-08 at 4 35 53 PM

Mobile Web - Safari

Screenshot 2022-11-08 at 4 38 17 PM

Desktop

Screen.Recording.2022-11-08.at.4.10.41.PM.mov

iOS

Screenshot 2022-11-08 at 4 38 37 PM

Android

Screenshot 2022-11-08 at 4 33 47 PM

@melvin-bot
Copy link

melvin-bot bot commented Nov 8, 2022

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!

@Puneet-here Puneet-here marked this pull request as ready for review November 8, 2022 11:10
@Puneet-here Puneet-here requested a review from a team as a code owner November 8, 2022 11:10
@melvin-bot melvin-bot bot requested review from Beamanator and thesahindia and removed request for a team November 8, 2022 11:11
Co-authored-by: Sahil <thesahindia@gmail.com>
@thesahindia
Copy link
Member

When we get an error the error will be shown above the button which is expected in the Form refactor, the problem I see is that the error contains html tag (the error is from backend)
Screenshot 2022-11-08 at 9 16 23 PM
The other thing is that at mobile the modal covers the error above the button and it will be dismissed once user closes the modal
@Beamanator, what can we do here?

expirationDate: 'Por favor introduzca una fecha de vencimiento válida',
securityCode: 'Ingrese un código de seguridad válido',
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change is not related to this PR but added since it was asked here

@Beamanator
Copy link
Contributor

@thesahindia

The other thing is that at mobile the modal covers the error above the button and it will be dismissed once user closes the modal
@Beamanator, what can we do here?

Ooh that's a very interesting point, it seems like we either need to do one of these:

  1. Not show the error in the form (above the "Close account" button)
  2. Not show the "Unable to close account" modal anymore

I call upon @shawnborton to assist with this question - @shawnborton on the "Close account" page we currently don't actually tell the user what error may have occurred when closing their account, we just show the "Unable to close account" modal (see this comment).

Is this a pattern we are ok with?

  • If yes, I assume we want to avoid showing the exact error in the "Close account" form (and just show the modal)
  • If not, maybe let's remove the modal & just show the error above the "Close account" button?

@thesahindia
Copy link
Member

@shawnborton is OOO, should we tag the design team?

@Beamanator
Copy link
Contributor

Aah shucks good point @thesahindia - currently @shawnborton is the whole @Expensify/design team 😅

@thesahindia do you mind posting in #expensify-open-source to get some feedback on this idea? I think we can pause the PR-merge-timer while we wait for feedback

@shawnborton
Copy link
Contributor

Just confirming that I like where we ended up in Slack, where we can omit the modal and just use the error message above the form button.

@Puneet-here
Copy link
Contributor Author

Puneet-here commented Nov 15, 2022

@Beamanator @thesahindia I have updated the code to remove the modal, we need to remove the <p> tag from the error message at backend.

@Beamanator
Copy link
Contributor

@Puneet-here thanks for the reminder, made a follow-up issue for myself here: #12747

@Beamanator
Copy link
Contributor

@thesahindia please feel free to test when you have time 👍

@thesahindia
Copy link
Member

@Puneet-here, let's remove the modal part since we don't have a modal now

* Clear CloseAccount error message to hide modal

P.S. I have reviewed the code, it looks good. I will test it again in the morning. EOD for me 🌃

@thesahindia
Copy link
Member

thesahindia commented Nov 16, 2022

@Puneet-here, great work!
Looks good and works well 🎉

cc: @Beamanator

@thesahindia
Copy link
Member

Reviewer Checklist

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web Screenshot 2022-11-08 at 8 55 07 PM
Mobile Web - Chrome Screenshot 2022-11-08 at 9 13 00 PM
Mobile Web - Safari Screenshot 2022-11-08 at 9 14 31 PM
Desktop Screenshot 2022-11-08 at 8 23 36 PM
iOS Screenshot 2022-11-08 at 9 13 51 PM
Android Screenshot 2022-11-08 at 9 08 38 PM

thesahindia
thesahindia previously approved these changes Nov 16, 2022
Copy link
Contributor

@Beamanator Beamanator left a comment

Choose a reason for hiding this comment

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

A few small requested changes, happy to discuss :D

Also going to request @shawnborton check out the new Close Account page design, I don't know if I love the two error messages both showing in red, with red dots 🤔

src/ONYXKEYS.js Show resolved Hide resolved
src/pages/settings/Security/CloseAccountPage.js Outdated Show resolved Hide resolved
@shawnborton
Copy link
Contributor

I agree that the red dot + red text is not my favorite, but I had posted some options in open source a while ago and this is what the group decided.

@Puneet-here
Copy link
Contributor Author

Updated!
cc: @thesahindia @Beamanator

@thesahindia
Copy link
Member

Thanks for the changes!

All yours @Beamanator

Copy link
Contributor

@Beamanator Beamanator left a comment

Choose a reason for hiding this comment

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

Sounds good, looks like we're good to go here!

@Beamanator Beamanator merged commit 46c1c7b into Expensify:main Nov 18, 2022
@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @Beamanator in version: 1.2.30-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 failure ❌
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @Beamanator in version: 1.2.30-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @luacmartins in version: 1.2.30-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@@ -48,6 +48,9 @@ const propTypes = {
/** Should the button be enabled when offline */
enabledWhenOffline: PropTypes.bool,

/** Whether the action is dangerous */
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand this - what does it mean for an action to be "dangerous"? 😕

Why was this added to such a low level component..

Copy link
Contributor

Choose a reason for hiding this comment

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

To me, "Dangerous" means if the user clicks the "Submit" button, the action being taken should only be taken with caution. I think it would be helpful if you can recommend a "better solution" or what you'd prefer seeing - I am guessing you are saying you'd like to see a more generic prop name, maybe something having to do with the submit button color?

Copy link
Contributor

Choose a reason for hiding this comment

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

To me, "Dangerous" means if the user clicks the "Submit" button, the action being taken should only be taken with caution.

I am guessing you are saying you'd like to see a more generic prop name

No, I think it's too generic. Which "action" is "dangerous"? It's a Form so the user can take many actions. It looks like this just controls the color of the button. So my suggestion would be something like isSubmitButtonDangerous, isSubmitActionDangerous etc.

Copy link
Contributor

Choose a reason for hiding this comment

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

Aah ok I'm glad we got that clarified, I see what you mean that technically there can be many "actions" taken in a form, though I thought it was a bit self explanatory that the main "action" is submitting the form - but it's good to be clear 👍 I like your suggestions, I think isSubmitActionDangerous is a bit more clear to me - there should only be 1 "submit action" (clicking on the submit button) so I'll go with that - follow-up PR incoming!

Copy link
Contributor

Choose a reason for hiding this comment

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

@marcaaron follow-up PR here: #13981

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.

6 participants