Infinite Red's own Mark Rickert joins to discuss the new Ignite 11 "Bison" release and the thoughtful changes that went into it! This latest update removes MobX State Tree as the default state management to give developers more flexibility, streamlines everything to new architecture-only, and includes improved light/dark theming right out of the box.
He also shared with our hosts why the name of this release is codenamed "BISON"
Show Notes
Connect With Us!
This episode is brought to you by Infinite Red!
Infinite Red is an expert React Native consultancy located in the USA. With nearly a decade of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter, core React Native contributors, creators of Ignite and Reactotron, and much, much more), Infinite Red is the best choice for helping you build and deploy your next React Native app.
Jed Bartausky:
Welcome back to another episode of the React Native Radio Podcast, episode 3 42, ignite 11 bison with Mark Ricker
Jamon Holmgren:
Mazen. I don't understand why you look so tired. You just got how many weeks off from work and you come back and you look tired. You should be resting on your time off. Why are you so tired?
Mazen Chami:
I know, right? It was a month off, but it was a month off of no sleep. My daughter was born about
Robin Heinze:
Yay. Yay.
Mazen Chami:
Yeah, so she's been keeping us up quite a bit, but usual baby stuff.
Jamon Holmgren:
I am not used to this usual baby stuff, but my granddaughter was here, I guess it was like four or five days, something like that. It's all a blur at this point. I forgot how much work it is to have a nine month old. She can crawl. She's constantly busy, constantly into things, constantly wants something super cute. You want to hold her and then she wants to wiggle and get off your go crawl away. And then her sleeping patterns are basically, oh, grandpa's sleeping. I'm going to wake up and wake everybody else up. That's very familiar. Yeah.
Robin Heinze:
Well, I'm sure you have a little bit of renewed empathy for your son and daughter-in-law.
Jamon Holmgren:
Yeah, T Life
Robin Heinze:
With a nine month old.
Jamon Holmgren:
Yeah, she was here. They were off doing a camp thing that they were doing and yeah, it was fun. It's always great to do the bonding thing. Of course, Mazen, I'm sure that you've been doing plenty of that with your new little
Mazen Chami:
Kid. Yeah,
Jamon Holmgren:
Yeah, for
Mazen Chami:
Sure. For sure. It's nice to have that time to just kind hang out and finish the newborn stage. It's kind of like a hard stage to, it's our second kid, so it's kind of remembering how to ride a bike again, almost that type of thing.
Jamon Holmgren:
And how's Zaid been kind of handling all this?
Mazen Chami:
He's been good.
Jamon Holmgren:
He
Mazen Chami:
Is actually a very good big brother and I think we haven't had any incidents, I guess is the main thing to think about here, so it's all good.
Jamon Holmgren:
Yeah. Alright, well along with Robin and Mazen, of course I'm Jamon. We also have Mark Rickert today, guest hosting with us. Mark is on our team. He's been on the show before. Welcome back, mark.
Mark Rickert:
Hey, thanks for having me. I'm happy to be back on the show.
Jamon Holmgren:
Awesome. I assume you haven't had to watch any little infants or anything. No, but I do have a nine month
Mark Rickert:
Old kitten, which
Robin Heinze:
Is,
Mark Rickert:
It's a whole other type of, yeah,
Robin Heinze:
Same, same. He
Mark Rickert:
Wakes you up in the middle of the night and brings toys onto the
Robin Heinze:
Bed and
Mark Rickert:
Yeah, it's not quite a baby level of annoyance I think, for me. But yeah, having a kitten is fun.
Jamon Holmgren:
And to be fair, you do have to deal with Todd every day as well, so a couple of babies. Alright. I hope he's not editing this one. He's going to,
Robin Heinze:
Oh, he will now
Jamon Holmgren:
Leave every cough in for me. Love you Todd. Alright, so Mark is a principal software engineer here at Infinite Red has worked here for longer than the company has existed. True. Mark and I actually knew each other before I knew my two business partners way back in the day. We did some iOS native open source work together. Mark, you're an extreme sports enthusiast. What all have you done list all the different types of extreme sports that you've done over the years
Mark Rickert:
Or
Robin Heinze:
Just in the past four days
Mark Rickert:
Maybe? Well over the weekend I did participate in a downhill mountain biking race, but most of the extreme sports that I do are related to flying. So something where my feet are off the ground that generally it started with skydiving that moved into, yeah, that moved into wingsuit flying, that moved into base jumping, that moved into paragliding. So yeah, anything where I'm flying either assisted or unassisted by an aircraft, I love it. I just like having my feet dangling from a parachute. It's a lot of fun.
Jamon Holmgren:
You have a para motor, you flew that from right near my, you couldn't quite take off from my property, didn't quite have the room for that, but you took off from a nearby area and were able to fly around my house for a while.
Mark Rickert:
Yeah, unfortunately that powered Paraglider met a fiery death in a house fire at my friend's house.
Robin Heinze:
Oh no.
Mark Rickert:
Yes, I don't, I don't have that machine anymore, but I do remember when I was flying, some maintenance guy came over and started yelling at us because he said I wasn't allowed to fly there. Apparently he thought it was like a remote controlled flight thing or something. I don't know.
Jamon Holmgren:
I think he could tell it you were flying around and it was pretty clearly you. But there was a sign that he pointed to that said I was there and he's like, look, you can't fly here. And it said no radio controlled
Mark Rickert:
And there was nothing radio controlled about,
Jamon Holmgren:
It's not radio controlled. I thought we were good here and he just wasn't having anything.
Mark Rickert:
I think we were looking at the letter of the law and he was looking at the spirit of the law. A lot of people don't like how loud the para motors are.
Jamon Holmgren:
Yeah, fair. Yeah. Fun fact. Mark once released an app to the app store while in free fall there's actually a video of this. How high were you when you did it? I guess I see what you did there. If I'm asking Mark, that could mean two different things.
Mark Rickert:
Yeah, no, first of all, I never do extreme sports with your mind in an altered state. Second, I did release an iPhone app specifically about skydiving to help you locate drop zones in your local
Robin Heinze:
Area. That's great marketing.
Mark Rickert:
Yeah, genius. It was a long time ago, but if I remember, I had to wait till 7,000 feet. You start at 14,000 feet. So I had to do half the skydive before I could even get the cell phone signal to get the data at speed in order to hit the button in the Xcode Connect app on my iPhone. So I just set the app to automatically get reviewed and then hold until I was ready and then I just hit the button.
Robin Heinze:
So you weren't coding, you weren't coding in free fall.
Mark Rickert:
I wasn't coding or
Robin Heinze:
Waiting for Apple, but you connect to the app store and hit a button, which is pretty cool.
Mark Rickert:
Yeah, well, because a lot of people don't realize this, that cell phone towers, they have directional antennas and so they're spreading the signal out over the ground. They're not sending it straight up and so you actually have to wait until you get closer to the ground in order to actually get enough data speed to actually do anything.
Jamon Holmgren:
It's wild that you did that, but it's so appropriate for the type of app it was and for the type of person you are. I do want to really quickly mention our sponsor, the company we all work for Infinite Red. It's a premier React native consultancy located fully remote in the us. I promise you that most of the time your coding will be done on the ground with both of our feet on solid ground. And yeah, if you want to work with Mark or any of the other amazing developers like Mazen here at Infinite Red, hit us up. Infinite Red slash React native, or actually I think it's Infinite
Slash Radio. I've only been doing this for what, five years now? Anyway, reach out. Alright, let's get into our topic for today. We're bringing Mark on because he was kind of the main person coordinating the next major iteration of Ignite and we're going to talk about version 11 now. Quick overview. Some of you in the audience may not know either that Ignite exists or maybe don't fully understand what it does. Ignite is a React native app generator. Essentially there's a CLI that generates an app, just a boilerplate app. It's really easy to spin it up, just takes a few seconds. It's also opinionated in the ways that Infinite Red likes to build React native apps with our 10 years of React native experience, we've been doing this for a long time and Ignite came out really only six months into us starting this journey. So it's been with us the whole way and iterating the whole way. And so as we discover good ways, good patterns, good bits of code to build expo or react native apps, we integrate those back into Ignite, which allows us to spin up the next one in less time. And it's also kind of like a reference. It's something we look at and say, Hey, this is how we did it in the past. You can copy some code or you can at least look at the patterns, what's the folder structure, et cetera.
Mark Rickert:
Yeah, I've done that a lot with my current client with the project I'm working on. It's been really great to have them present a problem to me and I just go, oh, we already have that as an example and Ignite and I just link them to the source code and they're like, oh, this solves our problem. Exactly. Yeah.
Robin Heinze:
They had already started their project before we joined them, otherwise we probably would've suggested they actually generate their app with Ignite and not have to do all the sort of back work. But it's definitely nice to have it
Jamon Holmgren:
And it lets you, there are some decisions that you can make. You can just accept everything as defaults or you can make some decisions like whether you're going to use React navigation or expo router, what package manager you want to use. We're not going to dictate that because we know everybody has a different opinion on that. And you can also strip the demo code out or leave it in for examples like showing some navigation, some
Mazen Chami:
Bottom tabs,
Jamon Holmgren:
Bottom tabs and things like that. But also different components and whatnot. It does come with some basic components. We make sure that they're not too involved. This isn't like a full UI kit for you, but rather these are very flexible components that just have some nice customizations and some niceties to them. We use them in the default app so you can see how we use them and there's a showcase built in sort of like using Storybook or something like that, but it's just simpler. There's a lot of really nice defaults, presets for a lot of configuration. So we handle all that stuff so you don't have to. And there's some fixes for some different common pitfalls like Safe Area View is already implemented for you. Keyboard avoidance is already set up. How many of you have set up a new app and then had to go and figure out how to do all this stuff that's just built in. You don't have to think about it, you move on. It's already set up. I need a custom font.
Mark Rickert:
Okay,
Jamon Holmgren:
It's already set up. You just add a font in the right spot and you're good to go. Themes, internationalization M was very, this is stuff that Ignite has provided over many years and we continue to evolve. Yeah, I do
Mazen Chami:
Think also something that you kind of brushed on for the CLI that I think is very important too is our generators. So those give you the ability to generate, well we'll get into this later, but give you the ability to generate screens and components. So essentially there's a template file that you can edit however you want your style to be. Every company might do things differently, whether you want constant screen equals that or you want add as a function, you can set up those generators for you and those save a lot of time over time. And if you have your own state management, you want to set up generators for your own models, you can set those up and the list goes on and that helps a lot. I do know one of our clients a big decision to stop with the app that they had and shift to Ignite was the generators and the speed that gave and the ability to use the CLI to generate screens, components, models, et cetera. Just from the CLI.
Mark Rickert:
Yeah, that's interesting. So many people care about so many different parts of Ignite and generators are a part that I've never used. I've never worked on them. It is just a part of Ignite that exists that I personally don't find value in it. But it's great to hear that other people do because my MO is, I usually just take an existing thing and copy and paste it and rename everything. And I think that's basically a generator. But other people may have other opinions.
Mazen Chami:
It's a manual generator.
Mark Rickert:
Manual generator.
Mazen Chami:
That's the one one that you get to pull the court to get it started rather than press the button.
Mark Rickert:
Right, exactly. Yeah,
Jamon Holmgren:
I like
Mark Rickert:
That the pull starts.
Jamon Holmgren:
We talked about maybe removing generators, but we actually heard from the community that a lot of people use them
Robin Heinze:
Well and they can be whatever you want give you. It comes with a screen and a component and a model, but it's just the tooling to have it be whatever you want if you're query,
Jamon Holmgren:
We simplified it quite a bit and Ignite, I can't remember which Ignite it was, but I actually rewrote a lot of the generator code to, because we had something really kind of complex before and just kind of rewrote it to be something that just did the basics and then yeah, you can go do your own modifications to it. Alright, really quick. So Mark did write an article about Ignite version 11. You can go read about that. We'll put the link in the show notes. It's on Redshift, which you can find at Shift Infinite Red. That's our blog. But also we're going to go through it today in a little bit less detail. Of course we only have so much time, so
Robin Heinze:
Less detail but more fun.
Jamon Holmgren:
Alright, here's a quick list of the important pieces. I'm not going to make any commentary about any of them. We'll do that next. So one we removed MobX State Tree as the default state management. We also only now support the new architecture going forward. We have a new themeing, well it's more of like an iterated theming refactor that happened. We upgraded to expo SDK 53. 54 is probably on its way as well. But 53 right now, Android Edge to Edge is now implemented and we removed all the barrel files so you don't have these Index Ts files everywhere. And we also moved back to Flat List. We'll talk about a little bit about why we did that rather than using list. Alright, I think we should talk about removing MobX State Tree
Robin Heinze:
First. We're going to have a lot of confused people in the audience being like what?
Jamon Holmgren:
Yeah,
Mark Rickert:
It's the bison in the room. Funny.
Robin Heinze:
Go read the blog if you want to find out why this release is called Ignite Bison. It's hilarious.
Jamon Holmgren:
Okay. Yes. Why did we take out MobX State Tree when we have used it and evangelized it for over five years? Do we not like MobX State Tree anymore? We still like MobX State Tree.
Robin Heinze:
We still like MobX.
Jamon Holmgren:
Yeah, it's still a good system.
Mark Rickert:
Yeah, it's still great. MobX State Tree is a really great system for observable state if you've never used it before, it's very similar to Redux, but without all the boilerplate and a lot of niceties that you can do with computer values and things like that. I
Robin Heinze:
Find it much more intuitive, intuitive to use than Redux. I have a much easier time forming a mental model of my data architecture with MobX State Tree then with Redux.
Mark Rickert:
So instead of slices and reducers, MobX State Tree kind of has just a class that you build with functions that all just return values and behind the scenes, MobX State Tree memorizes that and handles all the dipping of everything. So yeah,
Robin Heinze:
It's very object oriented as opposed to Redux where you're dispatching actions to sort of iteratively update your state. It's much more like I have an object and I'm going to invoke an action on my object, which makes sense to me coming from Rails and active record. So I've always liked it for that reason.
Mazen Chami:
And I think as we're talking about state management in general, and we said Ignite is how we like to do things at Infinite Red, we have our own MSD. Sure, we like MSD, that's the one we want to use. But if I look down our line for our clients, not everyone is using MSD. We're using pretty much almost every state management tool out there. Right Jim, and I think you did a poll recently internally and I was looking back at that and I feel like every single one is highlighted in there.
Jamon Holmgren:
Yeah, yeah. It was kind of amazing actually. And we've seen this with the community as well. The one that seems to probably have the most, we talked about this actually in the state of React native survey part that we did or episode that we did. And Zoot is doing quite well. It's kind of moving up very quickly. Of course a lot of people use Tent Stack Query and there's now Tent Stack db or what is it, the new Tan Stack state management system that's coming out.
And we just recognize that a lot of times. I think a lot I heard from people over the years saying, I love everything about Ignite, but I don't want to use Mobic State Tree, so I didn't use Ignite. And it's like, well, okay, you could have easily taken it out, right? We had a CLI option in there to remove it. Remove it, but also I understand that and state management for whatever reason is the thing that everybody has lots of opinions about. So we've pulled that out. Bring your own state management library and you can integrate it very quickly. What we have in its place is just sort of like basic you state.
Mark Rickert:
Yeah, there's a couple React context examples in there as well. If you want to just use pure react context
Robin Heinze:
If you want to hear us talk more in depth about state management and all of our feelings about it. We did an episode just a few weeks ago, r and r 3 35 called State Management Revisited and we talk all about MobX Diet Tree and why we love it, but also why we took it out of Ignite. So go make sure you go listen to that one.
Jamon Holmgren:
Okay. And moving to the next one, new architecture only. So legacy architecture we used to have, well it used to say like, okay, do you want the new architecture? And it was kind,
Robin Heinze:
It was a yes or no in the CLI.
Jamon Holmgren:
Exactly. And now we don't even ask you, we just set it to new architecture only.
Robin Heinze:
You can turn it off manually after the fact after you've generated your project. But we don't even, we're just not even asking you we're just that
Mazen Chami:
If you are turning it off, maybe reach out and let us know why. Because I personally am interested to know why people are going back
Robin Heinze:
To. The med team is interested too. They always want to know why people are stuck on the folder.
Mazen Chami:
There are just a handful and I say when I say handful, it's like maybe five, literally handful of packages that are not new architecture compatible. And I know Meta is working with them to get them new architecture compatible. So
Jamon Holmgren:
Yeah, I think new architecture is now the present. It's not the future anymore. And
Robin Heinze:
It's not the new architecture. It is the architecture.
Jamon Holmgren:
It is the architecture. There's legacy architecture and the React native architecture. Alright, so let's talk about this theming. Refactor. So we had something before Mark, you brought this in from a system that you built for a client. How does this work? Why did you refactor it?
Mark Rickert:
Yeah. Well the old theming system used React context, but it wasn't organized really well. It wasn't very easy to understand what's going on in the context versus there was logic that was split between the use theme app theme hook that consumes the context and the context itself. So I moved everything basically into the theme context and then exported the provider. And then the use theme hook is only just like three lines of code. So it's really easy to understand where the themeing is all taking place. And this refactor was the result of work I did on two client projects. Both of them wanted dark mode as well as light mode. And Ignite in the past hadn't supported multiple theme modes. Generally they're just light and dark though our theming provider does support more than just light or dark. If you wanted to add a compact mode or something like or a holiday mode, exactly, you can put those in there and switch between them.
Now obviously the system switching between light and dark mode affecting your app wouldn't work. You'd have to manually set, okay, we want the holiday theme mode in here to override our users' selection of dark mode from their system. But it's a really easy way so that a brand new ignited app supports light and dark mode out of the box, which so many people always want their apps to support light and dark mode. But I feel like it's always such an afterthought that this makes it super easy to just implement the theme provider and your app will automatically switch between light mode and dark mode and then your users can say, no, I always want light mode or I always want dark mode even if my phone is in light mode. And there are ways within Ignite an Ignited app to allow for this as well as resetting it. And all of that stuff is in the demo app when you just ignite a new app and don't remove the demo code. There's examples of how you can switch back and forth between light and dark mode manually as well as switching the system on simulator. You can just hit command shift A on iOS and it will just go back and forth between the thing, the light and dark mode. But Android's a little more difficult. It requires an A, DB command. So
Robin Heinze:
Similar to like I 18 n Light and Dark Mode is something that like clients, designers rarely think to ask for when the project starts and is really, really hard to add three months in when they do think of it. So having it and Ignite is a really nice way just to know that you always have it from the beginning.
Jamon Holmgren:
Yeah, it's nice to have. Let's say you have two people working on a project, have one of them run it in light mode and another one run it in dark mode. And that way each of you notice if there's an issue as you're going. And also it's not just about the colors, you can also change heights and widths, spacing, spac, all that stuff,
Mark Rickert:
Typography, these
Jamon Holmgren:
Things. Anything that's across the board that would be in your theme ts file. You can make changes to that. And you can also do it based on other criteria. There's not just what theme is there. You have full programmatic control over all the styles based on how this works.
Mark Rickert:
It's
Jamon Holmgren:
A really well done system. It's well typed, it has a good TypeScript support and I'm actually using it in my rewrite of React Toron in Mac Os, which I haven't really talked about on this show as much
Robin Heinze:
Yet. A little teaser there won't talking about. I'm sure there'll be a future episode about that once you're done. Oh
Jamon Holmgren:
Yeah, react Native Macs content coming. Okay. Let's talk about how we backed away from Flash list version one and we went back to flat list for Ignite. Now this is a little bit similar to the state management and us removing MobX State tree situation where we still flash list, especially version two looks really good and I think, did it just come out anyway, it's coming out very soon or it's out already a
Mark Rickert:
Month ago I think.
Jamon Holmgren:
Yeah, yeah, so Flash List V two looks really good. There's also Legend List, also version two looks really good and we've had a lot of luck with those. But there's always trade-offs with any of these things. And by using Flat List to start with, then we allow people to kind of make that decision on their own. A lot of times it depends on the list itself. Some lists are going to perform super well with flash lists. Some are going to super well with legend lists and some will actually perform the best with Flat List. You have to just do your own kind of measurements. You should always measure. In fact, in some cases it's best to use a scroll view and manage things yourself. It really just depends on the situation. So we did back away from Flash List for now and we're using Flat List.
Mark Rickert:
Yeah, supporting Flash List came with a bunch of extra boiler plate code. There was some issues with the new architecture and this was really just mostly for me about cleaning it up, getting rid of some of the weird configuration things that I had to do in order to get list working in the old architecture. And so the general cleanup and allowing Ignite to be a little bit more flexible for users, it's really about letting users pick the list component that they want to use in their app, whether that's a pure flat list, flash list, legend list, they're all going to give you something different and we just wanted to make sure that we weren't interjecting the wrong defaults into people's apps.
Mazen Chami:
I completely agree with you Mark. At the end of the day, apps are just lists. Every app that we've kind of talked about that we've built is just a long list, whether it's vertical, horizontal. So using the right list is very important and sometimes, and I think this is something that I kind of want to stress using the new and shiny tool might not be the best option for you. And we've noticed that one of the project that I'm currently on, we discussed looking at Flash List. Well when we ran the numbers we realized Flat List just does a really good job for us. So there was really no point in adding another dependency. Just going to Flat List did the trick.
Mark Rickert:
Yeah, and I mean people like to hate on Flat List, but if it's implemented correctly with some pretty sane defaults, which are not the defaults that Flat List comes with, it could be pretty performant. Totally.
Jamon Holmgren:
One of the things I want to add to the new React Actron is the ability to, with almost zero effort, measure the performance of each of these lists as you implement them. So you just go to a tab that's like lists and you just can see right there what the performance looks like. You can swap 'em in and out. Their APIs are almost identical, so it's super easy to just try each of them and try different configurations with recycling on and with recycling off and different things like that. So I think it's really about us having some measure, some way to measure this and profile it over just having basic opinions. And I want to say we want to be opinionated where it really matters things that, well, in some cases it's just going to be our opinion and we're just going to put that opinion in there. In other cases, it's going to be, in our experience, we have had a lot of issues going any other direction, this is the best that we've found. But in some cases we're just like, okay, different teams at Infinite Red have had success with multiple approaches. We're going to go to the lowest common denominator let you build off of that is already included a React native. So we don't have to think about, we don't have, it's not like we're making the choice for flat list over the others. We're simply Springboarding off of that.
Mark Rickert:
And a couple weeks ago I did a training session for my client, my current client where I implemented a few different lists, a legend list, flash list, a performance flat list, and a non-performance flat list just so that I could show them how to use the profiling tools and the flame graph and things like that. And it is so easy to make a non-performance flat list, so much so that there's actually a flat list performance optimization page in the React native docs. So if you've never read that to learn how to optimize a flat list, you really should go and read those docs on the React native website.
Jamon Holmgren:
I want to talk about the barrel files thing. So barrel files, just for people who don't know are index usually index ts files that you can just import when you're writing your import statement, you just import from the folder, it then loads the index ts by default and that imports and exports, re-exports, all of the stuff that's in that folder. It just kind of collects it all up in a big barrel. And then lets you pull from that
Robin Heinze:
Basically just makes the import statements at the top of your file cleaner.
Jamon Holmgren:
You have one import statement that can bring in a bunch of different things and it's just a little bit cleaner in some ways. However, there can be some downsides to this. And Mark, what was sort of the thinking behind removing those?
Mark Rickert:
Yeah, well with a brand new ignited app, you don't have these problems at all because it is such a small number of files. But in my research and reading what other people were talking about with barrel files, I've learned that they can really mess up the resolution graph of your app. It just takes so much longer to resolve where all the files and components are that removing them just made sense. From a scalability standpoint, we wanted to be setting patterns for developers that will scale over time and barrel files generally don't scale very well, increase loading times. They introduce a lot of files that need to be maintained over time, whereas the trade-off to not having the barrel files is that you have two or three import lines versus one import importing components directly from the source instead of from that barrel file. But at the same time, it also reduces the risk of circular dependencies because you've imported something from a barrel file which also imports something from another file and you get this round robin of graph resolution, which again takes more time. It takes metro a while to resolve those circular dependencies before it's finally like, oh I give up, here you go, something might break. So that's one of the reasons why we removed the barrel files
Jamon Holmgren:
In Metro, if you don't import a file, you could have a million files in your app directory or whatever. If you don't import that file from anywhere that is reachable has been imported. So you import your main app tsx, right? But then everything that imports throughout the tree and throughout the graph is included in your bundle. Anything that's not does not get imported. But with a barrel file, as soon as you import the barrel file, it imports, it goes out and grabs all of its things. And so now all of those things are included and if you just don't end up using one of those files in your app, it's still there. It's still in your bundle, there's nothing you can do about it. And that's a very hard problem to solve with tree shaking and whatnot. That's actually, it's a non-trivial problem.
Mark Rickert:
And where I do recommend using barrel files though is if you're creating a package that you're going to publish and have other people consume those components, that's where barrel files really shine. So you can just export that one file from your package JSON, and you export the entire public API of what you want and you only put the things that you want to export to that public API in that barrel file. So barrel files are much better for packages that you're creating versus an app itself where you can just import a component from the exact file where you created it instead of abstracting that to another place.
Jamon Holmgren:
Alright, so because we don't have a lot of time, I'm going to really quickly skip through Android Edge to Edge. This is actually coming in Expo SDK 54, but we brought in a workaround for 53 as well. So it works already in Ignite pre Expo 54. And speaking of which we are testing that we always want to test new things in projects to make sure that they're working well before we put them in Ignite. Ignite is never going to be the bleeding edge. We're going to make it something that is, anything in Ignite should have been tested in a project by Infinite Red and with feedback pulled back, okay, this works, this works well, we're good to go. Then we put it into Ignite, preferably with two or three. Alright, last question. Let's say that you have a previous version of an ignited app and you've been building with that. How do you upgrade to the latest and greatest Ignite patterns?
Robin Heinze:
You don't, but it's more complicated than that.
Mazen Chami:
It's complicated. Just copy and paste your file somewhere else, ignite a new app and then copy them back.
Robin Heinze:
Yeah, I mean really the answer is anything that's in the new Ignite you can copy over into your project. There's not any reason for you to need the Ignite CLI version itself. Once your app is ignited, it's ignited exists, you can add or remove code, just like go copy it. There's also a tool called Ignite Diff Purge,
Jamon Holmgren:
Which yeah, it hasn't been updated in a while,
Robin Heinze:
But it really, all it does is it'll give you on GitHub a comparison of everything that's changed since the most recent version. And you can pick and choose what you're like, oh, I really want the new themeing system, just copy it into your app. That's really the way to go. And then the next time you create a project, just use the
Jamon Holmgren:
New Yeah, exactly version and React native has the React native upgrade helper and Ignite has Ignite Diff Purge, and it's kind of a weird name, but Nicholas Soderstrom from Sweden is the one who maintains this and he actually just released yesterday, it looks like support for 11, actually 11.1 0.1, which is out already. So you have actually just this graph of what version you're coming from and what version you're going to, and that just loads up a diff. And then you can look at that and apply those changes. It's not quite as nice as the React native upgrade helper, but it's very, very useful. I've used this before to bring in patterns.
Mark Rickert:
Fun fact, I implemented the Light and Dark modes switching on the React native upgrade Helper. Oh, that's
Jamon Holmgren:
Right. Yeah, yeah, you can thank Mark for that.
Mark Rickert:
I'm really passionate about Dark Mode. I opened the upgrade helper on an airplane one time and I was like, my eyes were blown out with the light mode and I was like, why doesn't the upgrade helper have a dark mode? And so I did it and they promptly added me to the GitHub team so I can make updates to the upgrade helper. Now
Mazen Chami:
You woke up the whole plane and they were like, Nope.
Jamon Holmgren:
Yeah, exactly. Mark, you also tried this on your new Meta Quest headset side, didn't
Mark Rickert:
You? MedQuest three. Yeah. My wife got addicted to Beach Saber while we were visiting family on the East coast. And so when we got back, I just bought one just so that we could have it at the house. And I listened to the episode that you recorded about the Met Quest and he was like, we'll just plug it in and try and build an app to it. And so I ignited a brand new app and I plugged my Oculus in developer, sorry, my Meta quest in developer mode, and I typed yarn Android and I put the headset on and the app was there and it worked. The demo, everything. I could listen to the React Native Radio podcast from the app. Yeah, it does work out of the box with light and dark mode working. It was pretty cool to actually just run a command with it plugged into my computer.
Jamon Holmgren:
No changes.
Mark Rickert:
No changes at all. The UI was a little laggy, but I don't know if that has anything to do with all of the other stuff I was running at the same time on the headset.
Jamon Holmgren:
It's probably flat list. Let's just blame it on
Mark Rickert:
Flat list. It might've been flat list, but yeah, it was super easy. I heard them say that statement, just try it. And so I was like, oh, I'll just try it. And it just worked. It just worked. It was really cool.
Jamon Holmgren:
Awesome. So go get yourself a MedQuest three. I have one as well. I've been using it for various things. It's been fun.
Mazen Chami:
Don't forget to use r and r on checkout, please. I'm
Jamon Holmgren:
Kidding. Yeah, we should have. Oh man, we totally should have that. I wonder how many Quest headsets we've sold through the program
Mark Rickert:
Now that I've talked about it on the podcast, can I expense it?
Jamon Holmgren:
We will talk about that offline. Alright, Robin, take us out with the mom joke.
Robin Heinze:
I have one from Mark Rickert, our good friend.
Jamon Holmgren:
Oh, I know that guy. Hey,
Robin Heinze:
He's pretty cool. I asked my German friend if he knew this square root of 81. He said no.
Jamon Holmgren:
Alright, we'll see you all next time.
Jed Bartausky:
As always, thanks to our editor, Todd Werth, our assistant editors, Jed Bartausky and Tyler Williams, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.
There’s no perfect time to get started. Whether you have a formal proposal or a few napkin sketches, we’re always happy to chat about your project at any stage of the process.
Schedule a call