Introducing FlashList: Let's build a performant React Native list all together

Hey, everyone, my name is Marek. I'm a software engineer at Shopify, and I'm based in Berlin. And I'll be doing a presentation as an introduction to FlashList, and then I'll hand it over to Talha to lead the rest of the workshop. So if you want to introduce yourself as well.

Yeah, sure. Thanks, Marek. Hi, everyone. My name is Talha Nikwi. I'm a development manager here at Shopify. I lead a team called Retail Dev Accelerate, which is taking care of a lot of infra-related work for our POS application. I had the opportunity to collaborate with Marek and David on the FlashList project. And I'll be walking you through the workshop after Marek is done today. Thank you.

And then David will be here to support us, so if you want to give a quick introduction as well.

Yeah. Thank you, Marek. I'm David. I'm from Barcelona, Spain. I see some people from Spain as well in the audience. Nice to see. I'm a developer manager here at Shopify since a year ago and I was part of the FlashList team and I'm proud of showing this to you today because it's a project that it was like super nice to work on and to see the impact that they're doing in the community. So yeah. I'm glad to be here today.

Perfect. Then without further ado, I will share my screen to go through the presentation and yeah, let's start.

Awesome. I suppose everybody can share see my screen now to tell me. As I mentioned, my name is Marc Fort and today I will be giving a quick introduction to the topic of this workshop which is FlashList. So let me start with a tweet here. What if React Native ends up holding us back. Hold us back. Where are you rendering? A list of cards with checks in them. Now, of course, this is a bit of an over exaggeration, but it gives you a hint at how lists are perceived in React Native and that is inside React Native community but also outside. Additionally, we've had our share of issues with FlatList, the default component coming from React Native. This is our shop app running on a low-end Android device. As you can see, it's not responsive at all and it has a lot of blank cells that sometimes span the whole screen. In general, this is definitely not the user experience we want for our users. So we need a faster list. And we need a flat list. But first, let's consider alternatives such as RecyclistView. RecyclistView is a popular open source library that tries to fix the performance of lists in React Native. And the advantages are that it actually really is fast if you implement it properly. And the API is highly customizable, so you can achieve almost anything with it. And it is also quite well tested. It has been used for a bunch of years now in larger companies. And it has held up well. But it also has a couple of shortcomings. Primarily, the API the API is really complicated leading to less than desirable developer experience. It is also quite difficult to achieve performance cells with dynamic heights. And additionally, due to the fact that Recycler's View is a JS only implementation, there is there are also some first render layout spaces that should not be there.

So these shortcomings meant for us that we really needed to build our own version at Shopify and we called it FlashList. The goals of the projects have been to achieve a high frame rate for both UI and JSFPS. We wanted to minimize as much as possible the display of empty items and we wanted to make the library really easy to use and achieve as much performance as we could for a really smooth developer experience.

So this is the API for FlashList that we've come up with and as you can notice, we have mostly just changed the name of the component from FlatList to FlashList and try to keep the vast majority of the props the same. Now there are some props in FlashList that do not exist in FlatList for achieving better performance, and you will learn about some of those later in the workshop. Dynamic Heights, they pose no sweat and as I mentioned, that is even with the FlatList kind of API.

So let me answer a question now, how is FlashList so fast? And I'll start with actually explaining how FlatList works first. So in FlatList, we have a couple of items that are in the viewport here indexes from four to six, then we have a couple of preloaded items that are the bottom of the list. And then we have a couple of items that are still loaded in memory, two to three. Now, the amount of items in memory is in the FlatList case, quite high. But as you scroll down enough, FlatList will need to free up some space in the memory. And that's when VirtualizedList comes in component that FlatList uses under the hood. And what it will do is as you scroll down, it will empty the items, so that it replaces the content with just an empty view and keeps the dimensions of the cell, so the list layout does not change. This also means that as you scroll up and you get to these emptied items, you will need to render them always from scratch. And also as you scroll down and you need to load more items, you will also always need to render these items from scratch, which takes a lot of resources.

