Flutter_form_builder: [Feature Request] International phone input

[jasonlaw]

Hi @danvick ,

Can I request for an international phone input field?

https://github.com/niinyarko/flutter-international-phone-input

Thanks in advance.

[VOIDCRUSHER]

@jasonlaw , I would recommend using a package backed by an implementation of Google's libphonenumber parsing library, such as this one:

https://github.com/natintosh/intl-phone-number-input

I'm not sure how soon this could be added to this package but in the meantime, it looks like we can wrap this widget with a FormBuilderCustomField like so:

FormBuilderCustomField(
  attribute: "name",
  validators: [
    FormBuilderValidators.required(),
  ],
  formField: FormField(
    enabled: true,
    builder: (FormFieldState<dynamic> field) {
      return InternationalPhoneNumberInput.withCustomBorder(
        onInputChanged: (PhoneNumber number) {
            field.didChange(number);
        },
        inputBorder: OutlineInputBorder(),
        hintText: '[phone] 8901',
        initialCountry2LetterCode: 'US',
        errorMessage: 'Wrong number',
      );
    },
  ),
)

I haven't really tested this out so some changes might be warranted but hopefully helps. If you find a solution that works please post it back here!

[danvick]

Hi @danvick ,

Can I request for an international phone input field?

https://github.com/niinyarko/flutter-international-phone-input

Thanks in advance.

Hi @jasonlaw,
Will consider this in the next minor update.
Your feedback is a always welcome.
Cheers!

[danvick]

By the way @VOIDCRUSHER / @jasonlaw,
Has a consensus been reached about the package to utilize between the two suggested?

[jasonlaw]

Hi @danvick ,

I think the package is great and thanks for the consideration to include the feature into this great package, really appreciate it!

Thanks!

[VOIDCRUSHER]

@jasonlaw @danvick, I'm not sure if the community has made a consensus on which to use. Both seem to have similar stats on pub.dev and GitHub and both are using libphonenumber to handle parsing. I personally have a strong preference for https://github.com/natintosh/intl-phone-number-input/ in how it exposes it's field's InputDecoration parameter for greater control over it's appearance rather than just the two TextStyle fields offered in the other.

[jasonlaw]

Sorry for not being clear before, I mean package "natintosh/intl-phone-number-input" looks great to me and appreciate it to be part of the form builder package.

[danvick]

I've had a chance to look at the package and it contains a few issues which make it a challenge to integrate it into ours. Here are a few I've noticed:

1. onInputChanged is only fired if the phone number is valid. This means that if a user enters a valid number then deletes it, the number is still kept on the background. This is the biggest blocker.

1. Phone validation should have been left to the user so that we can react to input errors ourselves

2. I'd have liked the dropdown to have been ordered in order of the country code instead of names (flags). It becomes a bit hard to search for your flag. Because you need to know which countries are alphabetically located next to yours then know their flags, in order to find yours.

[danvick]

Now, with this said, we can raise these issues on the package repo or we could, submit PRs to help out the maintainer.
In the mean time I'll explore the other package.

[VOIDCRUSHER]

onInputChanged is only fired if the phone number is valid. This means that if a user enters a valid number then deletes it, the number is still kept on the background. This is the biggest blocker.

If they changed it to a TextFieldForm, wouldn't you still be able to get the fields true value regardless? I'm with you on having onInputChanged called unconditionally returning the values the user passed in so we can respond accordingly.

Phone validation should have been left to the user so that we can react to input errors ourselves

I can see the case for exposing an on Error or onValidate handler to catch the result but I don't think phone validation should ever be left to the developer, rather than using libphonenumber's parser. A phone input form is a special text field where I want to validate a phone number and maybe pass it on if it validates. It's not my call of course but I think It's a narrow enough use case where I think it might be ok if the list of validators is ignored.

[awhitford]

I too am interested in an _International Phone Input_ field. Is this a duplicate of #66?

Has anyone looked at the international_phone_input package?

[danvick]

