Talha Naqvi from Shopify comes on React Native Radio to talk about the hot new FlashList and why it’s a drop-in replacement for FlatList in most cases.
Talha Naqvi from Shopify comes on React Native Radio to talk about the hot new FlashList and why it’s a drop-in replacement for FlatList in most cases.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast. Brought to you by the Green M&M Council, who reminds you Green M&M's lascivious nature is purely a rumor.
Episode 245, Shopify's FlashList Library.
Robin Heinze:
So have you guys ever had to use patch-package?
Jamon Holmgren:
Yeah, it's great. I love patch-package.
Robin Heinze:
Yeah, super useful.
Mazen Chami:
It's saved my butt several times.
Robin Heinze:
So, for the listeners, if you don't know what patch-package is, it's a really cool library that lets you make a change in an NPM package and apply it to your project every time you run yarn. It's really useful if there's a change you want to make, but the poll request hasn't merged yet or you're just waiting on a publish or you want to try it out and anyway, it's really useful. However, last week I had to patch patch-package.
Jamon Holmgren:
You had to patch ...
Robin Heinze:
Which is a thing.
Jamon Holmgren:
The NPN package, patch-package.
Robin Heinze:
I had to patch, patch-package.
Mazen Chami:
What went wrong?
Jamon Holmgren:
Yeah, really?
Robin Heinze:
So I had to increase the buffer size because it was timing out and it would just air out when I was trying to patch another library.
Jamon Holmgren:
Yo dog.
Robin Heinze:
The patch-package wasn't working. And so I googled the air and there was a poll request which had gotten merged, which increased the buffer size. But then there were more comments that said, "Oh, this is still broken for me." I had to increase the buffer size again to a higher amount. And so I did that.
Jamon Holmgren:
So I don't understand how that works. Obviously, so when you yarn, it brings down patch-package and then it applies patches to all of the downloaded packages.
Robin Heinze:
Yes.
Jamon Holmgren:
So it apply it to itself.
Mazen Chami:
Version specific.
Jamon Holmgren:
But then how does it know to use that new one to patch the rest of them?
Robin Heinze:
Because then it's already patched. So when you run yarn patch patch-package, oh my God.
Jamon Holmgren:
Wait, you can run that separately?
Robin Heinze:
Patch-package. Patch-package. So you run patch-package, patch-package and it patches patch-package.
Jamon Holmgren:
And then you manually run it again.
Robin Heinze:
And then you run it to patch the actual package that you're trying to patch.
Mazen Chami:
We should have started a drinking game every time you said patch-package, we would be done. We wouldn't get to our guest.
Jamon Holmgren:
This sounds a little bit like my pool. I've had to patch a few holes in my pool, but right now one of my patches is leaking.
Robin Heinze:
Has a hole in it. So you had to patch your patch.
Jamon Holmgren:
I haven't patched that one yet, but this is the downside, leave it to me to swerve this into a discussion about my pool.
Robin Heinze:
About your pool, or your tractor. I'm surprised the tractor ...
Jamon Holmgren:
I do have a story about my tractor, but I'm not going to tell it this time. Maybe next time.
Robin Heinze:
Next time.
Jamon Holmgren:
I have a weird bug with my tractor. Okay.
Anyway, so I'm Jamon Holmgren, your host and friendly CTO of Infinite Red. I am located in the Pacific Northwest with my wife and four kids on three acres with a cat and a tractor. And I am joined today by my good co-hosts, Robin and Mazen.
Mazen Chami:
Woo.
Jamon Holmgren:
Okay. That's just ridiculous.
Mazen Chami:
Are we just good?
Jamon Holmgren:
We haven't used it. It just sounds super underwhelming. Yeah, they're good.
Robin Heinze:
We're good. They're not great.
Jamon Holmgren:
They're fine. They're all right.
Robin Heinze:
Just okay.
Jamon Holmgren:
It works. And we have a special guest, Talha Naqvi, who I will introduce in just a second. Robin Heinze is a senior software engineer here at Infinite Red, located southwest of me in Portland, Oregon with her husband and two kids and has specialized in React Native for the past five years. Mazen Chami lives in Durham, North Carolina with his wife and baby boy, I think that used to say newborn, but someone edited the template now because he's growing, he's getting bigger super fast. So, he's a former pro soccer player and coach and is a senior React Native engineer, also here at Infinite Red.
And then our guest today, very excited about this, Talha Naqvi, is a software development manager at Shopify. He's the creator of Recycler ListView, which we are going to talk about. That's not what the episode is directly about, but it's a very integral part of it. And he lives in Vancouver, BC and has worked at Shopify for, isn't it almost a year now?
Talha Naqvi:
Yeah.
Jamon Holmgren:
Wow. Yeah, that's awesome. So I'm going to bring you in in a bit here, Talha, but I want to really quickly mention that this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the US and Canada. We do have someone over in Vancouver, by the way, over in your neck of the woods. If you're looking for React Native expertise for your next project, hit us up. You can learn more on our website, infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio podcast.
All right, let's get into our topic because I really want to reserve as much time as possible for the topic. I know a lot of people are really interested in this. We are going to be talking about Shopify's FlashList. But first Talha, can you tell us about yourself and how you ended up at Shopify and what your role also has been with FlashList itself?
Talha Naqvi:
Yeah, sure. So I started out my career as a developer working on Windows, and then I started to develop some Windows phone apps. Eventually I started working on Android, tried a little bit of web and my React Native journey really started with, so I was in India before I moved to Canada. In India one of the major problems that all mobile developers and companies in general face is people don't really have data apps. So what got us interested in React Native was actually not cross-platform stuff, but being able to ship over the air. And that's how we got into it. And I remember I started playing with it back in 2016, so it's been quite a while and formed a small team. Eventually took the leadership of their team, became a manager and spent quite a bit of time there. And then I was looking at what else I can do, what other organizations I can explore.
And then Shopify came up with this very interesting announcement, right, that they're going all in and was a no-brainer because I knew that I could just go and apply my skill set and contribute and get a different experience. So that's how I joined Shopify.
So I joined as a development manager on the retail team and there was this opportunity that presented itself where the foundations, with what the foundations team was going to build, they wanted to solve the ListView problem and they patched it to me and asked that, "Do you want to help?" Because of my prior experience working on Recycler ListView. So, I took up the role. So Shopify has this concept of champions, which in a simple way they're the ones who are leader project and they're the ones who are responsible for making it happen. So I was championed for this project called Flash It, but really there was a phenomenal team working with me to make it happen.
Jamon Holmgren:
I do remember that announcement about Shopify going all in on React Native and I think that's, it's a shout out to the rest of your companies to be public about being all in on React Native because you can attract amazing talent to your team.
Robin Heinze:
It's only going to help you ultimately. I mean the more companies do that, A, you're going to attract talented people and B, the more companies do that, the more credibility React Native has and the stronger its reputation will be and the more support it'll get.
Mazen Chami:
It's funny how you said you went into React Native not because of cross platform. I feel like that's the first time I've heard that. Most people are, cross platform is one of the big reasons we're going to try it out and we're going to go from there. But most people do forget that with Native, as far as I know, can you do over the air on Native?
Robin Heinze:
No.
Mazen Chami:
Not that I know of. Exactly. So your ability to do that on ...
Robin Heinze:
The JavaScript bundle is what lets you do that.
Mazen Chami:
Exactly. So that's a big plus in, like you mentioned, people not updating the app? My wife might not like me to say this on the podcast, but she doesn't update unless I get my hand on her phone and update her apps and her OS. So, yeah, I feel your pain and that's a really cool intro into why you got into React Native.
Jamon Holmgren:
That's amazing.
Robin Heinze:
How big is the team specifically working on FlashList? I know Shopify's React Native team is pretty big, but ...
Talha Naqvi:
So, of course, there are so many teams working with React Native, right? But the foundations team are specifically people working on this project. So we were four in total, huge shout out to them. David Cortez, Merick Ford, Elvira Barcik. So four of us were working on FlashList to make it happen.
It was pretty interesting because they were located in Europe and I was in Vancouver. So we had an interesting working relationship where I would just have a two or three overlap with them and most of the stuff we did asynchronously. So I also experienced how to be effective in remote work in this whole journey.
Mazen Chami:
What was the inspiration for FlatList?
Robin Heinze:
FlashList. We are going to do that a lot.
Jamon Holmgren:
How many times are we going to do that in this?
Mazen Chami:
Yeah, right? Trust me, I'm happy there's something other than FlatList. The name's too close. What's the inspiration for FlashList?
Talha Naqvi:
See the idea again was to bridge the cab between how native lists perform and how you experience lists in React Native. Two problems, right? One is when you scroll quickly, of course, you get this bunch of blank space and you can get it pretty easily, right, if your list is complex enough for a simple list, maybe not that easy, but for a complex one, it's something that happens. And the other motivation was being very responsive, having the UI be extremely reactive to user imports. That's not the case with FlatList today. What I mean by is, imagine you have a checkbox, right? And you have a FlatList, you tap on that checkbox, you are going to update your data, all the components will get updated and your checkbox, there is a bit of lag in actually updating it. Solving problems like these. So overall it was about having a very fast and responsive list, which solves all of your use cases. You shouldn't have to really worry about implementing complex lists in your app anymore.
Mazen Chami:
I remember working on a project I think, I don't know Robin if you were still on that project, too, at the time, but we were literally fighting with the FlatList on end reach threshold for several days, I think it was. And it was just one of those things where we spent a lot of time just trying to understand that value and then fight with it to give us the data before the user even gets there. And then when the user was scrolling fast, like you mentioned, there was just a lot of blank space and that was just really, really hard to work with. So how does it work? What happens underneath the hoods?
Robin Heinze:
What's the magic?
Mazen Chami:
What's this magic we're all hearing about?
Talha Naqvi:
Before I get into that, right, like you said, a lot of teams at Shopify are also going through the same and the process of building this whole thing was, again, we talked to all the teams, figure out what the problems are and then find a solution for it. But ultimately what makes FlashList faster is recycling. So the way FlatList works, right, is whenever your view goes out of your viewpoint, it's marked as something that's not really getting used. So what it can do is it can simply destroy it, right? And that saves memory. And so you get this virtualization where you are not going to run out of memory. So that problem is pretty well solved.
But when you try to go back to that view, right, it will recreate it. And what happens during recreation is, first of all, your entire view on the native layer needs to be recreated. The entire layout needs to happen. And React Native also has to issue an instruction to create a view, which is typically a much bigger instruction compared to an update instruction, which would just say, okay, maybe just change this text. But for creating an entire thing, it has to issue a huge command over the bridge. So that makes creation of view a lot more expensive compared to just updating it. So what FlashList does instead is, when your view goes out of the view port, it's not going to destroy it, it's going to keep it as it is.
But let's say you scroll down and you have to render a new view, then it takes that old view, it applies that transform to it, moves it down and just updates it with new data. So, no new views are created on the UI side, right, on the native layer. Most of the layout can also get preserved if the OS has that optimization. In addition to this, even your JavaScript objects are recycled, right? Because the JavaScript component that React generates site is also preserved.
Jamon Holmgren:
This reminds me of this, and I don't even necessarily remember exactly. I remember when I was a kid, there's this story that I read about a cowboy and he was selling some cows to another, like a rancher or something like that. But he didn't have enough cows. He was supposed to bring maybe a hundred cows, but he only had like 20. So he put the rancher on a hill and he just marched the cows in a circle around the hill and told him to count them until there were a hundred and it was the same 20 cows just going around and around and around in a circle, getting counted five times each. So that's basically what you're doing here. You're basically just taking the same five or maybe 10 rows and just marching them over and over and over and just repainting them a little bit every time they go by. It's all smoke and mirrors. It's not actually an endless list, but it looks like an endless list. You can't tell the difference between that and an endless list, but that's essentially what you're doing with this recycling.
Talha Naqvi:
Recycling is a lot quicker than actually destroying and recreating. So one of the other things that we could do is reduce our render buffer. For those of you who are familiar with FlatList would know that it has a prop called window size and it's default value is 10, which means 10 screen worth of content is pre rendered, right?
Robin Heinze:
That's a lot.
Jamon Holmgren:
Yeah, it is a lot.
Talha Naqvi:
It's a lot, right? It's a lot. You can see that FPS counter dropping in the beginning. Believe it or not, with FlashList it's just 250 pixels.
Robin Heinze:
Wow.
Mazen Chami:
Whoa.
Talha Naqvi:
Yes.
Mazen Chami:
It's not even a full screen on some devices.
Talha Naqvi:
That's not even a full screen on most devices. So you are going to create a very small number of items.
Mazen Chami:
That's amazing.
Robin Heinze:
Well because creating takes so long, you need 10 screens worth of content to get you into the future. That's wild.
Jamon Holmgren:
Now this is not a new concept. I remember when I started doing iOS development 10 years ago, the built in table view controller for iOS would do recycling and it was a weird concept to learn. Okay, you put it into the queue and then you DQ something, one of the cells and then you repaint it and you adjust things and you have to, it'll give you an index so you can pull out of your data, but you had to do it really manually. I assume this is based on that and based on that concept.
Talha Naqvi:
Yes, exactly. And that's what we set out to achieve. Being able to recycle is going to lead to improvements in your memory consumption and reduce the CP overhead. And it did and worked out pretty well. And the other benefit that I was talking about, right, small render window, that impacts your apps responsiveness a lot. If you guys have a chance, just go and try it with a checkbox. You would see the checkbox is getting updated almost instantly. While with FlatList it's going to take sometime. Especially if you have that full 10 screen size worth of content render.
Robin Heinze:
You mentioned that it uses a transform mechanism to basically move the recycled view where it needs to be. Is that brittle at all? I mean, how precisely do you need to know the height of your content or things like that? How brittle is it?
Talha Naqvi:
We only really need you to provide just one estimate. So, no developer has to really just estimate everything or compute the height of any of the views. Let's say if you have 10 different types of views with 10 different hires, you can just provide an average. And we have made it simple, you can simply render a FlashList without an estimate and it's going to give you a suggestion. You can just take that suggestion and put it there.
Robin Heinze:
Oh okay.
Talha Naqvi:
And it's going to work pretty well. And after that it just takes care of everything. You don't have to do anything yet. Even if items vary quite a bit in size, we have enough tolerance and component that it's going to take care of it. And that's a good point because this is one of the things that we discussed a lot internally, that how do we want to get this estimate? It was a mandatory problem in the beginning, but we were not happy with it because it was difficult to compute. You had to do an average yourself. And that's where we came up with this idea of just compute it and suggest it as a one in that, add this to input.
Robin Heinze:
That's a really good user experience.
Mazen Chami:
All this is making me think whenever I'm using a longer FlatList, one of my biggest pain points is pagination. Does FlashList do anything specific to handle pagination? I mean, because you mentioned the 200 pixels that's very small and we're talking about potentially three or four scrolls. I don't know, most APIs will return either 50 or a hundred items and then you get the next 50 or a hundred. So is there anything happening to handle this or is it just because of the recycler view, all is well?
Talha Naqvi:
It depends, right, what kind of challenges you are facing. We haven't done anything special for that, to be honest, right? I can make a guess what your problem could have been, right? When you're at the end of the list and you do a pagination. Again, it'll try to fill up its entire buffer of 10 screen. So that might lead to a lot of performance hit because that's a lot to draw, right? But with FlashList, right, you'd almost always just draw those 250 pixels. You can choose to increase that in specific cases, but the default number is 250 and it works well in most cases. So no matter how many items you add in your list, right, there's no correlation between number of items and how FlashList is going to work.
Mazen Chami:
That's good to know.
Jamon Holmgren:
So speaking of recycling, you created Recycler ListView and that, was I think, was that pre Shopify that you created that? Yeah.
Talha Naqvi:
Yes.
Jamon Holmgren:
So tell me about that one because that's some of the underpinnings of FlashList. FlashList does stuff on top of it. First off, how'd you come up with and what were you using Recycle ListView for? And then secondly, how does FlashLists sort of build on that?
Talha Naqvi:
So while I was working for Flip Card back in India, so we had the same problem that Shopify had about lists and we solved it with the Recycler ListView, but Recycler ListView, we worked with a set of constraints or assumptions there. One was it has to be JS only because of how flip card operated and shipping over the air was also important for buck fixes and some of the important releases. So being JS only was important, we couldn't keep changing native code. But the recycling aspect of Recycler List, worked very well, especially if you didn't have Dynamic Heights, right? Working with Dynamic Heights and Recycle List was pretty hard because you need to estimate each and everything and you have to be quite accurate in those estimates, which is where most of the developer pain points used to come from.
So while working on FlashLists, we had to implement recycling. So we considered multiple aspects. First idea was to add recycling to FlatList, right? Maybe extend from it, modify and try and add recycling there. But then we realized that if we were to add recycling, then a lot of other functionality that FlatList derives some, scroll view is going to break. For example, sticky headers, stuff like that. That depends upon you having each of your item rendered as an individual cell. So a lot of things were going to break. The second natural option was, of course, to depend upon Recycler ListView to do the same thing. And it comes with a lot of features that we wanted to build with. And of course I was super familiar with it. So we did, we built a small sample and it was with a figs hire, but it worked out pretty well. So everybody was on board. But the major challenges with the recycler list, we had to be saw for example, layout being on JavaScript and you get tons of glitches with it if you have dynamic hires.
And what we did is we added a layout algorithm on the native side. We call it auto layout view. What it does is it can accept anything that resembles a grid layout and it can correct it before it's painted on your screen. So recycle list, we can generate whatever it wants, but when you see it it's going to be correct. And that helps with almost everything. Like your blank area is reduced because if you imagine if your estimate are too large or too less, you can get blank spaces. But given this algorithm is preemptively just correcting everything, it eliminates that problem no matter what size of elements you have. And then a lot of people don't know how to tweak Recycler ListView. It has so much stuff in it. So we did that for everyone as part of FlashList.
We don't even use Recycler ListView at ATV. We use a derivative called Progressive list view. Oh okay. Yeah. Which makes sure that your load times are super fast. It's going to measure how big is your screen, then figure out how many elements to mount and then only draw what fills your first screen and then automatically batch the rest of the draw for your second frame. And then in the next frame it's going to build your recycler pool automatically. So when you actually start scrolling on FlashList, you're actually drawing nothing new. It's all getting reused. While if you implement Recycler ListView for today, you'd most likely have a few frame drops when you just start to scroll because it's going to start building items to fill its recycled pool. Which FlashList doesn't have to do, it just does it in the beginning.
Jamon Holmgren:
You're measuring things in terms of actual frame by frame. Like a video game would do, where you're trying to fit everything into a frame.
Talha Naqvi:
So our goal was to just make sure that, how should I put it? You shouldn't be able to make performance related mistakes easily. There are certain things that are difficult to control in that area, but for the most part, if you use FlashLists, you'll have a pretty well performing list quite easily.
Jamon Holmgren:
So, FlashList seems pretty awesome and it's amazing how quickly it's been adopted across the whole ecosystem.
Robin Heinze:
Almost all of our clients are at least talking about their plans to implement it. Or they already have.
Mazen Chami:
Just this morning I was working with one of the other devs, Frank at IR and we were implementing FlashList in Ignite.
Jamon Holmgren:
Our boiler plate. We made that decision, even though we normally won't include something that's this early. We want to try it in a couple projects and see how it goes. But it sure seems to be rapidly, I guess a testament to your team's high quality work, really?
Robin Heinze:
Well it comes from Shopify, you trust it. There's a certain amount of reputation there.
Jamon Holmgren:
I would agree with that. So I guess the question that comes out of that is, well, it's a multipart here. First off, would there be any plans to integrate this into the React Native core, as FlashList? Or, could the original FlatList be modified to use some of these techniques to be faster itself?
Talha Naqvi:
We haven't specifically had any discussions with Meta around this or anyone in the community. But again, I have a viewpoint, right, when you are a separate package, you can move a lot faster. Imagine, right, if you have to wait for a React Native upgrade to get a fixed and FlashList, right? I strongly believe in modularizing stuff and I believe that having it outside might actually be better.
Jamon Holmgren:
Well actually if I can interrupt here, it might actually make sense to just get rid of FlatList out of the core.
Robin Heinze:
The Lean Core ...
Jamon Holmgren:
The Lean Core Initiative.
Robin Heinze:
They're removing so many packages already.
Jamon Holmgren:
Pulling stuff out.
Mazen Chami:
Just put it in the community repo and people can choose to use it over FlashList.
Jamon Holmgren:
There's an argument to be made that maybe React Native should come with some sort of a list, some sort of a thing that you can display a list with because that's such a basic concept and bringing in a third party just to show that maybe is going a little far. But I don't know. I mean it makes sense what you're saying.
Robin Heinze:
I mean I can see Meta at least wanting to support it, officially mention it in the docs. I mean given how widespread the adoption is at this point, I'd be surprised if Meta doesn't get involved in some way.
Talha Naqvi:
That'll definitely be cool. I think lists are a problem. It's quite an outspread problem, right?
Robin Heinze:
Every app in the universe has a list in its own way.
Talha Naqvi:
It's pretty widespread and everybody has been through this and I think that's why the adoption is looking pretty good because most of the people have list. Most of the mobile applications are lists, right? Honestly speaking, right?
Robin Heinze:
That's 90% of what we do is fetch data, put it in a list.
Jamon Holmgren:
And credit to Utah and your team, keeping it compatible with the API was a huge decision because you could have gone with maybe a different API, there are other options out there, but you just said nope, FlatList API is close enough, let's do basically that. And so people can rename their FlatList to FlashList, tripping up Mazen every time and then maybe a few gotchas, but otherwise it's just a drop in replacement, which is really, really good for adoption.
Robin Heinze:
That's huge.
Talha Naqvi:
And that was the idea when we were discussing what API were going to keep. But having just same API as FlatList you can make it a drop in replacement like you mentioned, but you don't really even have to educate anyone, right? Let's say if you had already worked with React Native, you're familiar with that FlatList API and you can just start working on FlashList, right? Your official documentation also teaches you FlashList. So I was pretty excited by that idea and it's a good API to be honest, right?
Jamon Holmgren:
It is. It is.
Talha Naqvi:
It's a good idea.
Jamon Holmgren:
I like FlatList API.
Robin Heinze:
It's much better than ListViews API. That's the dark days.
Talha Naqvi:
ListView. Coming back to this point, having the API same, it enables a lot of interesting use cases. For example, we do differ from FlatList in some areas. For example, if you specify a sticky header indices and you have zero in there, FlashList is actually going to stick your first item while FlatList is going to stick your header. So we made couple of choices like these because we felt that this behavior is too implicit, right? If I have sticky headers calculated and I just add a header to my list, now I have to offset all these sticky indices by one. That was weird.
And then there are some use cases which don't work in FlashList right now. For example, if you have a very small list, right? Two, three items and you want to reuse that component inside another scroll view, right? The idea is that your same component can become an infinite list but can also be embedded in other lists. So FlashLists cannot do that right now, we do not support Flex Grow, but if you have the API, just like FlatList, right, you can simply implement an if statement in your code, that if it's being embedded, continue to use FlatList because you don't care about performance that there are two, three items. But if it's not embedded, just use FlashList.
Jamon Holmgren:
You can have const my list equals and then a turnery and return either FlashList or FlatList. And then when you say my list, just use either one interchangeably.
Talha Naqvi:
And that's how we have implemented in couple of our apps vertically. Because we usually release things under a feature flag first, test it out and that feature flag does exactly that. If on use FlashList, if off just go to FlatList.
Mazen Chami:
Do you guys have any plans to integrate with the new architecture? Or is it already compatible with the new architecture?
Talha Naqvi:
Okay, so it's not going to work with new architecture right now, but huge shout out to Software Mansion. They are helping us in actually getting that done and they have already raised the first PR. So it's going to be compatible with the new architecture pretty soon. There are some issues that we are seeing on Android that we want to investigate and make sure that there are no performance issues, right? Ideally we wanted to work faster on the new architecture because the bridge overhead is supposed to go down with fabric, right? So theoretically it should make FlashList a lot faster without us specifically using any synchronous APIs or anything like that. But we just have to make sure that happens and we vet it quite well before we push it out.
Robin Heinze:
So we've talked a lot about what makes FlashList awesome and we all think it's awesome, we're all using it. But I want to know what sucks about it. It's a blunt question, but it basically means just what needs to be improved? Why might you not use FlashList and stick with FlatList?
Talha Naqvi:
That's a good question. So there are couple of things that suck because of recycling itself. I give you an example. Most of the people when they implement FlatList, they would assign an explicit key and that's what React recommends that you add a stable key to your items, which is dependent on data and not on indices or anything like that. But if you add that key by mistake to FlashList, right? All your recycling benefits just disappear. So that's one thing that's very easy to miss and it has been a little difficult to educate people about it. Community has picked it up very well, but that's the easiest thing that you can screw up and lose your gains.
Jamon Holmgren:
Well it's been beat into our heads, put a key on any repeating item, put a key on it, put a key on it, and then tele comes in and says, stop putting keys on stuff. We got this handled.
Talha Naqvi:
In fact, we even recommend people, if you're rendering, let's say a complex component inside FlashList and you have a list inside or you're entering a scroll view by doing an A dot map, we suggest that we explicitly ignored LinkedIn Putin this is there as well. Oh wow. Because if you do that, right, for example, let's say you have five products with product IDs that you're entering as a list within your component. When it's being recycled, product IDs for all of them are going to change and these items are going to get recreated. While if you would've used indices or something that does not change, FlashList would've been able to just recycle them, too.
So the idea is it's a little, recycling is a little bit difficult to understand and to get maximum gains, you have to get familiar with that idea. Another example of that would be people use a lot of foundationals inside React component, right? If this is their render image, if not render now, right? But if you do that, you're losing out a recycling. These could be minute gains. But if instead of destroying you just set, let's say display none, which just hides it, removes it from layout, but doesn't actually destroy it, then FlashLists wouldn't even have to recreate that on the next recycle.
Jamon Holmgren:
You want everything there, but then just configure it by hiding and, that makes sense. You want basically the identical cells scrolling by, that you can just turn a couple things on and off.
Robin Heinze:
So, it'll take some change in our habits.
Jamon Holmgren:
Yeah.
Talha Naqvi:
Yes. And if you have completely different looking items, so you can assign different types to them and let FlashList know, right, that this is of this type, this is of type two, this is of type one, and then it can make sure that it chooses the right component to push the new data in. But if you're rendering same type of items, if you make sure that they do not change a lot internally, using these conditioners, it's going to perform a lot better.
Jamon Holmgren:
Just remember, it's those cows going around the hill. You want to make sure they look different so that the rancher doesn't clue in it's the same cow.
Talha Naqvi:
So that's one thing. The other thing is, again, recycling. A lot of people, when we open, so we saw a lot of people in the Discord community complaining about how their items were not actually updating. So the problem was they were using use state inside their components, making a copy of the data and then updating, right? And when FlashList was recycling them, they were not doing a set state or updating that internal state. So items were not changing. So that is also something that we had to work on educating everyone. A lot of lists do not do that, most of the people always make sure that components can get updated. But again, that's one of those gotchas that you need to know about and you can miss when you're migrating. So that's all about how recycling is a little bit harder compared to just destroying and recreating.
The other thing, in terms of missing features actually we are very, very close to FlatList. Except bidirectional, infinite scrolling. That's something that we have really not been able to get to, I would say. We had a prototype working where you know can have a chat application and you can add items to the bottom or to the top, without shifting elements. But it's something that we want to make sure works well before we push it out. The prototype works well on iOS, but on hand Android, we still have some issues where you can see certain glitches. So we want to fix that. So if that's important to you, then you should probably still use FlatList. But let's say if you are happy with an inverted experience on FlatList and you use your chat application that way, you can do it FlashList as well.
So, I think that flag is called maintain visible content position. If you heavily depend on that and their score part of your experience, then FlashList cannot do that right now. But everything else, it can do pretty well.
One more thing that's coming to my mind very quickly is when you do make a mistake on FlashList and a severe one, right? Let's say adding a key on your primary component, you will notice performance issues a lot sooner because of how small our end buffer is, which I talked about in the beginning. So, that's also something that people have to really think about. But, other than recycling, I wouldn't call anything a major drawback or really sucks about FlashList. If you can change your mindset and adopt recycling, then I think it's pretty easy to use and you can get very close to nativeless performance, like they'll be practically indistinguishable.
Jamon Holmgren:
So we have many more questions that we did not get to, but we are out of time here. One of the cool things also is that this is already being integrated into Expo, so it's something that you can use in Expo, I think 46 or maybe in a 45. I don't remember exactly which SDK, so that's awesome. Talha, where can people find you online to follow along and learn about the latest and greatest FlashList improvements?
Talha Naqvi:
You can follow me on Naqvi Talha on Twitter.
Jamon Holmgren:
Okay. That's N-A-Q-V-I T-A-L-H-A on Twitter.
Talha Naqvi:
Yes.
Jamon Holmgren:
You can also follow us here at React Native Radio, at React Native R-A-D-I-O. You can follow Robin, @robin_heinze. Mazen @mazenchami. And I'm @jamonholmgren. If you want to nerd out more about React Native, check out my Twitch stream at rn.live. I've been not streaming as much this summer, but I'll be doing more as we head into fall and winter, of course.
Robin Heinze:
Too much time in the pool.
Jamon Holmgren:
That's actually true. Trying to patch those patches.
Robin Heinze:
Patch those patches.
Jamon Holmgren:
You can also join our Slack Community at community.infinite.red. We have over 2000 React Native developers in there. And we do have a new Twitter community, rntwitter.infinite.red. Thanks so much, Talha, this is fantastic. And also thanks to you and to the team there and Shopify itself for open sourcing this solution and letting the rest of us use it. It's really, really cool. A great addition.
Talha Naqvi:
It's been fun. And thank you all for having me here. It was a pleasure talking to you all and talking about FlashList.
Jamon Holmgren:
Likewise. As always, thanks to our producer and editor, Todd Werth, our assistant editor and episode release coordinator, Jed Bartausky, our designer Justin Huskey and our guest coordinator, Derek Greenberg. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/reactnative. And, of course, thank you to the listener. Make sure you subscribe if you're not already. Hey, give us a little review in the app store. We don't ask for this, hardly ever, but we appreciate it. We have far too few reviews in the App Store and Google Play Store and Spotify compared to how many people we know are listening. There are a ton of you out there, thousands and thousands that are listening right now. So, Robin, do you have a mom joke by the way, to finish this off?
Robin Heinze:
I do. Why did the electrician fall in love with every girl he ever met? Because he couldn't resist her.
Jamon Holmgren:
Oh man. Nerdy, nerdy job. You know what? You know our audience. You know our audience.
Robin Heinze:
Yep, yep.
Jamon Holmgren:
That's pretty funny. I guess that's it. We'll see you all next time.
Robin Heinze:
Bye.