Platforms, on the other hand, take a different approach. We, again, have a couple of items in the viewport. We have some items that are preloaded, but the amount of those items is quite low. And most importantly, we have a concept called Recycling Pool. So as we scroll through the list, the items that are not visible on the screen anymore, they are put into the Recycling Pool. And then when we need to load more items, Flashlist will look into the Recycling Pool, and if there are any items that are currently not in use, it will move that item back into the list and just rerender it with the new data. This means that, for example, if only a text in the cell changes, it will have to re-render just that part, and it will not have to create anything from scratch. And that makes it quite As a visualization, you can see as we scroll, the items are being put into the recycling pool, and then when we need to create more items at the bottom of the list, FlashList will actually start pulling out the items from the recycling pool back into the list, and we will start to get instances and IDs that we've actually seen before. And again, this saves a lot of resources. We also needed to fix the first render layout issue. So this is how the first layout issue looked with Recycle List View, and you can see that the items kind of overlap each other. Now this is only for a couple of frames, so this recording is slowed down to make this more obvious. To get deeper into the problem, on the left hand side, you have how Recycle List View expects the layout to look like. It expects every item to be the same depending also on the estimated item size, which is a problem we'll also learn more about later at the workshop. But the actual layout, the thing that's actually rendered on the screen, is different. Here we have item number zero that has, for example, 100 pixels of height, but then the item number one, it has, for example, 200 pixels, but Recycle List View still counts with it having only 100. And so the item number two is then over the item number one, resulting in items overriding each other. So we implemented a native view called Auto Layout View that goes through the whole list. And whenever it sees items overlapping each other, or when there are spaces between items, it automatically fixes those UI issues and puts everything edge to edge as it's supposed to be. So with FlashList, if we look at the recording we can know like. To sum up the FlashList implementation, we have an API that's very similar to FlatList. We've implemented a native view to fix the first render issue. We've been able to achieve performant dynamic cell height with the simple API similar to FlatList and we have used Recycle as the inner engine that we've built on top of it to achieve the API. And also give you more performance out of the box. So we'll quickly look at some of the metrics but you will also get the metrics first hand during this workshop. I have been using a Motorola Moto G10 device which is quite low-end and so keep that in mind when seeing the numbers. First let's look at FlatList UI in JSFPS using Twitter sample. Very similar to what we will see in the workshop. And as you can see, the JSFPS drops multiple times to zero and UIFPS drops to sub-10 as well.

And also give you more performance out of the box. So we'll quickly look at some of the metrics but you will also get the metrics first hand during this workshop. I have been using a Motorola Moto G10 device which is quite low-end and so keep that in mind when seeing the numbers.

First let's look at FlatList UI in JSFPS using Twitter sample. Very similar to what we will see in the workshop. And as you can see, the JSFPS drops multiple times to zero and UIFPS drops to sub-10 as well. So what we get in the end is average JSFPS of 11.8, average UI 44 and JS threadlock is almost two seconds which means that for almost two seconds user has not been able to interact with screen at all because when the JS is in the threadlock that's not possible.

If we look at FlatList UI in JSFPS with the same sample by just changing the name, we can see that the JSFPS never drops that low, never drops even close to being zero, and UIFPS stays around 64 most of the time. So we get an average JSFPS of 49 and average UIFPS of 58, which is about four times improvement just by changing the name.

We have also been looking at blank spaces using a Flipper plugin that we've built just for this project. And as you can see with FlatList, we get huge blank cells spanning the whole screen which are the real large parts at the top, and the average is around 280 pixels. With FlatList, we get a different story. We do get some blank cells, but they are quite limited and only appear for a limited period of time, and so the average in the end is around 45, or so, which is seven times better than with FlatList.

So, is FlashList production ready? Let me get back to the initial example of Shop App. On the left, you have FlatList, which was for multiple seconds not responsive at all, and it had those huge blank screens that were spamming the whole screen. And on the right, we do have some small blank cells, but only for a limited period of time, and more importantly, the app is extremely snappy, even on such a low-end Android device such as Moto G10. We are also using it in all of our apps in Shopify Mobile Shop, POS, and Inbox. And we've also seen a lot of excitement in the community, and the list is also being used extremely now in production as well. So you can check out the project on GitHub, but you will also do that during this workshop. And that's it for me. And I'll pass it over to Telha, who will get more into the coding part of the workshop. Thank you.

Thank you, Merik, for the amazing introduction to Flashlist. I'll take over from here. Let me start presenting my screen. All right. Second. Okay. So, before we begin, I'll quickly introduce everyone to— All right, even before I start, right, can I get some thumbs up in the chat if everybody can hear me okay? And if you're here, just to let me know. Awesome. Awesome, I get to see some responses. All right. All right. Okay. So, I'm sharing one document in the chat right now. Make sure that you use this link and open this document. So, this is what you're going to see. It's right here on my screen. So, this is basically all the setup steps that we have for you. I'm going to walk through each of those. I just want to give you a quick overview of what you can do in case you run into problems. So, first of all, there's a link for questions. Make sure that you use this link to ask us questions and not the chat. We are going to try and go through most of them towards the end of this workshop. There's a link to a performance tracking sheet, which I'm going to talk about very soon. You have a link to the slides that I'm going to present. Most importantly, there is this section called skip ahead. So, at any point, let's say, if you have not been able to complete a particular task, you can skip to any task that you want. Let's say, if you jump to task four, task one, two, three will already be done in that snack for you already. So, no need to worry if you are not able to keep up, you can skip ahead, and you can do it at your own, in your own time later on.