Hi all,
FormBuilderPhoneField has been implemented in v3.10.0.

Due to some issues we had in the phone input packages we had tried to use initially, we've decided to take a different approach altogether.

Let's kindly give feedback on that. In the meantime, I'm gonna close this issue.

[awhitford]

Does an autocorrect flag have any meaning to FormBuilderPhoneField?

[awhitford]

I just tried this:

          FormBuilderPhoneField(
            attribute: 'recipientPhone',
            decoration: const InputDecoration(
              icon: const Icon(Icons.smartphone),
              labelText: 'Mobile Phone (Text/SMS)',
            ),
            textInputAction: TextInputAction.next,
            maxLength: 20,
          ),

and I got:

[VERBOSE-2:ui_dart_state.cc(157)] Unhandled Exception: NoSuchMethodError: The getter 'isNotEmpty' was called on null.
Receiver: null
Tried calling: isNotEmpty
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:53:5)
#1      FormBuilderPhoneFieldState._parsePhone (package:flutter_form_builder/src/fields/form_builder_phone_field.dart:158:23)
#2      FormBuilderPhoneFieldState.initState (package:flutter_form_builder/src/fields/form_builder_phone_field.dart:150:5)
#3      StatefulElement._firstBuild (package:flutter/src/widgets/framework.dart:4640:58)
#4      ComponentElement.mount (package:flutter/src/widgets/framework.dart:4476:5)
#5      Element.inflateWidget (package:flutter/src/widgets/framework.dart:3446:14)
#6      MultiChildRenderObjectElement.mount (package:flutter/src/widgets/framework.dart:5947:32)
#7      Element.inflateWidget (package:flutter/src/widgets/framework.dart:3446:14)
#8      Element.updateChild (package:flutter/src/widgets/framework.dart:3214:18)
#9      SingleChildRen<…>

I was able to resolve it by specifying an initialValue:

            initialValue: '',

Obviously, I'd expect initialValue to be _optional_ like the other classes.

[danvick]

Thanks for the prompt feedback. I'll work on a fix promptly

[awhitford]

Validation: I would like there to be a way to ensure that the phone number is valid. So far, it appears that any gibberish entered into the field is accepted. _Is that intentional? Should it be restricted to numbers and some symbols?_

Also weird is that I figured that at least I could specify a minimum length to improve the probability of a legitimate phone number, however adding minLength did not have any impact:

            validators: [
              FormBuilderValidators.minLength(10, allowEmpty: true),
            ],

Logic with 100% accuracy to completely ensure that a phone number is valid is likely not realistic (and the rules will change over time). However, some basic input validation is reasonable.

[VOIDCRUSHER]

@awhitford Unfortunately, those checks are not strong enough to determine whether the number is valid. For this, you would want to use libphonenumber, which is the dart port of google's phone number parsing library. To hack this together, you would want to either create your own FormBuilderValidator that invokes libphonenumber's parser or maybe just a FormBuilderCustomField that includes this functionality. The key is to always use libphonenumber, it's the industry standard now.

[awhitford]

@VOIDCRUSHER Yes, using libphonenumber would be ideal, and maybe the ultimate goal. That library offers formatAsYouType feature too, which ideally would be leveraged.

The first iteration of FormBuilderPhoneField is an improvement over a vanilla FormBuilderTextField, except that it is presently unusable to me because validation is not working at all.

[awhitford]

FormBuilderPhoneField wraps phone_number, which "uses the native libraries libphonenumber for Android and PhoneNumberKit pod for iOS." So ideally that widget is leveraging those libraries for the best experience.

Ultimately, I am seeking a valid phone number in E.164 format, which it appears that the package supports. (Twilio offers a Free Format Lookup API, but I don't think that will be necessary.)

While E.164 is the preferred _value_ format, for presentation to the user, showing the numbers grouped is usually nicer, like: [ +49 ] 30 123 123 123.

[awhitford]

I finally figured out why the Phone Field validation was not working, and submitted PR #307 to fix it.

I am now anxious for your next release. 😃