Format assumes local number before national number

[nlwillia]

When autoFormat is enabled, intl-tel-input hands off formatting duties after each character event to libephonenumber's AsYouTypeFormatter. This mode seems to assume that a local number is being entered until enough digits are typed, then it switches to a long distance number with an area code.

The result for a US number is that the user starts seeing a placeholder of "(...) ...-...." for a 10-digit number, but as they type they see the 7-digit "...-...." format first. It only changes if they keep typing. When someone intended to enter a 10-digit number from the start (which is almost always going to be the case for a web form), this is counter-intuitive. Some users will stop and try to fix the format instead of continuing to type which frustrates them since they can't add characters that the widget thinks are invalid.

I dug into libphonenumber a bit and found that the formats used are part of the big blob of configuration data that gets downloaded. If I remove [,"(\\d{3})(\\d{4})","$1-$2",,"","",1], from the file in the US section, then the formatter starts with the assumption of a 10 digit number as preferred.

Any suggestions of a better way to go about it? For example, being able to provide a function that would return a custom format string for a country code would be cleaner than having to manually edit the data file.

[jackocnr]

Yes you are exactly right. Unfortunately I don't have time to dig into this right now, but could you see if there is a way to tell AsYouTypeFormatted to always use the full national formatting? Else could we open an issue with libphonenumber asking for this?

[nlwillia]

I looked at the API and implementation and didn't see anything promising. Logged #907 upstream.

[jackocnr]

Brilliant, thank you. Fingers crossed.

[keghani]

Hi!

I checked the demo and for the US I see "(201) 555-5555" in grey in the text box. Yet I'm not allowed to enter punctuation marks into the box.

The user experience could be improved by either not using AsYouTypeFormatter or removing the grey help text (it confuses more than it helps right now).

[jackocnr]

Thanks @keghani for your input, and I agree we need to do something as currently you can't type the first character from the placeholder. Is there a way to programmatically discard certain formats?

@nlwillia I can't find that string you removed - perhaps it has changed in the latest build? I could find 7 instances of a shorter version: "(\\d{3})(\\d{4})","$1-$2", but don't know which one to remove. How did you figure it out before?

Unless we can A) programmatically remove formats, or B) find a reliable automated way to remove that format during the build process (seems unlikely), then I propose we change the autoFormat option to false by default, and add a warning to the description about known UX issues.

[keghani]

Re. "Is there a way to programmatically discard certain formats?"

Not through libphonenumber. I do think your best option is to change autoFormat to false, this would solve the problem for all regions - otherwise you can't be sure that the example format won't conflict with what you can type in via AYTP.

[jackocnr]

I agree. Updated in v7.1.0.

[nlwillia]

For whatever reason, it's [,"(\\d{3})(\\d{4})","$1-$2",,,,1] in the latest build.

I was thinking that if there were a reliable way of telling whether a format would produce an E164 result then partial formats could be excluded as part of the custom build process somehow (ex: applying an XSLT to the XML). I see <intlFormat>NA</intlFormat> in the XML for the unwanted US entry, but I don't know if that can be generalized to use to identify the unwanted patterns.

[alanmatuszak]

Just a thought - what if the formatting was applied when the user leaves the field - that way they could type in the 10 digit (or 7 digit number) as quickly as possible without punctuation, then when they leave the field it will get formatted nicely.

[jackocnr]

@alanmatuszak it's an interesting idea, but it would be weird if the user had added their own formatting chars, and then we immediately overrode that.

[nlwillia]

I added PR #357 with a transform to remove the local formats. It's a bit of an experiment as I can't tell you for sure that my hypothesis about how to identify local formats is correct, but hopefully it gets the idea across. A couple of tests that assume local formatting/interpretation are failing, but otherwise it seems to work for cases like disallowing a 7 digit number in the US.

I think the as-you-type formatting is one of the cooler features of intl-tel-input, so it's a shame that it has to be disabled by default to avoid some of these local number edge cases. I don't know if this utils.js approach is trustworthy enough to ship as the only option with formatting defaulted again or if it's something you'd want to make an option (ex: including a second, non-local version of utils.js).

As an aside, I don't know whether there's any dead-weight in the metadata file relative to intl-tel-input, but with a transform in place, anything else you would want to remove is pretty easy. There could be things that libphonenumber builds in that intl-tel-input could exclude and reduce the file size a bit. It would need some experimentation and could be fragile, but perhaps it's something to think about.

[jackocnr]

@nlwillia I appreciate your enthusiasm for the feature, and I'm excited to try your PR - it looks to be a stroke of genius, but the fact remains that we're hacking libphonenumber to do something it's not supposed to, and it could easily break with future updates. I have summarized my thoughts here, and I would appreciate your feedback: #346

[nlwillia]

I'd guess that there's sufficient inertia in how libphonenumber has chosen to structure their metadata (given the huge investment they've made in compiling and normalizing it) that this approach would be as stable as any other integration point you currently have. Removing NA formats might be mildly opportunistic, but it's not like there are a ton of them, and for the US it's going to be a correct change for most purposes.

If you end up keeping the autoformatter then I think the questions are whether you continue just publishing an unabridged utils.js and let others do their own builds, publishing a choice of raw or curated builds or only publishing a curated build. And if you publish a curated build, whether that's based on a fixed list of known problem cases or on a rule like NA. Either way you can automate it.

[jackocnr]

Removed autoFormat in v8.0.0, so closing this now. Thanks again for your input.