All right. So, without further ado, let me get into the workshop, right? I'll start presenting.

All right. So, make sure that you have Expo Go installed in your phone. And just make sure that you open, this, the link that's mentioned in the document here, open the following scan, you can open this, and you'll see something like this. I'm also going to scan this QR code and make sure that my phone is connected. Make sure you scan your QR code and not mine. So, here we go. You can see my device on the right, it's the Moto G Stylus. Okay. So, I have my device connected at this point. You can see this device does show up in Snap. I can click on the reload app button to reload at any point. And on the left, you can click on the no errors and one warning and logs to view the logs that are going to show up. So, that was a quick introduction on how Snap is going to work.

Right. As the second step, go back to the document and open the performance tracking sheet. It's going to look something like this. So, what I want everyone to do after you have launched the sample and you can see it in your ExpoGo application, just go ahead and click this checkbox and add your name and device on the left. This is how we can keep track of how everyone is progressing. Joshua, you make sure that your ExpoGo app is up-to-date. Alright. Go ahead and add your names. Alright, first Android device on the list. Glad to see that. iPhone 14 Pro Max is also there. Is there anyone who is running into any issues? Go ahead, go ahead. Yeah, don't worry about the rest of the columns. I'm going to walk you through what we're exactly going to do, and we'll do it together. Just add your names, your device, and whether you have loaded up the sample in your Xpogo application. All right, we'll quickly explore what the sample is about, and then we'll start with the first task. This sample is a list of Twitter feeds, and some of these tweets have related tweets along with them. So if you notice, anything that has more than two retweets has a related tweet. So it's a combination of vertical lists and horizontal lists. If you click any of the horizontal items, it's going to change the primary tweet. And the element is going to become selected. And that's all that this sample does. Feel free to play with it.

So moving on, I'll just move on to the next task, and we'll start doing stuff now. All right, what's the first thing? So what we want to do is, if you notice, there's a Run Benchmark button on the top. I want everyone to click on it and wait for the benchmark to run and finish. It's going to give you an average FPS number at the end of the run. I'll do it along with you. Let's do it together. All right. OK, mine is running. OK, so I got a result. My average AFPS was 1.7. Remember, mine is a pretty low end device. It's a Moto G Stylus with a Snapdragon 665.

So after you are done, what I want everyone to do is go and put this average number in the baseline column. You just have to click that run benchmark button and wait. All right, very nice. A lot of people have been able to do it. Remember, you have to put the average number and not the max FPS. Yeah, Josh, your number is pretty high. If you think you have not got the right number, make sure that you reload the application and make sure that you chose the right link and just run the benchmark again, and you can update it later. Yes, this number is indeed dependent on device performance, and I'm using a very low-end device, Moto G Stylus, Snapdragon 665. Flat list, all the items are memorized. Everything is as it should be. It's just that when you have a vertical list and a horizontal list nested together, it's a pretty complex thing. Ah, that's what? You opened the final sample directly. All right, Joshua, make sure you fix it. So we'll go ahead in the interest of time because I really do want to take questions in the end.

Okay, so what's the next thing? What we want to do now is, let's look at the sample, all right? If you open the SRC folder inside Twitter, you would find three files, TweetSell, TweetContent, and Twitter. Twitter is where our flat list is defined. So what I want everyone to do is start their flash list migration. I'm going to do the first couple of things with you, so follow along, but the rest of the tasks, I might pause for a minute or two and let you do it. So what we just need to do is, we need to change the name to flash list, and I need to import it. All right. That's all. Change the name to flash list, and I'm going to go ahead and reload the application. Okay. And that's it. We have completed the first step to migration to flash list.

What's the next thing that we want to do? What we now want to do is we want to observe the load time for this list. What's load time? Load time is the time that it takes for your items to actually become visible on the screen and flash list has a neat API that enables you to do that. So, I'll go ahead and do that. Of course I'm copy-pasting some code, but feel free to type it in.

