You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 27, 2024. It is now read-only.
We use E164 phone numbers (+12125004000, +442075972524) in our app. As these clearly indicate the country, the extra step of parsing the first few characters in order to tell format() what country we are in seems like extra effort. In addition, in v1.0.0 it seems like region is ignored when the phone number is passed in E164 format.
The new parse() method has been great so far! I'd love to see format() follow the same path of making region optional, with its use enhancing the method when necessary or useful.
Alternatives you've considered:
We are using this library and format() with regionCode:"US" as a placeholder for now, and it works, but are concerned that a future enhancement, change, or bug fix might cause this faked functionality to behave in a different manner.
I tried a different library, but it was feature incomplete, as it had only implemented mobile and fixedLine, and not Toll Free, etc and so the validation in that library failed to meet our needs.
The text was updated successfully, but these errors were encountered:
Environment
Package version: v1.0.0
Description
What you'd like to happen:
We use E164 phone numbers (+12125004000, +442075972524) in our app. As these clearly indicate the country, the extra step of parsing the first few characters in order to tell
format()
what country we are in seems like extra effort. In addition, in v1.0.0 it seems likeregion
is ignored when the phone number is passed in E164 format.The new
parse()
method has been great so far! I'd love to seeformat()
follow the same path of making region optional, with its use enhancing the method when necessary or useful.Alternatives you've considered:
We are using this library and
format()
withregionCode:"US"
as a placeholder for now, and it works, but are concerned that a future enhancement, change, or bug fix might cause this faked functionality to behave in a different manner.I tried a different library, but it was feature incomplete, as it had only implemented mobile and fixedLine, and not Toll Free, etc and so the validation in that library failed to meet our needs.
The text was updated successfully, but these errors were encountered: