Original subtitles

Instead of having our column with that single child scroll view, there is another widget baked into

Flutter that we can use to ensure that we automatically have a scrollable column or row because it's

such a common pattern that you need multiple widgets next to each other or on top of each other or above each

other

and that that list should be scrollable and a column and a row by default is not scrollable.

So of course, you could always wrap your columns and rows with single child scroll view but as I said,

Flutter has a shortcut here. Instead of manually adding that single child scroll view,

let's get rid of it here in the transaction list widget and instead of that, let's use instead of the

column, a ListView widget. ListView is a widget provided by Flutter which is the end by default

a column with a single child scroll view

you could say. On the ListView, you can set a bunch of things,

most of them are relatively advanced and rarely needed but you can also set a scroll direction in case

you need a row instead of a column, a scrollable row. With that if you save it,

now we'll have the same behavior as before, as I can quickly prove if I enter items here,

this is a scrollable list in that container which we defined here.

Now also important,

if I remove that container here in my transaction list widget,

now you see no transactions are shown and we actually get an error here.

It's a pretty long error message and it can be complicated to read,

in the end the problem is that the vertical viewport was given an unbounded height and this might

sound cryptic but what it means is that ListView is in the end a widget which yes, is a column with

a scroll view but what it means in the end is that ListView is basically a widget that has an infinite

height. Unlike a column which takes all the height it can get on the given screen, a ListView does

not have a fixed height, it can't have a fixed height because it's scrollable, there are items that are

currently not on the screen and therefore, the height where all the items have to fit in in the end has

to be infinite because it has to be larger than just the screen size,

otherwise the items that are there and just aren't on the screen at the moment wouldn't be there, right.

So there are items below the screen or above the screen depending on where you scrolled and these items

are also part of the ListView.

Therefore, its height is higher than the screen height, it's actually infinite.

The problem with an infinite height just is, if you throw it into your page like this, Flutter doesn't

know how to size that ListView. Of course to you as a human, it's obvious, it should take the remaining

space here right

but that's not how Flutter works,

it needs clearer instructions than that. So you need to give it some constraints,

some settings on how much height it should take and previously, with that container, we had that. If you

have a container around your ListView, you have exactly that kind of constraint

you need. You're telling Flutter add that ListView please and Flutter has a look at its parent and it finds

out oh my parent has a height of 300,

okay I will take 300 as a height for the ListView. Without that container,

the parent here of the ListView is, since we use transaction list here in user transactions, is in the

end that column and a column by default takes all the height it can get.

So the problem with that of course is if we have something that takes all the height it can get and

then we have something that has an infinite height,

if we combine these two, we have a problem because as much as I can get and I know no limits, it's a bad

combination.

So here, we need some wrapper that defines a height, so that Flutter knows how big that ListView actually

should be, how high it should be in this case.

But with that, using a ListView is the better alternative to using a column with a single child scroll

view because it's the end shorter

and in addition, you get a couple of other optimizations and improvements which the ListView has baked

in. We learned about the ListView,

there are actually two kinds of ListViews or two ways of using it I should say. The ListView widget can

be used as we used it, by passing a children argument to its constructor and then you have a list of

child widgets. The alternative way of using the ListView is to use the builder constructor it offers you,

so that's an extra constructor on the ListView class which also gives you a ListView but a ListView

that works differently.

Now let's first of all have a look at the left case,

there we have our child widgets and as you learned, a ListView in the end is like a column with a single

child scroll view around it and therefore, it's able to have more items than we have space on the screen

because it has an infinite height or width. The ListView builder generally works similarly but there

we have no wrapping single child scroll view in that sense

but instead here, we have some optimizations put in place by Flutter. To be precise, the ListView builder

in the end only renders the widgets that are visible and

that's a difference to this scenario on the left here. With ListView where you pass your children as

an argument, all the widgets that are part of the ListView are rendered even if they're offscreen. Now

for short lists,

that's no problem but for very large lists, that means that you consume a lot of memory, a lot of performance

for items that aren't even visible

and if you then scroll such a long list, you can have lags and bad performance because Flutter needs

