All language subtitles for 19. Fetching User Input

So having the button is good, but of course, you want to actually add a new transaction when we press

it for dad, we first of all need to collect the user input.

It's good that we have these text fields.

But how can we get access to what the user entered?

There are two ways of getting access.

It's up to you which one you choose.

It also depends on the complexity of the form you're building.

The first way of getting access is that you simply saved the user input with every keystroke that you

save it in a property.

Now, for that, we need a property in which we can save it and we can add it here to our widget.

But keep in mind that this is a stateless widget.

And what does this mean?

It means that any data we have in there, like the transactions property is immutable.

We can't change it.

Well, technically, we can change it, but our changes will never be reflected on the user interface.

Now, actually, here, that wouldn't be a problem because with every keystroke we could save the day

that a user entered and then only do something once we hit a button.

So it's actually okay if we just save changes without updating the user interface because there is no

update.

We want to perform with every keystroke.

We just want to save the data behind the scenes.

And we can do that because a stateless widget is still a objects to look normal class.

So we can't have properties in there, which we can change.

We just can't rerun the build method.

We can't use set state here.

But again, that won't be needed.

So what you can do, therefore, is you can add new properties here to your class maybe.

A string title input and another string amount input, that's, by the way, important, the input values

are always strings by default.

If you need a different value, like a number here for the amount, then you need to convert it manually.

So we have these two strings.

And now if we go down to our textfield stair, you can add the on changed listener.

Now on changed will fire with every keystroke.

As you see, you have a couple of our listeners to on editing complete as fired when the user presses

the Dunn Go or next or whatever it is, button into soft keyboard.

So that would basically be that button in the bottom right corner that can have a different look and

meaning.

And you can configure that actually by way.

You can ignore this here for now.

This strange yellow thing, your so that is on editing complete that it's fired when that button is

pressed on.

Submitted is kind of related, but this fires whenever the done button is pressed.

So not on every button in the bottom right corner basically, but only for that.

Dunbarton and if you configured your text few to show a different button there then would not fire.

And on tap is fired whenever you tap into the textfield.

Now, here we need unchanged because unchanged fires for every keystroke on changed then requires us

to pass a reference, a pointer at a function which takes a string value.

So not a function that has no arguments, but a function that accepts exactly one argument, which is

of type string.

And that then returns nothing.

You can use a named function here or you define an anonymous function.

However, as it just explained, it needs to be a function which takes value.

You don't need to add to type here because Dart is smart enough to infer this because on changed expects

a function that takes a string argument.

Dart automatically understands that value here will be of type string.

You also don't have to name this value.

You can name it Val, whatever you want.

So now we get this.

We have this function.

It will be triggered for every keystroke.

And then in here, since we're editing the title here, we can set title input equal to velt.

So that means we overwrite the current value of title input with the input the user chose here.

So with the current input off that text, input off the TextField.

We can do the same for the amount.

Add on changed here, gets to value and then we can all use Ted Shorter notation with the arrow because

we have only one expression.

Dear, we can set amount input equal to VLT.

With that, we have a setup where we register every keystroke.

And now we save that in our title input and any amount input.

Again, the UI won't be updated because we're not calling set state and we couldn't call it because

we're in a state.

This widget.

But that's not required here.

To prove that it worked here, when we pressed that ad transaction button, I will print the title input

so the value is stored in there and also the amount input.

Let's save all of that.

And again, you can't ignore this yellow black thing, you're at the bottom.

I will explain what's up with that later.

And for the moment, we can enter some amount here, like twelve dot ninety nine.

And here we can enter a title like.

Test and you could use your physical keyboard for this, too.

If you don't hit ad transaction, you see test and 12 99 output here because these values were saved

with every keystroke and therefore we can also use them.

The only thing we can do right now is update our user interface based on that.

Registering the input on every keystroke is perfectly fine.

However, here, Flattr actually complains or gives us a warning.

That is my home page Closs, which is marked as immutable.

That's basically a flag to stateless, which it sets, has a field, a property which changes or which

is not final.

That's true.

Title input and amount input are not final.

They can change.

And actually the case we have here is a pretty neat case.

Normally you don't have changeable properties in a stateless widget because you can't update UI based

on these changes anyways.

This is one of the rare cases where we save some data and where we are perfectly fine with that, having

no direct impact on the user interface.

Still, you might want to consider turning this entire widget into a state full widget to get rid of

that wording.

And also to avoid an error which will run into later or a little issue which will run into later, which

it will fix later, though.

So we'll then see how to work around that.

Nonetheless, for the moment, this year will work and we can leave it like this for the moment.

Now we'll have a problem anyways.

I, of course, don't just want to print my results here.

I want to create a new element or new transaction.

And Dad, in the end should then also lead to some output on the screen because transactions are a list

here should then actually change and hold that new transaction.

So.

We'll have to switch to a stateful, which is at some point anyways before we do so, however, let

me first of all show you an alternative to registering this manually on every keystroke whilst you can

do this.

And whilst this is especially useful, if you have more complex logic that you maybe want to run on,

every keystroke, flutter actually has a built in mechanism that allows you to listen to every keystroke

and then get the finished value once you're done for dad.

I'll comment out the title and put an amount and put and I'll add two new properties which now are final

and add as the title controller, which is created with a value of text editing controller and it's

De Amount controller, which is also a text editing controller.

Text editing controller is a class provided by Flutter.

And you can assign such a controller to your text fields with the help of the controller argument.

So now to the title TextField.

I add my title controller and to the amount TextField here I'll add my amount controller.

Now what do these controllers do?

Flutter automatically connects to controllers with our TextField and these controllers.

Me and listen to the user input and safety user input and they have four here in on prest.

We can then print title controller DOT text to get access to that safe text.

Hence now if I go back and I type something here and I hit done and then at transaction I see test here.

So this is of course a more convenient way because you don't have to manually write a function that

takes a value and just say, sit in a property.

And in addition, as an extra benefit, this is not always a solution because these properties are final

and the heavy lifting of saving stuff is done by flutter.

This is now a solution.

Flutter all likes in a stateless which it.

Nonetheless, the days of us using a stateless widgets were at least of only using stateless widgets

are coming to an end because we will have to change this to a state full widget in order to update our

list of transactions and reflect that change on the user interface, where, of course, for every new

transaction, a new transaction card should be out, put down their.