All language subtitles for 41. Splitting the App Into Widgets

Now what have we added this ternary expression, we covered a lot of the core fundamentals of both Dart

and Flutter.

Now obviously there's way more to learn,

otherwise there wouldn't be more course content left

but it's an important first step.

This ternary expression down there however could be kind of difficult to read. If you will have a look

at this, it might not be obvious on first side what's going on here,

especially because we have this quite complex column in between and to be honest, it isn't even that

complex.

You can and you will throughout this course have way more complex widget structures than this column here

and what could we do about that to make that more readable? If you want to make your widget tree more

readable and more manageable,

one thing that should always come to your mind is splitting that. You can of course split your widgets

into sub-widgets,

the question always is, should you split it?

Well, let's assume you have a bigger widget with a lot of different nested widgets which you pass in

to each other and so on. Then of course you can always split this into a separate sub-widgets which take

these individual tasks and the question is, should you do that?

Now in general

and that's really something you can memorize, in Flutter,

it's always encouraged to create more than less widgets.

Of course you should not wrap every single built-in widget into your own custom widget and you will

get a feeling for when the right point to split your widgets is there

but overall, it's better to have smaller widgets than large widgets.

It's better to have a readable code than unreadable, really entangled code It's better because it makes

your code easier to manage for you and your fellow developers

but it's also better for performance,

that is something I'll dive in later though.

So in our application which we have here, it might be worth considering putting the column here but also

the center widget into a separate widget.

Now of course, the center widget is not really complex at all and it would be fine to leave it here

but I do plan on adding more content to it.

So therefore, I will add two new widgets here - quiz.dart and result.dart. Now in my

quiz.dart file, I'll create a stateless widget, quiz, where I import the Flutter material.dart file as always

and then we can take this column which we have in the main.dart file, grab it and add it here instead

of that container as a return value for the build method.

Now of course in here, we're referring to the question and to the answer widgets,

so what we should do here is we should import both, we should import question.dart and we should import

./answer.dart to unlock these widgets here in this file and I'm referring to the questions list

and also to the answer question function.

Now of course you could now think that you want to turn quiz into a stateful widget now because

now we have both the question and the answers in here,

so we could manage everything for that in this widget

but please keep in mind that in order to show the result which we want to do in the main.dart file and

not in the quiz.dart file, otherwise we would basically transfer the ternary expression also into the

quiz.dart file, because we need to manage that condition in the main.dart file,

we want to keep our state in here.

So instead what I want to do is here in the main.dart file, instead of importing the question, I import

the quiz.dart file and that allows me to use the quiz widget here if this condition is met,

so often the question mark here in the body and to the quiz widget, we should pass both our questions

list and our answer question function and that of course means that we forward this answer question

function through two levels of widget. We pass it from the MyApp widget in the main.dart file to the

quiz widget and in the quiz widget, we forward it to the answer widget. But it is what it is, it still

is a leaner setup where we manage the state on the highest level that makes sense, where we then also

can still control whether to show the quiz or our result which we'll soon show here.

So that means I want to forward a pointer at answer question to quiz and I also want to forward questions

and as a side note because I forgot this earlier, since questions is now a property of the entire class,

it should of course be _questions to be in line with for example the question index here because

it is a private property that's only available in MyAppState.

So change questions to _questions, change it in all the places where you use it, like here in

the condition and here where you pass it down and now in the quiz widget here, we want to accept

both that function, that answer question function and our questions list here. For that let's add two

final properties here as you learned it, runtime constant values which are initialized when our app starts

but thereafter they don't change and here, we have our list of maps, where each map also has different

values, it holds string keys and object values, so we have these nested generic assignments here. So we

have our list of questions and we also have a function which I'll name

answerQuestion, without an underscore here because this widget is not private,

it should be used from inside other files.

So here, I then also add a constructor and to mix it up, not because it's required but to mix it up,

I'll use named arguments here, so I'll have my questions list and I have my answer

question

function here.

Now the problem is I also need to know which question we're looking at,

so let's also accept our question index here

which should be an integer and also add this as a named argument here to the quiz widget

and then here I use question index, without the underscore and here, answer question without the underscore

and therefore this should all work

and now in main.dart where we use this quiz widget, we now have to pass these values as named arguments.

I also want to add, before I pass it, I want to add required, @required in front of all these arguments,

@required is a decorator provided by material.dart and it basically tells Flutter that all these

values are required, that we must not omit a single one of them.

So if you tried to create this quiz widget with only one or two or none of these arguments here, we would

get an error.

So now of course we have to create that quiz widget,

we do that in MyAppState class in the main.dart file.

Here's the quiz widget

and now let's assign values to our named arguments.

If we place the cursor between the parentheses and we hit control space, we get some IDE support and

for answer question which is my function pointer here, I want to point at _answerQuestion,

so my function I have here in the MyAppState class. At question index, there I want to pass

_questionIndex which is the property managed here in my MyAppState class and at questions, I will

pass _questions.

So now we're creating that quiz widget with that data forwarded to it, might look a bit redundant but

still, I'd say that is now cleaner here than having the column in here.

Let's now also outsource of course our result,

so that center widget. Here in result.dart, I again create a stateless widget which I'll name result and

in there, I import package:flutter/material.dart like before and instead of returning a container, i return

center.

Now we just need to use that result widget here,

so after the colon, we can use result, like that. For that to be available of course, we need to import it

though, you always need to import what you use,

so let's import result.dart. With all of that out of the way, let's restart

the app

by pressing the green refresh button here and let's see whether that works as it should. We see the

questions and answers and I can tap them and if I tap my buttons three times, I see you did it.

Of course that was a lot of work for the same result as before but Flutter is also all about writing

clean code and clean widget trees

and I would argue that this is now easier to read than having that column here in our main.dart file,

especially of course if you add more and more logic in here and splitting your app into widgets is a

good practice.

As I mentioned, don't wrap every single text into your own custom widget but as soon as it gets a bit

more complex,

couple of lines, more logic, then you should strongly consider creating a new widget for that.