to manage all these items in memory even though you might not be seeing them right now,

you can't interact with them right now,

still Flutter needs to maintain them all in memory.

The idea with the ListView builder is that Flutter actually gets rid of all the items which are currently

not visible and only shows you what's visible.

So the parts that are not on the screen are not loaded or not rendered to be precise

and this therefore is the solution and the approach you should use for very long lists or for lists

where you don't know how many items will be on it, so that for longer lists, you don't run into performance

issues and lags.

Now it is worth noting that the ListView builder of course has a certain threshold, so it doesn't instantly

remove every item that's not on the screen anymore,

it waits until this is a little distance away, so until you scroll a bit before it actually removes

that and the ListView on the left here where you pass children will actually also get rid of elements

that are outside of the current viewport or beyond a certain threshold

but unlike ListView builder on the right, it has less optimizations in place and unlike ListView builder,

it actually does create all items that are in it, initially it does not create them lazily when they're

needed but instead it just has a limited amount of optimization. So you don't want to use that for very

long lists or lists where you don't know in advance how many items you'll have and potentially you might

have a lot,

in such cases you might want to use ListView builder instead to improve performance.

So let's have a look at that ListView builder then. We can easily transform our existing list to such

a dynamically loaded and rendered list by using ListView builder instead of ListView

but now we need to pass different arguments here.

The builder method requires an item builder argument, that's a must have, you must provide the item builder.

Now item builder in turn takes a function that will give us a context,

we get that automatically, Flutter manages that for us,

context is this meta object with which we haven't really worked thus far

which holds information about the position of the widget in the widget tree and int,

it gives us a number of type int and that actually will be the index of the item we're currently building

but step-by-step. Item builder takes a function,

so you need to provide a function here, either a named function or as I'm doing it here,

an anonymous function. Then this function as I just mentioned receives a context and I will name this

ctx, you can give this any name you want but the value of this argument will be build context because

this function here is not called by you,

so it's not your job to provide these arguments,

it's called by Flutter because it calls this builder function here for every new item it wants to render

on the screen, for every new list item in the end and it gives us a context which we don't need here

but still we get it and it gives us an index of that item.

So is it the first item, the second item, the third item of the items it should render,

that's what we get here.

Now what you can't provide to the builder constructor is your children thing here,

instead what you need to provide is the item count argument and that defines how many items should be

built.

In our case here, that would be the length of our transactions list,

if we have two transactions, we want to build two items, right?

So we pass transactions.length which gives us the number of items in our transactions list.

Now Flutter knows that it should execute this function here twice

if we have two items or as often as we have items in transactions and now in here, we have to return

a widget, a widget that is built for this item

we're currently looking at,

so a widget that is built for the first item, for the second item and the third item and so on. The item

I want to build here of course is my card here, so I can actually grab this entire return statement

here all the way up here and replace this return statement with it, so that I return my card inside of

that builder method

here. The problem now just is in there,

I previously got my transaction because previously, we mapped our list of transactions to a list of widgets.

This approach does now not work anymore because now the builder instead simply takes a number of items,

not the list itself,

just a number of items and then repeats this function here,

this builder function for every item. In order to now get access to the different transactions,

we can simply replace tx here with transactions which is our overall transactions list and there with

the square bracket syntax, we can access a specific index

and here it's convenient and of course not a surprise and not happening by accident,

that Flutter gives us the index as a second argument in this function

it calls for the item it tries to create.

So it gives us zero for the first element it tries to create, one for the second element and so on and

therefore we can use this index here to access the first transaction, the second transaction and so on

depending on which item is getting built

and this is all managed by Flutter.

So now we use transactions index instead of tx here

and with that, if we save this, we get our transactions here

but now built with the help of the builder and that of course is pretty nice because now, here of course

we don't really see that or feel that but now we have a list that also has a great performance for

a lot of items,

so now this is the solution you should use for very long lists. For lists where you know how many items

you have and it'll only be six or seven, then using ListView children is perfectly fine but for long lists

or lists where you don't know in advance how many items you'll have,

consider using ListView builder to get the best possible performance.