Harris and Jamon talk about the newly released Ignite, code-named “Ignite Flame," the latest version of the most popular React Native project boilerplate. They discuss what it is, what changes in Flame, and what the motivation for the rewrite was.
Harris and Jamon talk about the newly released Ignite, code-named “Ignite Flame," the latest version of the most popular React Native project boilerplate. They discuss what it is, what changes in Flame, and what the motivation for the rewrite was.
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!
Jamon Holmgren:
Hey everyone. Welcome to the React Native Radio podcast where we explore React Native together. I'm your host, Jamon Holmgren. Today we are doing a special episode where it's just gonna be the two of us, Harris and I. Adhithi and Robin couldn't make it today. How are you doing, Harris?
Harris Robin Kalash:
I'm good. I'm good. How are you, Jamon?
Jamon Holmgren:
I'm doing okay. I'm doing okay. We'll have to forge ahead without Adhithi and Robin. They usually are the stars of the show, but we'll try to do our best imitation of them.
[Harris and Jamon laugh]
Jamon Holmgren:
Where are you today, Harris? You're in today in adventures of what is it? Where's Harris?
Harris Robin Kalash:
Where--
Jamon Holmgren:
Where's Harris?
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Sort of like Where's Waldo?
Harris Robin Kalash:
Yeah, where's Harris around the world? Yeah, I'm still in Vancouver City.
Jamon Holmgren:
Okay.
Harris Robin Kalash:
Yeah. I, from last time, just changed neighborhoods. And--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
I'm here for the foreseeable future. We'll see if I can make it back to Montreal for Christmas. But, I'm going with their regulations. So, I might not be able to go. But we'll see.
Jamon Holmgren:
Yeah. Yeah, things are probably locking down around there as well.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
So how are things going in Canada in general?
Harris Robin Kalash:
Yeah, it's interesting. We're probably stricter because we have like sort of the maritime provinces on the East Coast which basically have no cases of COVID.
Jamon Holmgren:
Okay.
Harris Robin Kalash:
Yeah, they've created what they call the maritime bubble.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
So, if you're not already in the maritime province, you pretty much can't go. And if you do go, you have to quarantine within their facilities. So, it's extremely like--
Jamon Holmgren:
Wow.
Harris Robin Kalash:
Yeah. Yeah. So, it's really hard to get there. So, even though I'm in Canada, I actually technically cannot travel anywhere in Canada easily. Yeah, and Quebec, they have strict lockdown. So, no gatherings. So, no Christmas. Basically, no gatherings--
Jamon Holmgren:
Wow. Yeah.
Harris Robin Kalash:
--around Christmas at all which is why I might stay.
Jamon Holmgren:
Yeah, they're certainly locking down here in Washington state as well. The cases are rising. Not to dwell on this too much, but I saw a graphic saying sort of like the deadliest days in American history. And there's the usuals like 9/11 and stuff.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
But then it said last Thursday. I was right there.
Harris Robin Kalash:
Wow.
Jamon Holmgren:
It's that bad. So, pretty tough. But, hopefully, we can get through it. And, hopefully, the vaccine's on the way and we can move forward. But--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--we're not here to talk about medical things, pandemics and the like. We're here to talk about React Native. Before we get into that, I'd like to say that this episode is sponsored by infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the USA and Canada. With years of React Native experience and deep roots in the React Native community, we are the hosts of Chain React. And we publish the React Native newsletter to over 11,000 subscribers. I think it's actually 12,000 now. I should update my notes. Infinite Red is the best choice for your next React Native app. Hit us up at hello@infinite.red. You can email me directly at jamon@infinite.red. And you can also learn more at our website, infinite.red. If you put infinitered.red/react-native, you'll get more React Native focused content. So, we actually just published that page the other day. It's looking really nice. Cool. So, let's talk about our topic. It's a library that's near and dear to my heart. I've been working on it as, I guess you could say, the core maintainer for many years now. And that's our open source library Ignite.
We're gonna talk about that today because I've been working on it for the past several months doing a major update. We are on version three point something right now. We've gone through several iterations in the past. So, I'll talk a little bit more about what ignite is just for the listeners, just to let people know kind of what's going on here. Harris has contributed to Ignite. He's certainly very knowledgeable about Ignite. He's not been involved in this latest update of Ignite. So, Harris, I'm gonna lean on you to ask me questions and stuff.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Not necessarily an interview, but it'll still be a panel here where we're talking about it. But, you can help me keep the conversation going and make sure that I don't miss anything.
Harris Robin Kalash:
Yeah, sounds good.
Jamon Holmgren:
Awesome. So, what is Ignite? So, ignite is a boilerplate for React Native. I would say fairly undisputed that it is the top or the most popular third-party React Native boilerplate. There are others obviously with React Native's Vanilla one that just comes with it. That's the default. And Expo has a few boilerplates as well that are well-loved and well-used. But in terms of actual stacks with full opinions baked in, Ignite really is the most popular one out there. In 2015 we started using React Native. And then in 2016 we decided, "Hey, we need to put our opinions into a boilerplate. This gotta be something where we can spin up a new app, we're an agency. So, we need to spin up new apps all the time. We don't wanna have to redo the first parts of building an app." So, that's where Ignite came from. And the first iteration was Redux. It was not TypeScript. It was just JavaScript, modern JavaScript. We used react-navigation. Trying to think of what else, redux-sagas. We used redux-sagas for side effects.
And we used that first for several years. And then 2017 we started working on the next iteration. And we actually, at that point, moved over to mobx-state-tree which of course is a different state management library than a competitor to Redux, so to speak. So, we also went TypeScript. We upgraded a lot of things. We made a few different choices in terms of how we organized our code and whatnot. And what's kind of funny about that, so the first one we called Andross. And the second one we called Bowser. These are all named after video game villains. And so we've been using Bowser up until this point. So, we're on version three. Like I said, version one was Andross. Version two was Bowser, basically. Version three was a major update to Bowser and Ignite itself. It brought in TypeScript for the CLI. Cuz there's a CLI component as well. You can type in "ignite new something", and it'll actually spin it up. That's important here to have a CLI.
Harris Robin Kalash:
So, is Flame version four?
Jamon Holmgren:
So, Flame is basically version four. Exactly.
Harris Robin Kalash:
Okay.
Jamon Holmgren:
And it's just a codename.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Why didn't I use Cyberdemon or something like that?
[Harris laughs]
Jamon Holmgren:
Which is actually our next codename. That's because it's bigger than just the boilerplate itself. The boilerplates have those names. But, this is actually a complete rewrite of the CLI itself. So, it's kind of interesting because we released Ignite CLI 2. And what we did was we basically opened it up. We made it so that you could have plugins. Because like here's an example. Let's say you have an app and you want to add maps, well, do you wanna have that in the boilerplate where every app that you spin up with Ignite has maps? That can be something you don't wanna do because that brings with it a lot of different things. It's a larger app, and you'd have to go through and delete that. So, that was kind of the problem we were dealing with. There's a kitchen sink. Do we wanna do that, or do we wanna add it later? So, plugins were the answer to that. We also had plugins for internationalization, we had various things.
Harris Robin Kalash:
Mhm.
Jamon Holmgren:
But, other places themselves were actually plugins. And we actually made a system where you can make your own boilerplate. And there were a few that became popular, like there's Ignite JHipster which is I think the most popular non Infinite Red boilerplate that uses Ignite. So, these were all things that were a concern at the time. And we developed this out, and we released it. It's done very well. But one thing that we've really noticed, and I know Harris you've been a part of this too, is that maintaining it can be difficult. Because you have the CLI and then you have separate boilerplates. And they have to work well together. And then, not to mention, the plugins themselves and whatnot.
Harris Robin Kalash:
But, yeah, definitely maintaining it can definitely be a pain.
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Oh.
Jamon Holmgren:
Yeah, cuz you've had to kind of answer some of those questions too. Like you posted this issue in the wrong repo, you're in the CLI, you need to be over at the boilerplate or vice versa.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Plugins were especially difficult because as we would evolve the boilerplate, then the plugins would lose compatibility. And what if you had the wrong version of a plugin? It was like we were maintaining another layer of NPM on top of NPM.
[Jamon and Harris laugh]
Jamon Holmgren:
Like our own package manager. This was something that was kind of foreseen by Steve Kellock who's kind of the brain trust behind the Ignite 2 upgrade. And he doesn't work at Infinite Red anymore, but he at the time was one of top developers. And he was really interested in making this more of a pluggable architecture. But, he did foresee that this could be a problem. And this is something he was a little worried about at the time. And it kind of came through. We eventually just stopped maintaining the plugins which is not great, but we didn't really have the resources to do that. And, in fact, a lot of times it was me. It was you, Harris. It was Bryan Stearns, sometimes others at Infinite Red. But, it was pretty difficult to find the time for that.
So, earlier this year I just started thinking, "You know what? Maybe we need to simplify. Maybe we need to streamline. Maybe we need to really bring this back to the basics of what do people really like Ignite for." Well, they like to be able to spin up a new app with all of Infinite Red's opinions baked in. Not all of them, but the basics, the stuff that you really need every single project. Then they also really like generators. And we'll talk more about generators in a bit. But, those were basically it. And plugins weren't as big of a deal.
Harris Robin Kalash:
Sometimes, things get outdated pretty quickly. If plugins are not maintained, that's not gonna--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--also encourage use. Yeah.
Jamon Holmgren:
Yeah, totally.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
So, I just started thinking about this and like, "Okay, yeah. Why don't we simplify?" My initial thought was I was gonna rewrite the CLI and then adapt the boilerplate to work with the new CLI. And I met with Bryan Stearns. Brian's awesome. He's been working in this industry for a long time. He actually worked with Steve Jobs on the original Macintosh. This is how long he's been--
Harris Robin Kalash:
Wow.
Jamon Holmgren:
--working. Like if you watch like documentaries about Steve Jobs, you'll see Bryan walking by in the background. All right, this is how--
[Harris laughs]
Jamon Holmgren:
--big of a deal he is. And somehow he works for me which is awesome. I love having Bryan around. He's the best. Despite having the pedigree he has, he's always excited about new technology. So, I love having him to bounce things off. But he told me, "Oh, Jamon, why not just put them both in the same repo rather than trying to coordinate? Okay, the boilerplate knows how to play well with the old CLI and the new CLI. And the CLI knows how to play well with the old boilerplate and the new boilerplate. Then why take on that level of complexity? Why don't we just recombine them back into one repository? It's a package deal. Ignite is ignite." And I'm like, "Wow, I should have thought of that. And that's great. That's a great insight. We tried to modularize it and make it so that you can just plug things in, it didn't really work so much. So, why don't we just go back to the original idea?"
Harris Robin Kalash:
So, I guess you've tried to over optimize, I guess, by, yeah, splitting it up? And would we still be able to have different boilerplates?
Jamon Holmgren:
So, yes.
Harris Robin Kalash:
Yes.
[Harris laughs]
Jamon Holmgren:
So, not with the new CLI. However, the version three still works. And what I've done in the new CLI, as I've rewritten it, it detects if you're trying to use Bowser, Andross, or JHipster. And it tells you, "Hey, you're using the new CLI. In order to use these, use NPX, ignite-cli@3
Harris Robin Kalash:
Right.
Jamon Holmgren:
So, with the @3 it tells it, "Use the previous version." And if there are big issues, we'll certainly go back and release new versions of 3 which it's barely budged in the last year and a half. So, I don't think we really need to probably at this point. But, that's available if people need to. So, we're handling that backwards compatibility as well as we can. That's kind of the idea behind it.
Harris Robin Kalash:
Okay. So Ignite Flame is going to be rewritten CLI, but the boilerplate's essentially going to be kind of what we have here with Bowser. So MobX-State-Tree Reactotron.
Jamon Holmgren:
Exactly, yeah. We're not gonna upset that too much. We're not gonna try to change up too much of that. There are some improvements for sure. And I'll launch into that when we kind of get to that point in the podcast, but it's gonna be pretty similar to Bowser. And it'll evolve though over time. It won't stay the same. There's a lot of plans that we have really based on our entire philosophy for Ignite. And this is something that we've really stuck with since we released it. Nothing gets into Ignite unless we've already tried it on at least one client project successfully, usually two, maybe three before we bring it into the boilerplate. Because we don't wanna be starting with opinions that are just opinions and not based on any sort of empirical evidence. When we can put something in there that we've used on a project, we know that it works. That's why we call it battle-tested. Ignite is something that powers big apps that are out there. And when we've used it ourselves, we do use it ourselves for new projects, then that just gives it the reliability. Even if you do run into issues and stuff we've run into as well, we can help.
Harris Robin Kalash:
Cool. Yeah, that's a good way to put it. Actually thinking now, we probably should have a section in Ignite Flame eventually where we show all the companies or all the apps out there that use it, of course if we--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--can get permission--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--from the client.
Jamon Holmgren:
Yeah, totally. Yeah, I would love that. I know there are a lot out there that use it. Not all of which we can say.
[Harris laughs]
Jamon Holmgren:
Kind of the downside to this--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--industry, part of the software we write is a part of some pretty big apps. But we can't really say sometimes. But, yeah. The ones we can, I would love that. In fact, listeners, if you have used Ignite in any form over the years, we'd love to hear from you. Just tweet at us @ReactNativeRdio on Twitter, and that would be something I'd love to put into a document like Harris is saying. So, Flame, I rewrote it from scratch. I literally spun up a new Gluegun app. So, Gluegun is a CLA library basically. It powers our CLIs. There are others out there that do a pretty good job. Gluegun is just the flavor we like. Ignite 2.0 and 3.0 were around 3,000 lines of code in 57 files. This is all TypeScript. And the Ignite Flame CLI rewritten from scratch is like 950 lines, so over 3,000 down to 950 lines of code--
Harris Robin Kalash:
Wow.
Jamon Holmgren:
--in 15 files. So, much much smaller. In fact, there's one file that contains probably, I don't know, 30 40 lines of code that really should move into Gluegun as a core library of Gluegun. That's something I'll probably do in the future, so it'll get even smaller. It also takes about a quarter less time to spin up a new app from scratch, so it's faster as well. It does less which is nice. There are some things, some kind of backflips we were doing to make it work in the past. Like spinning up a brand new app would require some some high jinks to make it work. And one of the ways that we've achieved this is by we're leaning on the React Native CLI now rather than doing it all ourselves. We also have Expo support. So, we're using the Expo CLI. We've removed a few of the features, too. So, plugins are gone. Like you can use them with Ignite 3, but don't try to use them with the Ignite for Ignite Flame version of the CLI. Third-party boilerplates are supported only in Ignite 3. So, if you need to support that, you again use Ignite 3 for that. There's a concept called sporking which was always--Sorry, Gant Laborde probably listening to this podcast. But I've never really liked the name of that. It doesn't really say what it does. Okay, Harris, let me ask you. What do you think Ignite sporking is?
Harris Robin Kalash:
I can see the similarity with forking, but I have no idea.
Jamon Holmgren:
Right.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
It's clever. It's clever. But, it doesn't really address what's happening. What it does is it copies your generator. Let me explain what a generator is, ignite generate component harris. Okay?
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
What it does is it generates a new component in your app components folder, creates a new folder. It drops in a couple of files like your style file in your component file and maybe some like a test or something. And it like names everything in there Harris. Everything is Harris now. And that's what the generator does. So, you can just run that anytime you need a new component, anytime you need a new screen. You say ignite generate or ignite g screen--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--login screen or login. And it'll generate a login screen. What we originally did was like it would reach out and like download the template every single time.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Sporking actually would put the template into your folder into like a special folder like an Ignite folder so that you could modify it. It was kind of a cool idea like, "I don't always want Infinite Red's version of a screen. I want my version of a screen." Maybe a particular project has a certain--
Harris Robin Kalash:
Oh, I see.
Jamon Holmgren:
--like you need some wrapper, you need some--
Harris Robin Kalash:
Right.
Jamon Holmgren:
You always have to bring in something.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Maybe a different styling library or something. So, just modify it there. So, that's what sporking was. But it was just not an well-known thing. I think there were people even at Infinite Red that didn't know it existed. It was pretty badly marketed and just not totally thought through 100%.
Harris Robin Kalash:
Yeah, I didn't know about it either.
Jamon Holmgren:
Yeah, yeah. What happens now is everything is sporked by default. Like it just copies in your templates into your folder. So, if you create a new Ignite app, you go to Ignite, like the Ignite folder in your app, slash templates. You'll see all of your templates there for any generator, and you can just go through and edit them. If you need updating, you just type in ignite. Now this might change. So, if you're listening to this podcast like a year from now, this might have changed. I don't know. But ignite generate screen -- update will actually download the old one you assume and like update it. So, if you made any changes to it, then those will get blown away at that point. But, you can always keep it up to date that way. So, it's a pretty cool concept. And it works, I think, very well. We're gonna probably release a video and certainly some documentation around how to use that. I think it's actually a very powerful concept that people really would use a lot if they understood. Because the new Ignite Flame will actually support more than just the ones that come with the boilerplate. You can make up your own on the spot. You can just be like, "Hey, I want the ability to generate translation files." or something like that. And you can just create a generator, and Ignite will know how to handle that.
Harris Robin Kalash:
Nice. Yeah, actually, that sounds really useful. I've never used it, but I think I'll try it next time.
Jamon Holmgren:
I'd like feedback on it, too. I know that some people prefer to just copy other stuff that they've already set up which is totally fine. But I think the more feedback we get around Ignite generators, the more useful they'll be.
Harris Robin Kalash:
Yeah. I mean, copying other stuff, that's what I typically do. But I don't know if I like it because often if I have a lot of interfaces or naming everything manually--
Jamon Holmgren:
Right. Yeah.
Harris Robin Kalash:
--and looking for Yeah.
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah. I'll definitely try it, and I'll let you know--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--how it goes.
Jamon Holmgren:
So, we're probably not gonna all the boilerplate Ignite Bowser anymore. We're just gonna call it Ignite. I think we'll go away from the codename idea. That's not a total final decision, but I think that's probably the direction we're gonna go.
Harris Robin Kalash:
So just Ignite, not Ignite Flame?
Jamon Holmgren:
Right.
Harris Robin Kalash:
Okay.
Jamon Holmgren:
Ignite is Ignite.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
You just always gonna have like the latest version of Ignite or whatever.
Harris Robin Kalash:
Yeah, that makes sense. Yeah, actually, I do remember being confused at the very beginning when I first learned about Ignite.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
Being confused as to what Ignite is--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--and like sort of understanding, "Okay, Ignite is just the CLI." And then there's Bowser and Andross and--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--and so on.
Jamon Holmgren:
Yeah, exactly. We're reducing the number of concepts that are associated with Ignite.
Harris Robin Kalash:
Not really the topic of this podcast, but another thing I'm curious about is how did--So Gluegun is an Infinite Red project, right? So--
Jamon Holmgren:
Yeah, it is. Yep.
Harris Robin Kalash:
Yeah. How did that come to be?
Jamon Holmgren:
Right. So that was a Steve invention. I mentioned Steve Kellock before.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
When he wanted to kind of go to a more modular approach for Ignite, he--So I think Ignite 1 was built on Yeoman, I believe. And that's a pretty popular CLI library. But he wasn't happy with Yeoman. There were a lot of issues with it. I think if he had found some others like Oclif o c l i f which comes out of Heroku. I think if he had found that, it probably would have done the job. But at the time, there really wasn't something like that out there that made sense. So, he extracted a lot of functionality from the original Ignite CLI, rewrote a lot of it, and we released it as Gluegun. And I've been maintaining it since he left, and Gluegun is really cool. You can actually spin up a new CLI. It's pretty meta. You can say gluegun. You can do like npx gluegun new my cli or pizza app or pizza cli if you wanna order pizza on your terminal. And it generates one for you, and then you can go in there and edit commands. And it gives you a whole toolbox of stuff. That's the cool thing about its batteries included.
A lot of these like commands are very very minimal which is fine. But then you have to make a bunch of decisions. And where Gluegun comes with a lot of stuff like, "Hey, here's how you generate things with templates. Here's how you interact with the file system. Here's how you run commands on the terminal. This is how you patch files." There's a really cool patching library that really should be its own thing inside of Gluegun.
Harris Robin Kalash:
Yes.
Jamon Holmgren:
So there's a lot of cool functionality just baked into Gluegun, and definitely something that is probably really overlooked in the JavaScript community. At the same time I understand why Gluegun is something that we haven't had the resources to really devote a lot of time to. I think that people would fall in love with it if they started using it. But, that's just me.
Harris Robin Kalash:
Yeah, it sounds pretty productive. I've tried to mentor, and you're right. It is very bare bones. So--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
So the stack for Bowser, like you said Harris, hasn't really changed. With Flame it won't really change. We are on the latest React Native, React Native 0.63. We're on TypeScript 4.0 or 4.1 which I just updated actually last night before we recorded here. MobX-State-Tree 4. whatever. That's the state management system that we use, and we've talked about it in the past on this podcast. I've been doing a lot of recruiting of a new core team and building that up as the core maintainer of that one. We have React Navigation Five for the navigation routing part of it. We integrate detox just by default. In the past it was like an option. You could choose do you want detox or do you not? Now it's just like, well, Infinite Red never chooses "no detox".
So let's just bake it in. Detox is part of it. There's a thing called Apisauce which is how you make network requests. That is something we'll probably look at in the future because there are some other options for network requests. But Apisauce is a pretty cool one. It's basically a wrapper around Axios. So, if you've used Axios before, Apisauce just makes it cooler, nicer, easier.
Harris Robin Kalash:
One small correction though, we're on MobX 6.1 now.
Jamon Holmgren:
MobX 6. That's right.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
My bad. Yeah.
Harris Robin Kalash:
Because it is now a drop in replacement, so we were able to skip 5. And we didn't need proxy support because 6 works for both proxy and non-proxy environments.
Jamon Holmgren:
My bad. I meant, MobX State Tree 4.0.
Harris Robin Kalash:
Whatever.
Jamon Holmgren:
And then MobX 6. You're right. Exactly, MobX 6. So, talk about that a little bit, Harris, so that I'm not just riding over this podcast instead of my blog.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
But, talk about that MobX State Tree and then also mob x react light and how that kind of fits in.
Harris Robin Kalash:
We were actually on MobX 4 for a while. We couldn't upgrade to 5 for the longest time because MobX 5 required proxy support. So, however, we couldn't upgrade because the Hermes engine didn't--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--support proxy. And that was--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
That was like a whole thing where they were discussing internally testing it, and that took a while. And even though now they're going to potentially make Hermes on by default for both iOS and Android--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--MobX 6 came out and actually works as a drop in replacements where it doesn't require proxy. So I think it detects if there's proxy--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--in the environment. And if there isn't, it just doesn't use that and falls back to whatever was using MobX 6. And it actually worked out as a drop in replacement. I upgraded it. No problems at all in the boilerplate.
Jamon Holmgren:
That's really cool. Yeah, they did some really amazing work with MobX 6.
Harris Robin Kalash:
Yeah. And MobX-State-Tree how they all fit together, so MobX-State-Tree gives you the power of MobX but sort of like I like to think of it as the benefits of like a single source of truth.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
State-Tree's kind of like what you have in Redux.
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
For me, it really gives you the best of both worlds where you get sort of the single source of truth, but you do get like the optimized--
Jamon Holmgren:
Right.
Harris Robin Kalash:
So you do get like the, for example, the computed views which are memorized, right?
Jamon Holmgren:
Yep. Yep.
Harris Robin Kalash:
You get the optimizations out of the box. You don't have to mess around with like the selectors. And even with like Redux selectors, you can't get the level of optimization that you get with MobX out of the box.
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
I actually always use MobX with MobX-State-Tree. So--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--interesting. We were discussing actually in discord about how I saw something in the marketing thread about the name MobX-State-Tree. Like it doesn't really tell you what it does.
Jamon Holmgren:
Yeah. No, you're exactly right. So, Harris is on the MobX-State-Tree core team with me. And we've been having discussions internally cuz our first meeting is actually tomorrow--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--with the core team. One of the things that is a recurring theme throughout MobX-State-Tree documentation is that it describes how it does stuff much more than why and what's cool about it. And everything is like, "No, it's a staple tree that it's kind of written in words that mean that they're accurate. They're not something that really connects with people. We're definitely gonna be putting a lot of effort into making sure that we really can kind of convey what is cool about MobX-State-Tree. Anyway, yeah, that's obviously a whole nother thing. We'll probably be talking about it in the future a lot. Sorry to all the Redux fans. Let me just put this out there.
[Jamon laughs]
Jamon Holmgren:
I know we talk about MobX-State-Tree a lot in this podcast. The fact that two of us are on the core team certainly is part of that, and we're just fans of Infinite Red and otherwise. But, I really don't have anything against Redux from--Certainly, I actually tweeted just recently that I heard from a developer whose CTO decided to use Redux over MobX-State-Tree because of the size of the community and the third-party support and things like that. And I totally get that. That's a reasonable direction to go. And that's actually one of the reasons why I like React Native over Flutter, for example.
Even if Flutter is better in certain ways, the community and the third-party ecosystem means a lot. So, I totally get that line of thought. I'm not trying to brag on Redux. In fact, there's some really cool things that they've been doing lately with the--
Harris Robin Kalash:
Redux toolkit?
Jamon Holmgren:
Yeah, Redux toolkit. Thank you.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
And they've been really addressing a lot feedback from the community. I also think that there's a lot of other state, this is not supposed to be about state management but there's a lot of other state management libraries coming out. And they all have the same flaw. They all have the same problem. Every single one of them. Redux does not. Redux and MobX-State-Tree are the two, and you can throw on Bare Vanilla MobX as well. Those are the only ones that really address the idea of having a centralized store. All the rest of them scatter the state all throughout all of your components and all the problems that come with that. But we can talk about that in the future. Definitely not anti-Redux here, but we've made the decision to go with MobX-State-Tree MST. And that's what Ignite comes with.
Harris Robin Kalash:
One interesting thing I'd like to add is RecoilJS, which is this new internal--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--statement with library at Facebook, actually takes a lot from MobX.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
Yeah, uses also an observable observer pattern.
Jamon Holmgren:
Yep.
Harris Robin Kalash:
And it's a lot more similar to MobX in a lot of the ideas. So, if you wanna--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Yeah, Recoil is interesting. Do they still have that flaw though where you don't have that centralized store--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--in the concept of a data tree? But, yeah, I like that part of the reactive part of Recoil for sure.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
We've been integrating a lot more deeply with Expo. So, that doesn't mean that when you spin up a new Ignite app that it's gonna come like Expo, like for managed Expo workflow. What it does mean is that we have Expo's unimodules support baked into the every app that you spin up even if you're not using Expo. The reason for that is we use Expo third-party modules all the time. So, Expo's team is amazing. Their developers are awesome. Every time that we reach out there we look around and we try to find a third-party library to do something, the Expo version tends to be the best quality. It just really is. And so having unimodules baked in from the start means that we don't have to make the decision the additional friction of, "Well, do we really wanna integrate Expo unimodules?"
Unimodules for those who don't know allows you to run Expo libraries and non Expo projects as well as in Expo itself. So, it unifies the whole thing. You can also make the decision to just be like, "Well, I wanna go with Expo, managed Expo workflow." And we've done a whole project using that. That went really well. That is also built in. So if you pass in -- expo, it will actually use the Expo CLI to generate it. And then it will be a managed Expo project with all of the same goodness that comes with Ignite the boilerplate. That's kind of the rundown of Ignite Flame. So, right now we're recording in early December. This will come out in a couple weeks. So, by that time it should be out. If not, this podcast will give me some some incentive to get it out the door. But, I worked on it a lot yesterday. Got detox tests running well in both Expo and non-Expo. And detox of course being the end to end testing, and we feel that's very, very important high bang for your buck.
So when you spin up a new Ignite app, you already have a test written. You can just run yarn build:e2e and yarn test:e2e. If you are using Expo, you can just say yarn test:e2e. And it'll do the job, so you can start doing your end to end tests right away when you very first start the project. You also have just the course and everything built in. This is just part of the reducing friction, part of it. So, I'm pretty excited about that. Well, we should have this released. And you can start using it at that point. We'll link in the show notes to the introductory blog post that I'm writing about it. Andross and now Ignite 3 are kind of on community support, so we'll review pull requests and merge them, release new versions for people. Andross support, I shouldn't say support, but Andross usage has dropped off pretty significantly in the last, I would say, year. And we're seeing Redux just the interest in doing Redux dropping as well. People are moving to alternatives.
So, that's something that I think will continue. That trend will continue overtime. Redux is still fine. They're doing good work on their side but iust in terms of if you want Infinite Red's opinions. The benefit of Ignite is you're coming to us to learn from the dozens and dozens of projects we do every year and learning from all the pin points we've had, and then we incorporate the fixes right back into the boilerplate. There's little things in the boilerplate right now that you don't even know. Like if you started a new Vanilla React Native app, you're gonna run into it. If you started a new Ignite app, it's all smoothed over for you which is really great.
Harris Robin Kalash:
Yeah. Yeah. It's definitely, like I would say, it's weeks of work then--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--you're right off the bat from translations to debugging to--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah. So--
Jamon Holmgren:
I'd like to also put a shout out here for our community Infinite Red Slack community. If you go to community.infinite.red, there are lots of Ignite users in there. And so if you run into a problem or if you need to have something explained about MobX-State-Tree or TypeScript or anything else React Navigation, there's literally hundreds, maybe thousands of Ignite developers. And they're talking pretty much every day. So, go check that out. That's another benefit of using Ignite. I know this episode has been a lot about the stuff that I'm working on. I guess I'm just really excited about it. I feel like it's gonna help the community. At Infinite Red we're all about community. We give away this stuff for free all the time. It's Gluegun, Apisauce, Ignite, Reactotron, we didn't even talk about that. That's built-in to Ignite Reactotron supporters. All of these different libraries and the community and helping people out, we are probably giving away thousands of hours of free work and help.
I think that this stuff though it comes around. I think a lot of companies would look at this and say, "This is ridiculous. Why are you spending so much time just giving it all away?" But it always comes around. I benefitted so much from the open source community. I love paying it back. It's just so much fun. Okay, let's really quickly jump over to weird bugs. Harris, do you have a weird bug? Cuz if you don't, I do.
[Jamon laughs]
Harris Robin Kalash:
Yeah. I'll let you go first. I'll think about it.
Jamon Holmgren:
Right.
Harris Robin Kalash:
But I'm not sure if I do.
Jamon Holmgren:
All right. So, in the course of doing this Ignite Flame stuff I was working on integrating Expo localization. And it worked fine with Expo. But when I would use it in a bare like Vanilla React Native app, it would give me this weird error which would be like, "Cannot find property locale of undefined." And it was coming from within the Expo localization library. So I went into node modules. And I was looking around. I found the line of code that was airing, and it was literally trying to import something from--there was a local file right next to it. Like import from the same folder or this other file. And it should have the locale. Like I looked at it, it's exporting it. Everything's fine. What the heck?
And I spent, I swear, three hours probably trying to get this to work. One of the things that I did was I commented out the whole file to see if I can get a different error. I did not get a different error. I was like, "What the heck?" Well, I finally figured out that it was telling me it was coming from Expo. Oh, sorry, from localization.ts. But that was just the source map telling me that. It was actually coming from the build folder, not the source folder. So, that's just something to keep in mind when you're debugging. Make sure you're working in the right file.
And so I went to the other one and, yes, I could get it to error differently. But, it was so weird because it just looked like it was coming in as undefined. Like what the heck? Maybe it was a circular dependency or something like that. I don't know. But I added .js to the end of the import statement, like import expo-localization from expo-localization.js instead of just without the .js. And it started working. So weird. There was a workaround Brent Vatne from Expo gave me, I filed an issue with a minimal repro. And Brent within like fifteen minutes gave me a response, "Hey, just use--" I think it was Babel Expo? Expo Babel?
Harris Robin Kalash:
Jest Expo.
Jamon Holmgren:
Jest Expo?
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Jest Expo. And use that as my Babel transform and oh no, my Jest preset. And when I used that, then the problem went away. So I don't know why I at that point had spent too much time on it. And I was just like, "Okay, it works. I'm moving on." But, yeah, that was a very weird bug. Why adding a .js to the end would work and not having .js wouldn't, I don't know. I still don't know.
Harris Robin Kalash:
Yeah, sort of the explanation was that it was missing marks for the Expo modules. But, I still wouldn't understand how the extention relates to that.
Jamon Holmgren:
Yeah. All right, you got anything else?
Harris Robin Kalash:
I did run into a bug actually. I have this Fastlane script that uploads this Android bundle to the Play Store.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
And for the longest time it was working fine. But for some reason, it just stopped working. Like--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--this is like a few days ago, just the script that I usually run to push it off for testing. Now,the error that I got was that, at first it wasn't very obvious to me. But it was just telling me that like, "Okay. Well, the size is too big, the bundle size."
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
So it turns out that, and I don't know if this is a new thing, but APK files are limited to 100 MB--
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
--on Google Play. And all of a sudden, the bundle size went up way over that. And the reason is that the team that's working on this project, so I was just helping them with some CI stuff. But the team that is working on this project added this native module, Zoom actually, Zoom SDK. And it increased the bundle size by so much that it was way over the limit. And I did a bit of research, and there were two options. Basically one of them is to split it into multiple bundles.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
But, I didn't like that idea. There was a more recommended option which was to switch over from APK to this new AAB format from Google. I don't know if you've ever heard of this.
Jamon Holmgren:
Hmm. No.
Harris Robin Kalash:
Yeah. So, that's kind of like what's recommended now. So APKs are kind of like, I mean, they still work. But--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
--AAB is sort of the new format--
Jamon Holmgren:
Okay.
Harris Robin Kalash:
--that Google recommends.
Jamon Holmgren:
That's good.
Harris Robin Kalash:
Yeah. And yeah. So the way to fix that was essentially--And also, yeah. AABs, I should mention, have a higher limit. So, they are not capped at 100.
Jamon Holmgren:
Hmm.
Harris Robin Kalash:
I forget what the exact number is, but I think it's like 150 or 200.
Jamon Holmgren:
Okay.
Harris Robin Kalash:
So, yeah. So essentially the solution to that was instead of bundling it as an APK I have to bundle it as an AAB--
Jamon Holmgren:
Oh.
Harris Robin Kalash:
--and then upload it to Google Play.
Jamon Holmgren:
Okay, wow.
Harris Robin Kalash:
So, that's--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
That's good to know though that there is another option out there. Cuz it can be kind of tough to keep it below that limit sometimes.
Harris Robin Kalash:
Yeah, yeah, yeah. And, yeah, it wasn't too hard to change it. I just have to make sure that like everywhere else in my Fastlane scripts or I don't point to an APK anymore, right?
Jamon Holmgren:
Right.
Harris Robin Kalash:
Yeah, it's not even using an APK anymore.
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah. And it is actually the recommended approach now anyway.
Jamon Holmgren:
Mhm.
Harris Robin Kalash:
But most people still use APKs because they just haven't maybe hit that limit or--
Jamon Holmgren:
Yeah.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Cool, so you can find Harris online on Twitter @nomadic spoon.
Harris Robin Kalash:
Yes.
Jamon Holmgren:
He's less nomadic right now, but he's still known as Nomadic Spoon on Twitter. I'm @jamonholmgren. As always, thanks to our producer and editor Todd Werth, our transcript and release coordinator Jed Bartausky. Bartausky. Okay, I have to tell this story. Jed has worked for me for even prior to this business, I mean, way back to my original business for a very long time. He's also been a family friend for for ages. I started calling him Jed Bartowski because I was watching the TV show Chuck which the protagonist is Chuck Bartowski. And so I just called him Jed Bartowski, and he never corrected me. Not once.
[Jamon and Harris laugh]
Jamon Holmgren:
I found out later when someone said, "Oh yeah, Jed Bartausky." I'm like, "You said that wrong." They said, "No, no. you didn't. No, I didn't."
[Jamon and Harris laugh]
Jamon Holmgren:
And I asked Jed. And yeah, it's Bartausky. So, anyway, that's a whole thing. Todd makes fun of me every time I mispronounce it, but it kind of looks like it should be Bartowski when you look at how it's spelled. But, yeah. So, Jed Bartausky. I think nailed it there. And our social media coordinator Missy Warren, thank you as well. Thanks to our sponsor Infinite Red. Check us out at infinite.red/react-native. A special thanks to you all listening today. Make sure to subscribe on all the major podcasting platforms. React Native Radio is the name. And hey, while you're at it, send one of your favorite episodes over to a friend. If you do that, I would really appreciate it. We are really trying to do a good job with this podcast and hoping to get the word out there about it. See you all next time.
[Music]