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

Validate phone numbers in different formats #672

Merged
merged 12 commits into from
Apr 2, 2024
Merged

Conversation

tienifr
Copy link
Contributor

@tienifr tienifr commented Mar 26, 2024

Current isValidPhone function only validates E.164 standard phone numbers but not others causing misunderstandings and worng usages. This PR:

  1. Mark isValidPhone as deprecated
  2. Replace isValidPhone with isValidE164Phone
  3. Add a new isValidPhoneFormat to validate phone numbers in different formats
significant: 4404589784
international: +1 440-458-9784
e164: +14404589784
national: (440) 458-9784
123.456.7890

Fixed Issues

$ Expensify/App#37723

Tests

1. What unit/integration tests cover your change? What autoQA tests cover your change?

This is a renaming refactor so no need to add new unit tests.

2. What tests did you perform that validates your changed worked?

  • Test in Expensify App follow these steps:
  1. Go to Workspace > Bank account.
  2. Initiate the add BA flow
  3. Proceed to Company's phone number step
  4. Enter a random US number in national format (xxx) xxx-xxxx, e.g., "(440) 458-9784"
  5. Press Next
  6. Verify that the phone number is parsed successfully

QA

1. What does QA need to do to validate your changes?

Test in Expensify App follow these steps:

  1. Go to Workspace > Bank account.
  2. Initiate the add BA flow
  3. Proceed to Company's phone number step
  4. Enter a random US number in national format (xxx) xxx-xxxx, e.g., "(440) 458-9784"
  5. Press Next
  6. Verify that the phone number is parsed successfully

2. What areas to they need to test for regressions?

NA

Screenshots

Screen.Recording.2024-03-26.at.18.32.42-compressed.mov

@Pujan92
Copy link
Contributor

Pujan92 commented Mar 26, 2024

@tienifr aren't we supposed to add isValidPhone logic here in common?

@Pujan92

This comment was marked as outdated.

@tienifr
Copy link
Contributor Author

tienifr commented Mar 27, 2024

@Pujan92 Yes, I just added it.

@tienifr tienifr changed the title Rename isValidPhone to isValidE164Phone Validate phone numbers in different formats Mar 27, 2024
@Pujan92
Copy link
Contributor

Pujan92 commented Mar 27, 2024

@Pujan92 Yes, I just added it.

Thanks!

@grgia grgia self-requested a review March 27, 2024 13:34
@rlinoz
Copy link
Contributor

rlinoz commented Mar 27, 2024

This looks good, but may silently break OldDot, so I am waiting a little to review and merge

@Pujan92
Copy link
Contributor

Pujan92 commented Mar 27, 2024

@tienifr Looks good to me, better if you add some tests here for isValidPhone and isValidE164Phone

describe('Str.isValidEmail', () => {

Also some space lint fixes which look straightforward to me, from this PR only 1 error occurred but better if we fix all(5) space errors here.

Screenshot 2024-03-27 at 22 49 16

lib/str.d.ts Outdated Show resolved Hide resolved
@rlinoz
Copy link
Contributor

rlinoz commented Mar 28, 2024

So, I was thinking about this, and how we can merge this without breaking other parts of the application that depend on it.

What if we:

  1. Deprecate the isValidPhone and keep its behavior
  2. Keep the new isValidE164Phone and mention it in the deprecated message of the isValidPhone
  3. Create a new isValidPhoneFormat or something like that, and make it have the behavior of the new isValidPhone, also link this in the deprecated method so people know what method to look for depending on what they want

cc: @Pujan92 @tienifr @grgia

@tienifr
Copy link
Contributor Author

tienifr commented Mar 29, 2024

@Pujan92 What do you think? I think that's not neccessary because we already investigate all usages of the deprecated isValidPhone in App.

@tienifr
Copy link
Contributor Author

tienifr commented Mar 29, 2024

I added unit test.

@Pujan92
Copy link
Contributor

Pujan92 commented Mar 29, 2024

@rlinoz As @tienifr said we have covered all occurrences in the App and going to update it in the App PR, @grgia My only concern is to confirm and check whether any other repo is using this function or not. If it is used then with the version bump we also need to rename those occurrences.

Screenshot 2024-03-29 at 17 27 47

@rlinoz
Copy link
Contributor

rlinoz commented Mar 29, 2024

This is used in Web-Expensify and Web-Secure.

My point is, if we merge this and someone updates the expensify-common lib in one of the repos before we merge the renaming, we will break this validation.

@Pujan92
Copy link
Contributor

Pujan92 commented Mar 29, 2024

Ah, ok @rlinoz . If that is the case then for the safer side, we can follow the approach that you mentioned here. With that, we may need 2nd PR for removing isValidPhone later once we update the occurrences in all repo to use the new function name.

@tienifr
Copy link
Contributor Author

tienifr commented Apr 1, 2024

@Pujan92 I marked isValidPhone as deprecated following the feedback above, also updated the PR description.

@Pujan92
Copy link
Contributor

Pujan92 commented Apr 1, 2024

Thanks @tienifr, Looks fine to me. cc: @rlinoz @grgia

Copy link
Contributor

@rlinoz rlinoz left a comment

Choose a reason for hiding this comment

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

Thanks!

@grgia grgia merged commit dc14d97 into Expensify:main Apr 2, 2024
5 checks passed
@Pujan92 Pujan92 mentioned this pull request Apr 4, 2024
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.

4 participants