input phone: do not require space separator between country code and local phone number

[MarekLacoAXA]

Feature request to allow omitting space separator between country code and local phone number.

We need a drop-in replacement for input-text where the input is a whole phone number as-is

We don't want to parse the existing phone numbers to find country codes and artificaly inject spaces after country code in order to be it processable by input-phone component.

Thanks!

[markus-walther]

@MarekLacoAXA It seems impossible in general to omit a separator (of any kind, space being just one possible choice) between country-code part and local-phone-number part of a telephone-number string.

This is because country codes are not unambiguous world-wide.

For example, the country code of Switzerland (+41) is a proper prefix of the country code of Liechtenstein (+417), and it would require knowledge of the entire allowed local-phone-number space of both countries to parse a given separator-free string into its two parts (note that there are many Swiss mobile numbers starting with +417 that are not from Liechtenstein)!

[MarekLacoAXA]

Here is a lib and its phone numbers namespace knowledge: https://github.com/catamphetamine/libphonenumber-js/blob/master/PhoneNumberMetadata.xml

[markus-walther]

The original ticket description is ambiguous and imprecise. Here is a spec proposal:

1. Add new property longestMatchParse (default: false).
2. When longestMatchParse is truthy, augment the component's behaviour to parse a user-entered cleaned composite phone number of format +ddd...d (d a digit) using a longest-match strategy into an initial country code taken from https://countrycode.org/ and a phone number proper.
3. Cleaned in step 2 means that user-entered input is stripped of spaces, dots and dashes (existing behaviour).
4. Step 2 can fail because the expected format is not found or because a county code not from https://countrycode.org/ was entered or because the number is invalid according to https://github.com/axa-ch-webhub-cloud/pattern-library/blob/develop/src/components/20-molecules/input-phone/index.js#L24.
5. Step 2 failure leads to rendering the invalid error, like with existing behaviour.
6. Step 2 success sets the country-code dropdown to the country whose code was parsed and rewrites the phone-number input field content to the phone number proper parsed.
7. Step 2 is applied on blur of the phone-number input field (for good UX, analogous to input-text PL component).
8. Step 2 can lead to an ambiguous parse result: the same country code may correspond to > 1 country (e.g. +1 corresponds to USA and Canada). Therefore, for all ambiguous parse results, interpret 'country' in step 6 as the forward-slash-separated concatenation of the countries sharing the same country code, in lexicographic order (e.g. 'Canada/USA').
9. No other behaviour of the existing component is changed.

[markus-walther]

@MarekLacoAXA Is the aforementioned spec good for you?

[MarekLacoAXA]

Hi @markus-walther !

Quick&short answers for now:

As a consumer of phone-number-input:

• I need to have "drop-in" / "plug-and-play" replacement for text-input:
• this means ONE INPUT => ONE OUTPUT and no surprises when ANY value passed (invalid input => invalid output, no MANGLING of input on focus/blur: output stays the same as input unless user did a change by intention)
• without having the above, I won't use the component, as I don't dare to submit unwanted customer-data modifications
• IF a country can be identified (or is chosen), then show Flag or Country name (this is IMO the main purpose of the component)
• longestMatchParse is an implementation detail and as a consumer do not need to know/specify which algorithm would be used to identify a country.

Thanks!

[MarekLacoAXA]

1. Add new property longestMatchParse (default: false).

I am not a fond of this. Would prefer to process numbers automatically instead.

2. When longestMatchParse is truthy, augment the component's behaviour to parse a user-entered cleaned composite phone number of format +ddd...d (d a digit) using a longest-match strategy into an initial country code taken from https://countrycode.org/ and a phone number proper.

"user-entered" -- to you mean here paste into field by end-user, or providing value attribute by consumer sw, or both?

If the longest-match strategy is sufficient: I can't judge, but I think it is a good start. It would be great to have a set of unit tests containing a couple of dozens of European numbers: testing if parsing country works ok using this strategy. Over time, IF cases show up where longest-match strategy is insufficient, then we can still improve strategy (add exceptions), or change strategy (use the disliked 140kb google lib).

3. Cleaned in step 2 means that user-entered input is stripped of spaces, dots and dashes (existing behaviour).

Unsure who cleans the number. Component itself or the consumer?

4. Step 2 can fail because the expected format is not found or because a county code not from https://countrycode.org/ was entered or because the number is invalid according to https://github.com/axa-ch-webhub-cloud/pattern-library/blob/develop/src/components/20-molecules/input-phone/index.js#L24.

yes, fail of parsing country is normal.

5. Step 2 failure leads to rendering the invalid error, like with existing behaviour.

agree

6. Step 2 success sets the country-code dropdown to the country whose code was parsed and rewrites the phone-number input field content to the phone number proper parsed.

agree

what happens on fail with the previous selected country? will be reset to empty?

7. Step 2 is applied on blur of the phone-number input field (for good UX, analogous to input-text PL component).

seems okay

8. Step 2 can lead to an ambiguous parse result: the same country code may correspond to > 1 country (e.g. +1 corresponds to USA and Canada). Therefore, for all ambiguous parse results, interpret 'country' in step 6 as the forward-slash-separated concatenation of the countries sharing the same country code, in lexicographic order (e.g. 'Canada/USA').

agree

9. No other behaviour of the existing component is changed.

can't judge

Thanks!

[markus-walther]

1. Add new property longestMatchParse (default: false).

I am not a fond of this. Would prefer to process numbers automatically instead.

APIs are a contract. PL APIs should be backwards-compatible. Hence a new property, so old behaviour is not gone for users that have built on it already.

2. When longestMatchParse is truthy, augment the component's behaviour to parse a user-entered cleaned composite phone number of format +ddd...d (d a digit) using a longest-match strategy into an initial country code taken from https://countrycode.org/ and a phone number proper.

"user-entered" -- to you mean here paste into field by end-user, or providing value attribute by consumer sw, or both?

User = end user. In ticket https://github.com/axa-ch-webhub-cloud/pattern-library/issues/2275 the other case is discussed.

If the longest-match strategy is sufficient: I can't judge, but I think it is a good start. It would be great to have a set of unit tests containing a couple of dozens of European numbers: testing if parsing country works ok using this strategy. Over time, IF cases show up where longest-match strategy is insufficient, then we can still improve strategy (add exceptions), or change strategy (use the disliked 140kb google lib).

This is entirely the job of the application, in this case you, to research data entry patterns occurring in the wild and possible reactions to this (including the possibility that phone numbers should be processed by backend).

Longest-match is a generic strategy that was proposed by you. It does not need excessive new tables that would bloat the component.

It would parse +14411235678 to +1441 (Bermuda) 1235678 (phone number) and not e.g. +1 (Canada/USA) ..., because +1441 is the longest prefix that can be matched to a country code.

3. Cleaned in step 2 means that user-entered input is stripped of spaces, dots and dashes (existing behaviour).

Unsure who cleans the number. Component itself or the consumer?

The component.

[MarekLacoAXA]

It would parse +14411235678 to +1441 (Bermuda) 1235678 (phone number) and not e.g. +1 (Canada/USA) ..., because +1441 is the longest prefix that can be matched to a country code.

Is this a problem or is this okay?