So, this is the way you do it. You add an on load listener. It gives you an object from which you can select elapsed time in milliseconds and you can log it. So, let me just reload the app again and you'll see that we'll have a load time appear. All right. So, my load time for this list is 1319. Really huge. It's taking over one second to render. If you notice, Flash list is giving us a warning here. It's saying that estimated item size is not defined. And based on the current configuration, I can set it to 279 to optimize performance.

What does this mean? So, before rendering, Flash list usually has to make a guess on how many items it should start with. And in a lot of cases, that estimate can be wrong. In this particular case, it might think that each item is 100 pixels. But after rendering, as a developer, now I know that my items are on 279 pixels, and Flash list is giving me that suggestion. And I can provide this information to Flash list up front, and it can use it to optimize some of the things. So, let's go ahead and do that. What we'll do is, we'll have to do estimated item size, 279. Once I've done that, let me reload the application again. Let's wait for the load time to show up. All right. My load time is now 485 milliseconds. What happened here? FlashList was able to make a much better guess on how many items it requires in the beginning. That led to a smaller number of items being mounted. And, if you see, we have already cut down the load times by more than 50% just by specifying that estimated item size. It's extremely important that it's specified. We have seen estimated item size and its impact. Now, give me a quick thumbs up if you have been able to do this. Thumbs up. Done. Anything in the chat? Awesome. I'm seeing some things come up. That's great. All right. So, let's repeat what we did the first time. We are going to click Run Benchmark Together on the updated code and we'll record the numbers under task 1. Let me do it. All right. It's running for me. All right. It's all white. Okay. The JSFES is now just 2.9. Still pretty bad. I'm going to go ahead and guard it under my row. 2.9.

Okay. I'm glad to see that a lot of you are able to get this done. Make sure that you are picking the average number and not the maximum or the minimum ones.

OK. All right, moving on to task two. Right, what we want to do is, as Merrick described, FlashList's goal is to reduce the number of items that are being created and destroyed. So how can we observe that? We can use the following code snippet inside our tweet cell and tweet content items.

And, all right, Mia, you can simply click on the link here and task one would already be done for you. And you can just start with task two if you were not able to finish it. But if you need a few extra minutes, go ahead and take that. All right. OK. So let's go ahead and do this. So first, I'm going to go to tweet cell and.

I'll use effect. And use effect. And I will return a function here. Which is going to take console log. They console at log. Tweet cell. I'm out. And we only want this to run only when the components and months I'll pass and empty dependency array. Very simple piece of code.

And same thing I will copy. And paste inside Tweet content. That's on line 72. And I'm going to change my console to Tweet content. And I'm going to import use effect. Go ahead and take your time. There's no rush. So I am done. I'm going to reload the application now. Give me a thumbs up if you have done this. Awesome. Great, great, great. Okay, okay, let's observe. I'll clear the existing logs. Let's see. I'm going to scroll manually, and okay. You see our tweet cell is unmounting all the time. Tweet content is also unmounted. A lot of unmount and mount events, and this is something that we want to really avoid. All right, so the idea of this particular task was to just observe how many mount and mounts we have, and then just run benchmark one more time. So let's do that. Make sure that you comment out the console.log, because it impacts performance. But we are going to go ahead and uncomment it in the next task. So I'm going to go comment console.log, reload the app, wait for it to load.

Make sure that you comment out the console.log, because it impacts performance. But we are going to go ahead and uncomment it in the next task. So I'm going to go comment console.log, reload the app, wait for it to load. So and let's run the benchmark again. Okay, for me the result is 8.9 FPS. Right? I believe it didn't do much for, you know, changing performance at all. Given that this is a low-end device, sometimes results can be a little bit flaky, and I believe that's what happened because I certainly didn't make any changes to improve anything. Okay. So let's capture those results. A lot of you are 41, 47, 44 already, 56. Yeah. I mean, iPhone 13 and iPhone 14 Pros, they have really solid single-core performance. That's why they can just brute-force their way through some of these performance issues. But there are a lot more visible on low-end Android devices, even mid-range Android devices. I think that's what the result is going to reflect. All right. I will move on to the next one once we are over 50 percent. Come on. Yeah, sometimes Snag doesn't reload. If you are suspicious, just trigger a reload either from the web console or by shaking the device and using the reload button. All right. Let's proceed. What's task 3? I wanted to quickly touch on the function of key prop and react. Whenever key prop basically maps your JS instance to an actual UI instance in the DOM, and whenever you change a key in React, it's going to recreate both the UI node and the JS node. This is specifically what we want to avoid in Flashlist. The next task is all about figuring out where these keys have been explicitly assigned, and we are going to remove them and see their impact on the mount and unmount operations happening. We have observed that in a lot of cases, when you're using Flatlist, you tend to add these keys, because it's not really impacted by it. It's destroying and recreating anyway, so having it or not having it does not make much difference. But as you will notice, in case of Flashlist, it can make a huge, huge difference. I'm going to remove one, and then I'll have you look for the other one. All right, so if you go to Twitter, you'll see that the primary render item has an explicit key defined. What we want to do is we want to go ahead and remove it. That's it. And we also want to go back to tweet cell and again uncomment our oncehold.log so that we can observe the unmount events again. So that was the first key. Go ahead and try and find the other key if it's defined anywhere. And let me know where it is in the chat. Could be in any of these components. I'll wait a minute and then we'll proceed. Okay, it looks like people have found where the, where the key is. Yes, it's inside tweet content. and it's on line number 78. If you see this, this, this key isn't even part of any map statement. This really isn't required unless somebody explicitly wanted to destroy and recreate this element. So we can go ahead, remove it. Let's reload the application. Okay, let it reload. Sometimes it takes a while even after it shows up yet. Now it actually reloaded. Okay, let me scroll.

