[FormBuilderTextField] Expose `FormBuilderTextFieldState` and `effectiveController`

[mernen]

Environment

Package version: 7.7.0

Description

What you'd like to happen: it would be occasionally handy to have access to the FormBuilderTextFieldState class, and effectiveController.

For example, I'd like to create a ClearFieldButton widget that shows a button for clearing the text field only when it's not empty. The ideal API (for ergonomics and practicality) would be:

FormBuilderTextField(
  name: 'example',
  decoration: InputDecoration(suffixIcon: const ClearFieldButton()),
)

Such a widget could implicitly find the text field's text controller by doing:

var controller = context.findAncestorStateOfType<FormBuilderTextFieldState>().effectiveController;

Unfortunately, though, both _FormBuilderTextFieldState and _effectiveController are currently private.

Alternatives you've considered: since FormBuilderTextField has a controller parameter, having a clear button is achievable by handling one's own TextEditingController:

// Not pictured: instantiating and disposing _controller

FormBuilderTextField(
  name: 'example',
  controller: _controller,
  decoration: InputDecoration(
    suffixIcon: ClearFieldButton(controller: _controller),
  ),
)

This is significantly more cumbersome, though, especially for larger forms, where flutter_form_builder usually excels.

[deandreamatias]

Hi @mernen !
Thanks for your contribution.
This controller in FormBuilderTextField don't is enought to that you want?

flutter_form_builder/lib/src/fields/form_builder_text_field.dart

Line 13 in 722cda4

final TextEditingController? controller;

You can use some like this example too
https://github.com/flutter-form-builder-ecosystem/flutter_form_builder#implement-reset-clear-or-other-button-into-formbuilderfield

[mernen]

Providing a custom text editing controller is workable, but then requires either several lines of handling and disposing the controller, or using hooks. This is fine for screens with a text field or two (I've actually implemented it this way in key parts), but if you're using flutter_form_builder you probably have many fields, and you picked the library precisely because it cuts so much boilerplate compared to Flutter's built-in form handling.

The problem with the given example is that I'd like for the button to only appear when the field is not empty, and AFAIK currently the only way to achieve that is through the TextEditingController. (An alternative would be if FormBuilderFieldState implemented Listenable)

Here's an example of an implementation I would like to achieve: it could work either with arbitrary controllers, or just integrate automatically with FormBuilderTextFields, as they are the most common case.

class ClearFieldButton extends StatelessWidget {
  const ClearFieldButton({super.key, this.controller});

  /// The [TextEditingController] to clear.
  /// Optional when used with a [FormBuilderTextField].
  final TextEditingController? controller;

  @override
  Widget build(BuildContext context) {
    // Being able to automatically integrate with FormBuilderTextField would be really convenient!
    var controller = this.controller ??
        context.findAncestorStateOfType<FormBuilderTextFieldState>()!.effectiveController;

    return ValueListenableBuilder<TextEditingValue>(
      valueListenable: controller,
      child: IconButton(
        onPressed: controller.clear,
        tooltip: 'Clear',
        icon: const Icon(Icons.clear),
      ),
      builder: (context, value, child) =>
          value.text.isEmpty ? const SizedBox() : child!,
    );
  }
}

[deandreamatias]

Ok perfect, make sense.
Currrently this States isn't public because a old change to fix lint analysis. I think that no has problem to change, but i don't if is a good practice make this State public. Why:

1. Maybe some people will confuse to import widget. FormBuilderTextField and FormBuilderTextFieldState
2. When create a StatefulWidget, Flutter make the State private by default
3. You can access to effective controller, but can access to another things too

[deandreamatias]

@mernen I found a solution that satisfies both:

You would create a separated widget with your text field configuration: clear button, validations and etc.
Here need to add somethings:

1. A fieldFormKey or a formKey
2. A ValueNotifier to text value
3. Reactive when TextField change and update the value notifier
4. Listen this ValueNotifier and show clear button when isNotEmpty
5. On clear button, call didChange to reset textField value or other method, like reset()

class _ClearFormBuilderTextFieldState
    extends State<_ClearFormBuilderTextField> {
  final ValueNotifier<String?> text = ValueNotifier<String?>(null);
  final textFieldKey = GlobalKey<FormBuilderFieldState>();

  @override
  Widget build(BuildContext context) {
    return FormBuilderTextField(
      autovalidateMode: AutovalidateMode.always,
      name: 'age',
      key: textFieldKey,
      onChanged: (value) {
        text.value = value;
      },
      decoration: InputDecoration(
        labelText: 'Age',
        suffixIcon: ValueListenableBuilder<String?>(
          valueListenable: text,
          child: IconButton(
            onPressed: () => textFieldKey.currentState?.didChange(null),
            tooltip: 'Clear',
            icon: const Icon(Icons.clear),
          ),
          builder: (context, value, child) =>
              (value?.isEmpty ?? true) ? const SizedBox() : child!,
        ),
      ),
    );
  }
}

I think that is the best solution to maintain the good practices that I mentioned before

[mernen]

That's not really a solution to me because I'd like the button to be composable, rather than baked into one specific kind of text field — we have multiple text field widgets in our app, and duplicating the clear-button logic on each would add quite a bit of code and responsibilities to them. Having a single input decoration widget that interacts with any parent seems like a cleaner solution.

I'm a bit torn here — I do think exposing the state is generally useful for those who want to create custom text fields, but I can also see that, from your side, exposing the state is no small commitment, especially if others aren't demanding it.

In the end we wound up creating our own FormBuilderTextField replacement to be used as the base class for all text fields in our design system. It's a bit cumbersome because creating a FormBuilderField widget is a lot of work (way too many fields to pass around!), but this is a separate issue that may require a radically different API design from FlutterFormBuilder, or might be alleviated with future Dart features, such as argument spreading.

[deandreamatias]

Hi @mernen
Thanks for your response and understanding of the situation. I really would like found a perfect solution for both sides, but I think that is hard.

In the past days, I thought about this package and some ways to improve the API to make more flexible but at same time consistent for Flutter developers. One of ideas was this PR, but I think that in future, will appear more functionalities and ideas.

If you can stay around to help on package improvement, I will appreciate your contributions.
Thanks!

[deandreamatias]

Hi @mernen
Maybe this flutter-form-builder-ecosystem/form_builder_phone_field#43 can discover a solution to this issue