Phone parsing

[nicolasburtey]

Some country code have a 0 for local phone. This lead to an error if not removed by the user

Ie: +33 06 versus +33 6

[nicolasburtey]

also: (123) 123 1234 shows as error in the mobile app (because of the parenthesis)

[MaxwellDG]

I'll look into this one.

@nicolasburtey Could you elaborate on the first task? I don't understand what you mean here. Is it automatically formatting numbers that start with zero to remove the zero?

[nicolasburtey]

I'll look into this one.

@nicolasburtey Could you elaborate on the first task? I don't understand what you mean here. Is it automatically formatting numbers that start with zero to remove the zero?

some numbers, in some countries have different ways to be accessed.

ie in France: +33 6 01 23 45 67 89 and + 33 06 01 23 45 67 89 both leads to the same underlying "phone"

the canonical number should be +33 6 01 23 45 67 89 but if the user enter +33 06 01 23 45 67 89 we should automatically erase the 0

the idea is to explore the api of libphonenumber-js and see if there are ways to address this.

[MaxwellDG]

Okay I get what you're saying. I'll take a look into it tomorrow.

[MaxwellDG]

@nicolasburtey The behaviour you're asking for looks like it's already there.

This input:

Results in this value being parsed without the leading 0:

Which is then saved and used without the leading zero afterwards:

The only additional behaviour I could see is if you want the input field to be formatted without the 0, but I wouldn't recommend that. I think that'd be uncomfortable for the user to see their input changed as they type.

[MaxwellDG]

I'm also not able to replicate the 2nd error with the parentheses. I did however think I did when I pressed 'back' and returned to the screen to try again. It had reverted to the first country code and therefore gave me an error because the areacode wasn't applicable to that country. For testing I'll need a screenshot or at least a specific number + country combination that should work but doesn't.

[nicolasburtey]

@nicolasburtey The behaviour you're asking for looks like it's already there.

This input:

Results in this value being parsed without the leading 0:

Which is then saved and used without the leading zero afterwards:

The only additional behaviour I could see is if you want the input field to be formatted without the 0, but I wouldn't recommend that. I think that'd be uncomfortable for the user to see their input changed as they type.

I think in that case, in the confirmation screen, we should show the canonical number. this is really the number that is saved in the system, so if the person contact the support for instance, the support would know what to look for

[MaxwellDG]

@nicolasburtey The behaviour you're asking for looks like it's already there. This input: Results in this value being parsed without the leading 0: Which is then saved and used without the leading zero afterwards: The only additional behaviour I could see is if you want the input field to be formatted without the 0, but I wouldn't recommend that. I think that'd be uncomfortable for the user to see their input changed as they type.

I think in that case, in the confirmation screen, we should show the canonical number. this is really the number that is saved in the system, so if the person contact the support for instance, the support would know what to look for

I know it looks like it's not in the example we used, but the confirmation screen has the canonical number already. I think you might be being tricked by the two zeros we both used in our example lol 0601234567. In our example/test the country code is +33 and the phone number is 601234567 (formatted from 0601234567).