Right. If you notice tweet content is still unmounting, but tweet cell is no longer unmounting at all. Like I don't see a single log in there. And the reason is because we removed the key prop that was defined on tweet cell. So the only problem we have right now is tweet content unmounting, and we'll figure out how to solve that very soon. So given tweet cell isn't unmounting anymore, I'm going to just go ahead and remove this use effect for tracking unmounts. And like we did last time I will comment out tweet content unmount, because it's going to interfere with our benchmarks. So comment that, reload, let's do it. And then we are going to run benchmark again and see if we have any improvement.

Okay, let it reload. Okay, my list loaded, 491 milliseconds, give me a thumbs up if you're ready to run benchmark. Okay, nice, very nice. Let's do it. Oh, it's still going blank. If you notice my Moto G stylus goes totally blank in most of the runs. All right, 11.6. So in my case, I have a little bit improvement, but nothing major to really celebrate. It's still pretty bad, right? Go ahead, finish your benchmarks and then we'll move on to task four. This is where I think things are going to start getting interesting. Yeah.

Okay, we are over 50%. Okay, do you notice any issue with the list right now? Ever since we removed that key? If you already see the issue, you can comment. Okay, let me show you. Look at the top items. First tweet is by Chris, second is by Lorenzo. Yeah, somebody got it. The items are repeating. If I go back to the top again, the tweets changed. Why is this happening? This is happening because items are getting recycled and when they're getting recycled, they're not getting updated. I know this could also be because of which my performance improved. Because nothing is happening, items are already just moving. So I'll quickly show you what is going on and why this is a problem and how we can fix it and then we'll fix it together. If you noticed, to each cell, I told you right, that when you click one of the horizontal items, it changes the top level tweet. And this current tweet is maintained using a state, whenever that click happens, the state is updated. But when the item is actually getting recycled, the state is not changing, so current tweet is actually preserved and that's the whole problem. This is not a problem in FlatList because when it recreates the item, your current tweet is always equal to the incoming tweet. But here, when this item updates, current tweets still remains the same. So any ideas, anybody wants to quickly comment in the chat how we can fix it? Right. Perfect. Okay, it's our favorite hook, USE Effect. Let me show you how it can work. So this is the code snippet that we are going to use. So, what we need to do is, let's do it together. USE Effect. What we want to check is if currentTweet is not equal to tweet, we want to call setCurrentTweet with a new tweet, and we want to run this only if our tweet changes and not on any of those horizontal item clicks. So, the tweet will only change when FlashList reuses an existing component, and that's where we want to make sure that we are syncing the state. Feel free to copy this code snippet, use effect if currentTweet is not equal to tweet, setCurrentTweet, and format so that it looks clear. I will go ahead and reload. All right, it has reloaded. So my first two tweets are Aaron and by Gargley. And let me scroll. I'm not showing sure if I'm saying their names right, but forgive me. If I go back up, you see everything is all right now. There are no items repeating. Has everyone been able to fix the issue? Give me a thumbs up if it's fixed for you now. All right. Awesome, I'm glad to see everybody is able to keep up nice and easy. We were pretty apprehensive honestly in the beginning that is it too difficult? We even did like a trial run yesterday just to make sure that it's not too difficult. Okay, if everyone's ready, let's go ahead and run the benchmark again. And let's look at the results. We are adding another render. So it might actually slow down. Let's find out. In the meantime, can anybody tell me if this is perhaps not the best way to update the element and what can be the potential problem? Okay, if you see my numbers have actually decreased 6.6. Not seeing a whole lot of improvement. Okay. Oh, everybody is already beyond 50% with what I put in my numbers. That's so cool. I'm so glad to see this. Okay.

