Now I just showed you the scroll view and it's already time to let go and to get rid of the scroll view,
why? The scroll view is great
if you have a scrollable area on your screen
but it's not so great if you have a list where you don't know how long it will be or which might be
very long.
Now if you know you have some content, maybe a list of data but you know it's only 20 items, so it will
probably exceed my screen boundaries but it will never be more than 20 or 15 items,
then you can use a scroll view
but if you have very long lists, then a scroll view can be very inefficient because what it does is it
renders all the elements in advance, even the ones that are not on the screen.
That means that even the goals down there which are currently not visible are fully rendered
and when you scroll such a very long list with a lot of elements or if you do anything else on the screen,
that can really slow down your app.
If you have a list with hundreds or thousands of elements and there are all always rendered even if
you don't see them, that can really slow down your app.
So in order to speed that up, there is a component built into React Native that handles such infinite
lists or lists that are potentially very long in a more efficient way
and that's the FlatList component which you also import from React Native. FlatList replaces scroll
view
so to say, so here we can simply use FlatList which is a self closing element and FlatList has two
important properties - the first property is the data property where you point at your input data and this
should point at an array.
So here, I point at course goals because that's the data I want to output.
The second important property is render item, that takes a function which is called for every item
in your data to render a list item.
This is a function which will get some data about that item,
hence I'll name the argument item data and then it has to return a component,
so here I'll return the same view I had before,
just get rid of the manual mapping logic, so I'll still return this view.
Now you don't need to set a key here anymore but I'll come back to how this is keyed in a second.
So now here we get the item data and therefore we don't have the goal here anymore.
An item data is a more complex object but in there what you'll have is an item property, besides item
you also have the index,
so the number, the position of that item in the array starting at 0 and separators which would allow you
to basically render separators dynamically between list items, not something we'll do here but item
will be your data,
so one element from your input data and that here is therefore one of our goals.
and if we do that and we save this, let's now learn React Native,
maybe here on the iPhone to mix things up and we can add things here
and if I add a lot and I then close the keyboard, I can scroll but you'll see that there is a warning.
We expand this, we see virtualize list missing keys for items,
so that is another warning related to keys.
The reason for that is that FlatList automatically adds keys to your items but only if your data, your
input data has a certain shape and our current shape where we simply have an array of strings is not
supported. The shape it would expect
is that you don't have goals which are just strings but instead that your list is a list of objects
where you must have a key property in that object and here we'll actually create a random key now with
Math.random and then I convert this to a string because it should be a string and of course, that's not
perfectly unique,
you might have the same random number twice but it's good enough for this demo here
and now you can't have any other data in here, in that object,
the key is the only must-have property,
so here I'll have a value property
but you could have named this val or text or whatever you want,
I'll go with value
and this is now my entered
goal.
So now our course goals array here is an array of objects where each object has a key property and a
value property
and now if we feed that course goals array into FlatList, FlatList is happy because it expects a data
source where you have an array of objects, where every object has a key property and then anything you
want. Now to output our data,
it's no longer enough to access itemData.item because item is now an object and not just a string anymore but
item will have a key and a value property now because that's what we're setting up up there and I can
simply access the value property to output the text. And now if we save this and this rebuilds and therefore
now if we try this again with Learn React Native, close the keyboard, you see we no longer
get the warning and we can still scroll this of course, we get no error here either because now, we have that
key property here. Now in case you have data where you don't have a key property and you don't want to
transform it, let's say you had ID instead which would cause a warning as you can see if I test this,
we get the warning here,
in that case you can also add another property to FlatList besides data and render item, you can add
the key extractor property which takes a function that tells FlatList how to extract your key and by
default, the logic is I'll have a look at the item and look for a key property but now with key extractor,
you can change this. Key extractor takes a function which takes two arguments - the item it's looking at
and the index of that item and now you need to return a key and by default, it would look for item.key,
so that's the default logic which you don't need to add.
Now here, I change the key or the unique identifier to be on an ID prop and therefore, I will change
this down there in the key extractor to get the ID as a key and now with that, you also get rid of the
warning because you inform React Native's FlatList how to get a unique key for every item in your
list.
So now here, if you again learn React Native here and we add this, you'll see this works, we can scroll this and
we also get no warning. So that's FlatList and you should use FlatList for very long lists, for lists
where you don't know how long they will be but where they potentially are very long because that gives
you a better performance than a scroll view which on the other hand is great if you know you only
have a limited amount of items which will probably go beyond your screen boundaries but where you won't
have too many redundant items rendered outside of the screen.