This approach introduces limitations for more advanced TextField use cases. If implemented, it might be provided as an optional feature for a basic scenario.

What limitations? I am not restricting the API, just expanding it. You can still use a controller, as I said and explained how an assert would work to validate the fields, hence as controller is still there.

I am labelling this as a proposal to add text/value parameter to textfield/textformfield

@maheshj01 can you please assign this to me? I can look into this

I don't get this change, there is onChanged: onTextChanged callback. If custom state handling is needed, it usually require large flexibility and onChanged is the way to go. I don't see the boilerplate.

@iamdipanshusingh Please wait until the secondary triage takes a look at this issue and this is prioritized. So that we know this is something flutter team would be interested to work on in the near future.

I don't get this change, there is onChanged: onTextChanged callback. If custom state handling is needed, it usually require large flexibility and onChanged is the way to go. I don't see the boilerplate.

Most of the Flutter widgets work in a reactive manner where they inform they changed and they accept a value. By changing the value in the widget's constructor, the widget reacts.

TextField only does half of this, it only informs change. It can't be updated in a declarative manner, it can't react to change, unless we use the controller in an imperative manner, not declarative.

Thus, if my state manager (e.g. Bloc) has a new state, and I have to update a form with 10 TextFields, then I need to create 10 TextEditingControllers, their variables, initialise them, and not forget to dispose them, and set them when the state changes. That's a lot of extra boilerplate if you ever had to deal with forms and values coming from other sources.

The TextEditingController has its benefits, it allows us to control lots of things and also get notified of changes, but for the vast majority of cases we only want to set the text and get change notifications, and having this at the widget level will simplify these flows a lot.

Got it. Actually it would be useful in that specific case 👍

I've wanted to do this kind of thing for so long. This was the very first quirk that bugged me about Flutter when I started using it in 2018. Coming from React at the time, I much preferred the declarative approach. Since then I have been secretly hoping to find a good reason to make it declarative or at least find some clear counterexample to show that we shouldn't.

First hurdle: The parameter should probably be textEditingValue instead of text so that it supports selection and composing (see TextEditingValue). But unfortunately onChanged is called with a String instead of a TextEditingValue. Maybe we should also add an onChangedValue parameter or something.

Then we'd have to make sure that this approach generally works with all of our existing text input features. For example, TextInputFormatter would be one to check. There's probably a lot of other stuff to worry about.

The first step should probably be to just try it out. Add textEditingValue and onChangedValue to EditableText and open a draft PR and see how it works.

If we can get it to work with everything and the API is not too confusing being alongside of TextEditingController, then I think I would approve that 👍

@justinmc good to hear.

This was honestly my first line if thought, but I also wasn't sure if this change wouldn't be too big, and that's why I said that just adding the option for text won't be the perfect solution but would already solve the vast majority of cases we need.

So IMO I agree with your plan, but if at the end you discover that it can't work, than I wouldn't scrap this, I would instead add the option to only set the text and get a solution that's not perfect, but still a lot more helpful than having nothing.

I created this initial draft. I might scrape it though 😅 as I think @justinmc's proposal seems to cover all the editable texts. Will have to see how TextEditingValue works.

In my case, I modified how the local controller is being created, and on didUpdateWidget I'm disposing the previous controller, and then assigning a new one, which is quite a dirty work, but works :)

Example app:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatefulWidget {
  const MyApp({super.key});

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  int counter = 0;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: Padding(
            padding: const EdgeInsets.all(8.0),
            child: Column(
              mainAxisSize: MainAxisSize.min,
              children: [
                TextField(text: 'initial text $counter'),
                FilledButton(
                  onPressed: () {
                    setState(() {
                      counter++;
                    });
                  },
                  child: Text("increment!"),
                ),
              ],
            ),
          ),
        ),
      ),
    );
  }
}