Okay, let's move on. Task number five. If you notice the horizontal list is also a flat list. So what we want to do is we want to migrate that to FlashList and we want to look at bugs. So go ahead and do it. Again, when you migrate, it's going to give you a suggestion for an estimated item size. I'm going to wait a minute to let everyone do it before I also go ahead and do it, all right. And then we'll discuss the bug and how we can fix it.

Okay, let's do 40 seconds. It shouldn't take much time and then I'll do it. Also try to find out or notice any bugs if there are any. All right, I'll also start doing it. Have to go to tweets cell. I'll change flat list to flash list. I need to import it, import flash list from that Shopify flash list. I am going to now reload. And hopefully it will give me a suggestion for my estimated item size because I don't want to guess it right now. Okay, I have a suggestion it's 352. Let me go ahead and add that estimated item size 352 and reload one more time. Anybody see any issue? A few items can repeat in the horizontal list because we are randomly generating that recommendations to it, but the repeating is not the problem.

Okay, I'll show you what the problem is. When you click on any of these items, the top tweet is going to change but the item itself is not going to get highlighted. Previously, you would see a light blue border show up. That's no longer happening, although it's functioning. So why is that? The reason for that is FlashList is extremely aggressive in cutting down renders. So instead of opting out of re-renders using use memo and things like that, you rather opt into re-rendering. So if your data has changed and your end item has changed, only in that case, FlashList does a complete re-render of items, otherwise it won't. So, and if you see our border color is dependent on whether the current, like the tweet displayed is the current tweet or not, and if this condition is true, the border changes. But in this case, FlashList is not going to re-render at all because the data has not changed when we click the item. So how do we solve this? We use the extra data prop, which is part of FlatList and FlashList both, and we can ask FlashList to also re-render if current tweet changes. Okay, I'm going to reload the app again, and once it's updates, this issue should be fixed. Okay, reload. All right. If you look at my load time is again reduced by almost 50%. Like I started out with 1.3 seconds, and it's not 238 milliseconds. It's an insane amount of improvement. But let's see if our bug is solved. All right, yeah. I can see the light blue border again. That's cool. Okay. All right, now let's go ahead and run the benchmark again and look at our new performance numbers at the end of task five, right? Now, it's looking better. It's looking a lot better. At least for me it is. Aha, 21.2. It's a pretty big improvement actually. It's very likely that folks with iPhones are already hitting the 60 top line at this point. Okay. That was it. Before I move on, I'll also quickly go ahead and you don't have to do this, you can just observe it with me.

I will uncomment this console.log and reload the application again. And you'll see that the tweet content will no longer unmount because we have moved to FlashList. All right. For unmounts, these are the previous items. Let me get rid of the logs. I'm going to now scroll, right. Oh God, it's still unmounting. That's weird. Okay. Right, what might be happening? Okay, let's reload one more time. Maybe there's still something wrong. No. All right, reload it again. Let's see. Okay, there are a few unmounts happening, which is okay. We'll figure out why that's the case. All right. Right. So to itself, we have okay. Let's move on to task number six.

Get item, type. What is get item type? This is the final piece of the puzzle, if I put it that way. If you notice, the unmounts are still happening because we might choose the wrong base to recycle items. For example, this particular tweet has no related tweets. And it might get recycled and reused to render a tweet which has related tweets. And what that means is we are going to see a lot of mount events as part of that. And vice versa, if I use this tweet, which has related tweets to render something that does not have those related tweets, all of those related tweets which we rendered before go to waste. Let's look at the code to understand why this happens. Inside tweet cell on line number 34, you'll see a check where I'm checking if recommendations.length is greater than zero, only then we are entering the flash list. So if this condition is mismatched with the request, mismatching between items, we can run into that issue. But we already have a fixed logic to decide whether or not we are going to show related tweets which is basically this. This is where we are checking if tweet.retweetcount is greater than two. We generate some related tweets and we show it to the user. What if we tell flash list that we are doing something like this? And flash list has a way in which you can do that. All right, so how does this work? So this is the code snipper that we are going to use. Get item type, you can go to your top level Twitter element and add this code. What's the code? Get item type, you are going to get an item. And if the item.retweet count is greater than two, we tell Flashlist that this is like a RT type element, which is like short for recommended tweets or related tweets. If the retweet count is less than or equal to two, we return T. So this way Flashlist can now figure out internally what items it should use to recycle what kind of items. And this is going to reduce the number of unmounts that we are seeing even more. Here, let me reload. My console.log is already uncommented, as you can see here, we will observe if we are still seeing any unmounts. Yeah. All right. Everything is loaded, let me scroll. Yeah, some unmount, two unmount. Flash to scan unmount a few things based on number of factors that it doesn't need. But on even scrolling quite a lot, right? You can see we are not getting repeated unmount events at all. Right, I'll give you a minute to do this.

