Add option to always include the country code in the text field
See original GitHub issueParsing the country code from the text field (some of the time) without also always displaying it in the text field can lead to a frustrating/confusing UX.
Making the country code always visible would provide an extra feedback to the user as to whether the number they entered is what they intended to enter.
Example of a possible confusing user interactions (I used this codesandbox):
- Let’s say I don’t realize that a country code is required, so I just start typing a phone number as it would normally be entered in my country (US), like
206-555-1234
. But to my surprise, Egypt is selected as the country (it was parsed from the text field) and the value is formatted as+20 65 551234
. If I as the user am paying close attention, this should clue me in to the fact that it did not interpret my number as a US number. But since it is formatted all strangely now, it may not be clear exactly how to fix the problem. I might try one of 2 things: 1.
Try to fix it via the text field (keyboard)- First, maybe I clear the input by backspacing. Egypt is still selected as the country, but since no country code is visible to the user, I might assume I’ve cleared the input completely (resetting it back to its initial state).
- Now let’s say I either the same number again,
206-555-1234
, or I try something different and add a1
,1-206-555-1234
(many people don’t know you need a+
before the country code) . Either way, I get a wrong result (either"+202065551234"
or"+2012065551234"
as the new internal state, respectively), but worst of all, may not realize it because the actual result is not visible to the user! What I see in the field is2065551234
, which at least looks better (more normal) than+20 65 551234
, so I might conclude that it interpreted the number correctly this time (wrong!) and proceed with filling in the rest of the form. Unless I’ve switched to my mouse and actually clicked on the flag, I still might not realize that the flag is somehow an integral part of the phone number field. And even if I do click the drop-down, since it doesn’t show the country codes next to the countries (requested in #259 and 👍 by me), nor in the text field, it’s not clear that they will actually be included in the value that gets submitted by the form, and I may still believe it’s going to submit it correctly.
- Or
2.
Try to fix it by choosing a different country from the select (mouse)- Perhaps just as likely, I, the hapless user, notice that the flag is incorrect and click on it to discover the drop-down. Sure enough, I see that Egypt is selected. “That’s not right! Let me fix that…”
- So I choose United States from the list and … wat? Now it says
+1 655 512 34
! What happened to the206
area code that I entered? (And of course, to add insult to injury, if I start typing20
after the+1
, I’ll run into the issue where only the2
ends up where I want it and the0
ends up at the end.)
Either always read/show country code from/in text field or never do
Currently it is inconsistent: the first time they enter a number, it interpreting it as a full, international number (taking the first digits as the country code), but after a country has been selected once, it interpreted all of the digits as being a national number.
I can understand how this was probably the intended behavior, and how it can be a pleasant UI some of the time. Since the default option is “International”, it makes sense that it would parse inputs as international numbers then but then switch to parsing as national numbers as soon as they select a country. Especially when you can set a default country, this might actually be a better UX because most people would probably prefer to see their phone number in their local/national format, right?
But there are 3 problems with that:
- People may not click on the country picker at all and not realize that the default selected option is “International”.
- As far as us knowing it’s a national number because they selected a country… That would certainly be true if the user were required to actually select it from the list. But if all they did was enter some digits, and we assumed some of them were the country code, then no, they haven’t told us what their country is definitely; we just guessed it.
- To be consistent, after parsing the country code out of the digits and setting the country, in order to properly switch from an international to a national phone number input, it seems like it should remove those country digits from the text field so that the remaining digits are only the digits that are for a national number in the selected country. (This goes back to my main point about how it should either always show or never show the country code in the text field.)
Related feature request: countryCodeEditable
prop
To make it even more fool-proof, maybe there should be the option to not only have the country code always be visible, but also not be deletable, like you can do with react-phone-input-2
(demo (source)). Seems like a pretty good option if you want to force people to use the country select to set the country code.
But if we allow country code to be editable in the field, then it seems like editing it there should cause it to select the corresponding country/flag. It looks like you can edit the country code some of the time with react-phone-number-input
— as long as the +
prefix is still there — but if you accidentally or purposefully remove the +
then you can’t edit the country code anymore, which could be confusing. I really like how react-phone-input-2
won’t even let you remove the +
— even with countryCodeEditable={true}
.
But both of these behaviors depend on having the country code always visible/included.
Another idea would be to add an option to not include an “International” option in the select. Then it would only have to parse national numbers.
In conclusion, this looks like an awesome library! The hybrid international/national number field idea seems to have some advantages, but also seems like it could possibly be confusing.
I think I may go with react-phone-input-2 for now, but there are some things about this library that I really like, too (such as the ability to not include the flags in the drop-down so that it loads faster and is more responsive), so it’s still in the running…
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (7 by maintainers)
Should I create a new issue for that or can this issue be about adding that new option?
Wow, that’s a lot of text.