And give me a thumbs up once you also don't see any unmount. Did someone scan my QR code? I saw an iPhone. I saw iPhone log. Awesome, I think some of you have already been able to do it. But yeah, unmounts are totally gone. That's awesome, and that's what we set out to do in the beginning. I'll actually go ahead and get rid of this UseEffect because nothing is unmounted so I don't need it. I'm going to reload one more time. Whoever has connected to my snack, your app will also reload. Okay, let's see. Okay. Okay. Awesome. Let's do it again. Let's run the benchmark and see the new numbers. It's looking a lot better. Most excited to see what the new number is going to look like. And remember, my iPhone is also recording. 32.4. 32.4 for me. 32.4. 34. And see, even if you don't have a low-end device right now, the material is all there, the snack is there, so you can, in the future, load the starting snack on a low-end device and then try the final one to figure out how much of an improvement you can expect. But yeah, like on an iPhone, you would have already hit the ceiling right now. So because the JS render is not going to capture anything more than 60 FPS for now. A lot of people might be at 60 FPS, honestly, at this point, but there's one more task left. It's not over. Okay. What's, if you remember, in one of the tasks, we added a use effect. And this is something that I wanted to touch on exclusively, because usually people add use effects to update their states and sync it with external data. But there's an alternate way where you can avoid the extra render. Our current setup, if I go back to the code, this use effect is going to be called after we have done one update, and then it's going to check this condition called set state, which means that the item is going to render two times. And some of these items have these nested horizontal lists which are super expensive to render. So, we definitely don't want to do it twice. So, let's see if we can do it just once and how to do that. Okay. So, the code snippet is in front of you. Let me do it and you can follow along. What I can do is, I can create this ref source to it to track what my source to it is, right? Which is coming from, let's say, Flashlist. I made a copy of it. Instead of use effect, I am now going to in the same same render loop, or render path. I'm going to check if my source tweet was equal to the tweet that is now passed by Flashlist. If it isn't, we capture the copy of it in the ref and we call set current to it in the same render call. What this does is, so in this particular case, let's say I talk about tweet content, so the render method of tweet cell, our current component is going to get called twice, but the render of tweet content is going to be called once. So it's like two renders, but below that tree it's just one render. So Flashlist is also going to get rendered just once. So if you do it this way, there are of course multiple ways of doing it, and React has this documented on how this works and why this is better than using UseEffect. But for Flashlist, we strongly recommend that if you have states, you sync them using this method because this is much faster than using UseEffect. Again, the improvements depend upon your particular component, but as you'll see in this case, it's going to make a difference. Yeah, let me reload.

And we're also just going to observe if we still see those repeat element bug or not. Okay, it has reloaded, let me scroll a little bit. Let me come back. Right, everything is looking good. Yeah. Give me a thumbs up if you were able to do this. Awesome, awesome. Okay, we are not going to run benchmark just yet. There's one more thing. Okay, draw distance. Many of you would be familiar with the window size prop in FlatList. FlashList also has a prop, it's called draw distance in this case. You can change this prop to a smaller, like by default, FlashList only draws 150 pixels ahead while FlatList draws 10 times of your viewport ahead of time. So FlashList draws a miniscule number of items compared to FlatList. But in case of horizontal list, you do not even need 250 pixels ahead of time draw. At least, you know, in this particular example, the item is pretty big, so I can probably just go ahead and change draw distance also. I'm going to make it zero. You can also choose not to do it, like even without it, we'll see a lot of improvement, but let's do it because we know that we don't really need to. And in case of FlashList, setting it to zero is not going to lead to any huge functional problems. Like in case of FlatList, I know in some cases when you change initial number to render or Windows size, you run into issues. Items do not load, but it's really a no compromise thing in this particular case. Right? If you are done with setting draw distance of the internal list, reload the application, and we are going to do the final run. Right, just 200 milliseconds load time. Okay, let's do it. Okay, it's looking pretty good. Don't even see blank spaces anymore. Okay, come on, come on, come on. 50.6, 50.6 for me. Okay, 50.6. Zach's results are pretty interesting. He started with 60 FPS. Still at 60 FPS. All right. So that's draw distance. I think we have, we have, and you know that brings us to the end of the actual coding part of the workshop. Let's quickly look at the results. So in my case, if you see I started at 1.7 FPS on a low-end device. Zach, it's okay. And my final number was 50.6. So I actually increased my JSFPS to 40, like by 48.9 FPS, and that constitutes to like 29 times improvement in JSFPS, right? And if I look at some of the iPhones we saw, see, interesting thing to note here is even on iPhone, if you're just seeing 1.2X improvement, flashless will actually be consuming very small amount of CPU compared to the flat list. So like brute forcing is possible, but you are burning through a lot, lot of energy and battery, your device is going to warm up, things like that. So you will still see battery improvements and devices are going to remain cool, even on iOS, but on Android, it's like night and day. I can already see, you know, KB getting close to 16 times improvements before the numbers was 7.2. Now the increase to 116 FPS, that's like almost 120 FPS. What are the other big numbers? Okay, iPhone 11 Pro going from 8.8 to 60, that's like almost six times increase. So on latest iPhones, we do expect you to see around 1.8 to 1.2 times improvement. But if you observe the CPU usage, it's going to show a similar trend as what you're seeing on Android. All right, all right. Since I have two more minutes before I finish, I would want to show you one more thing that's pretty interesting. So we have been looking at JSThread till now.

What about UiThread? Because flash is actually reduces burden on your UiThread even more. So I can do that. So on my Android device, I'm going to go to Settings, Developer Options, sorry wrong option. I do this all the time. If I scroll down, there's something called as Profile Hardware UiRendering on Screen as Bars. Okay, going back to Expo. So first I launch what we started with our original sample. So this is with FlatList, both vertical and horizontal. Let me reload. So every time you see these bars going above the red line, that's a frame drop, and the longer it is, the worse it is. Let me run the benchmark and see how it goes, okay. Lot of tall bars. Lot of tall bars, and it's pausing because jsthread is not able to keep up and is not able to even issue instructions for drawing. But maybe while coming back, it's going to be better. All right. 1.7 again, and you see these huge frame spikes. And this is where your UI is also gonna freeze, not just blank, actually freeze. Okay. Let's go to our FlashList sample with everything done and fixed. Yeah, let me reload. I just reload all the time just to be safe. Okay. Let me run it, and, okay. All right. Even with the recording, you'll see that we remain below 60 FPS for quite some time. Of course, we are dropping frames because it's a low-end device, and we are also recording or mirroring. But yeah, if that's not the case, then it's honestly possible, even on this device, if I disconnect from mirroring, it'll do 60 FPS. And you do not have a single huge spike freezing your UI thread at all. So that was quickly some notes on UI thread performance. I'm going to quickly go and disable that. Right. So that brings us to the end of the coding part. David, do you want to run through any questions if you have any? Yeah, I was just remembering the chat so I have this slider. But in case that you want to, go ahead and raise your hand here if you want to do the questions here. I see no questions there. I see one question in the Q&A here. But I think everyone- I think you were coding so- Yeah, it's difficult to go to a separate, because it was extremely fast-paced. But yeah, go ahead, raise your hand, we will unmute you and you can ask your question. Or you can type it in the chat. Okay, what was it? It's the question from Juan that says, can the items have different sizes? I think we answered that in the presentation. Yeah, if you look at this already, right? The items are of different size. Right? Flashlist does not ask you anywhere, and this is one item, like this tweet and the horizontal tweet is actually one item. Because we are rendering it inside to itself. And Flashlist did not ask you for different estimates or fixed sizes anywhere, but it still works very well. So dynamic heights are no problem at all. Yay. Cool, if you want to share your thoughts or comments, go ahead, you can also do that if you do not have any questions. Yay. Thumbs up if you actually do not have questions. Okay.

Either we did something really good or really bad. Maybe I can ask a question like for the audience, like how many of you know about Flashlist before this workshop or how many have you tried before joining the workshop? Maybe just give a thumbs up as well if you tried in the past, or now it's first time that you see it. Nice. All right. I see Zain mentioned that are going to get back to React Native from Flutter after this workshop. That's a win. Yeah, and folks, see, the more complex your list, the more gains you're going to see. On our website, we actually claim up to 10 X, but you can easily go over that if your items are complex enough.