In this episode, the hosts talk with Graham Mendick about his navigation library, which combines the best features of native navigation with React Native. We also talk about how it’s tough to get mindshare among developers these days for new libraries.
In this episode, the hosts talk with Graham Mendick about his navigation library, which combines the best features of native navigation with React Native. We also talk about how it’s tough to get mindshare among developers these days for new libraries.
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 I’m joined by my co-hosts, Harris and Robin. Adhithi couldn't make it today. And we get to play the fun little game, Where is Harris in The World Today? Harris, where are you at?
Harris Robin Kalash:
I'm still in Vancouver for this week. Next week, I'm going back to Montreal.
Jamon Holmgren:
Okay. All right. Now heads up, by the way, you'll probably be listening to this in the New Year, but there's a little bit of delay because we are not going to be releasing or recording for the next couple of weeks over the Christmas break. Yes, awesome. Well, how are you Harris? Anything new in your life?
Harris Robin Kalash:
I'm good. I'm good. Going for a hike tomorrow. It's going to be raining, but we'll see, so otherwise.
[Harris and Jamon laugh]
Jamon Holmgren:
I swore up and down I was going to keep up my new hiking hobby when we got into winter, and I have made a few hikes just not in the last like three weeks, so I'm slacking off a little bit. But hopefully, I can get back to it. It's definitely raining here.
Robin Heinze:
Did you get cold weather, like rain hiking gear? There's a whole set of gear you need once it's cold and raining.
Jamon Holmgren:
I did after the first time I went [Robin laughs] in the cold and rained and snow. [Jamon laugh] I was up there in like shorts and hiking shoes that just got soaked through and yes, I looked like a complete noob up on the mountain. I didn't actually go all the way up and I was like, “Okay, this is not good.” And I went back. Next time I went up, I had proper gear and I brought my son Cedric with me and we went all the way to the top of SilverStar Mountain, which is an awesome mount here in Southwest Washington. So actually, just saying that makes me want to go up there and I'll do that.
Robin Heinze:
Funny, you take up hiking you're like, "It's hiking! The mountains are free." And then you realize you're hiking in the Pacific Northwest and it gets to be a really expensive hobby really quickly.
Jamon Holmgren:
From Amazon and elsewhere. Yes, that's totally what happens.
[Robin and Jamon laugh]
So, Robin, how are you by the way?
Robin Heinze:
Oh, I'm doing good. We're just preparing for a quiet COVID Christmas.
Jamon Holmgren:
Quiet COVID Christmas. That sounds like the name of an album or something.
Robin Heinze:
Maybe there will be some albums next year. Quiet COVID Christmas, yes.
Jamon Holmgren:
I don't think I'll buy it.
[laugh]
Robin Heinze:
I'll skip that one.
Jamon Holmgren:
Skip that one. With us today, we also have a special guest and his name is Graham Mendick. He's the author of Navigation, which is the data first JavaScript router. He has a PhD, which he told me not to say, from Leeds University. He lives in Redding, just outside of London. He works in London. How are you doing, Graham?
Graham Mendick:
Yes, I'm good. Yes. Thanks for having me on. Really appreciate it.
Jamon Holmgren:
Yes, awesome. Well, what was your PhD in again?
Graham Mendick:
Math, but I did…
Jamon Holmgren:
Math, yes.
Robin Heinze:
And do you use that much now?
Graham Mendick:
No, I don't think I've ever used math since then.
Robin Heinze:
As a fellow math degree holder, I can attest to not using it even a little bit.
Graham Mendick:
Yes.
Jamon Holmgren:
Well, I don't have a math degree and I also don't use it, so I can pretty much say I’m a PhD now, right?
[Jamon and Graham laugh]
Robin Heinze:
Just don't call yourself Dr. Jamon. Come on.
[Jamon laughs]
Jamon Holmgren:
Dr. Jamon… Our topic today is going to be a really cool open-source library by Graham. I'll talk about that in a bit. But I want 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. We've been doing this for a very long time. I think around 40 or 50 years, right? Something like that.
Robin Heinze:
A long time in the JavaScript world. Which is like four, five?
Jamon Holmgren:
Since it came out, basically. And deep roots, we also have deep roots in the React Native community. We are the hosts of Chain React, the conference, and we publish the React Native newsletter. Infinite Red is the best choice, if I may say so myself, for your next React Native app. Hit us up hello@infinite.red. You can email me directly, jamon@infinite.red. If you have complaints, email them to harris@infinite.red.
[Robin and Harris laugh]
You can learn more on our website, infinite.red. Okay, so let's talk about this library. This very interesting library, actually, that is also extremely unGoogleable. The name is Navigation. So, we have React Native Navigation, then we went to React… Oh, wait, no. Let me start over.
Robin Heinze:
Yes. We have React Navigation and React Native Navigation.
Jamon Holmgren:
But there's also React Native Router Flux, React Native Navigation, React Navigation, and Graham's just like, you know what, let's just go with navigation. That right. We're just going to keep it simple here.
[Graham and Jamon laugh]
So, the name is Navigation. We will put a link to it in the show notes so you don't have to try to Google it. Let's talk about this. It's an open-source library. It's obviously about navigation. It’s in the same realm as React Native Navigation and React Navigation. You wouldn't use both on a project, you'd choose one. So, let me ask just to start things off, what was the thinking behind building your own navigation library?
Graham Mendick:
It started out as a router just for react really, and I built that many years ago. I saw a lot of other react routers, they were starting to say that they supported React Native too, so that got me interested in seeing if my navigation router would work on React Native too, and that was a few years ago. Now, it took me like three years really to get it to support React Native. That was a big journey. I had no Native experience before that. I just set out just to see what it could do. And so, on that four-year journey that's taken me to now I've got it working on React Native and it is, like you say, it's a competitor against React Navigation and React Native Navigation. It is hard to separate them from the names like you said.
Robin Heinze:
What were some of the biggest challenges in going from just JavaScript to supporting Native?
Graham Mendick:
Luckily, when I started out, I didn't know the challenges because I think it would have deterred me, but… So, all I was doing at first was just trying to get it to run on React Native, just seeing if it worked. But really, that's when you start to see these big differences between the web and native. And one of the biggest differences is there's a stack, a stack of screens on Native and you don't have that on web. And once you start looking at the stack-- So the first thing that I did was to try and implement that stack in JavaScript. That’s the most normal thing you do. And I think a lot of libraries do that. The early version of React Navigation was just a JavaScript stack before React Native screens came along. Yes, so I implemented the stack first in JavaScript, but then you see, that's not really satisfactory because you start to find out about Native and Native obviously, have their own stack, right? That's where it's implemented on the native side, so you don't compromise on all the animations run on the native side. And what I was doing was, I was implementing JavaScript where all the animations run on the JavaScript side so it doesn't look like a real Native app, and it doesn't feel like a real Native app, and also you get these problems with slowness, the animations are slow. And so that's when I started moving to native and started learning about native. So, I hadn't done any of the native side, left React Native behind and just dived into looking at how to build native apps. So, I learnt the Xcode platform, and I learnt the Android Studio platform and how to build Native apps, and that's when I realized what the Native components were. So, on Xcode, it's a UIViewController and on Android Studio, it's like fragments or activities. And then that's when I started to get into the native side. And so, the next iteration of it was moving all that stuff to the native side and using the native primitives that are part of the navigation libraries.
Jamon Holmgren:
I actually wasn't aware that it started as a web router originally. So, you were using it on the web and obviously you must have a different philosophy on that side. There are no native stacks there. How does it work on the web side of things?
Graham Mendick:
It is very different from any of the other routers you might have encountered with React. That's what I would say. The best way of describing it is page-based routing. So, all the other routers that I've seen are route-based routing. So, if you think of React Router, you specify your route and that's where it renders your pages, but on with the navigation routes, or paste based routing. So, what you get is a flat configuration. So, for each page you've got in your app, you just have one row in your configuration. So, if you've got 10 pages, you've got 10 rows. And what you do is you say the page you want to go to and the data you want to pass, and that's all you say. And then, you let the navigation router to work out all the complexity for you, so it builds your URLs for you. It passes strongly typed data. And that I think is what Next is trying to do, right? Next is trying to build file-based routing, but then it got complicated once they had nested routes, and they started having nested files and subdirectories. But what you want is you want that flat configuration structure. And even when you introduce nested routing, you still want your structure to stay flat. So, the way that I've done it is like you can think of it is, each page has an array of routes. So, if you have to support nested route structure, you still want your configuration flat, but you specify both the top-level route and the nested route at that page level.
Jamon Holmgren:
Interesting. So, you're really basing it on the page itself, and then each route is just a property so to speak, or it's an array, like you said, and you can host that page on a number of different locations?
Graham Mendick:
Yes. The routing, first, we specify the pages and you don't even need to specify any routes, right? What the navigation routes will do is it will generate routes for you, just some dummy routes, just so that you can start navigating. So, you don't even need to specify. You just say I want this page and I want to pass this day and the navigation route will generate everything URLs and everything, then they're messy URLs because it's just generating them to get you going. And then once you finish your pages, and you navigate and you say I actually want this really beautiful URL to look like this, and you don't have to change any code at all. It just updates, everything updates, and all your URLs are just exactly as you want.
Robin Heinze:
It makes a lot of sense to me. It's because the web routing is sort of leftover from when webpages were just pointing to various places in a file structure on a server somewhere, but we have these single-page apps now which are not structured like that. So, it makes sense to just build your app the way it makes sense and then make the URLs fit your app rather than trying to build your app around a nested URL structure that doesn't make sense.
Graham Mendick:
Yes, exactly. And it still supports nested URLs or nested routes. If you want them at the end, you just have to configure both. There's a short syntax for it. So, although I said you configure an array of routes, but it's actually a nicer syntax than that. And it's also much more how native works, right? You don't have this-- You just say the screen you want to go to right in native, you don't have any of that complexity. So, why do you need that complexity on the website as well, I think people just got used to it.
Robin Heinze:
It's just like how it's always worked, and so we've been shoehorning the new single-page apps into the old routing ways.
Graham Mendick:
Yes. I do hope if maybe the guy from Next, Guillermo Rauch, sees it, if he's listening to any of this or something, if he looks at the navigation router, it would fit so perfectly for Next. And I have written something about it and tried to reach out to him, but it's very hard if you're not a celebrity to get any attention. It’s very hard. [Robin and Jamon laugh] It would just be perfect for Next.
Robin Heinze:
If you're listening, reach out to Graham. [Robin laughs]
Jamon Holmgren:
Well, you're a celebrity now that you're on this podcast.
Graham Mendick:
Yes.
Robin Heinze:
Oh, yes.
[Robin, Jamon and Graham laugh]
Robin Heinze:
We are all celebrities. I can't go anywhere anymore.
[Robin, Jamon and Graham laugh]
Jamon Holmgren:
So, going back to the Native side, because obviously this is the React Native podcast, React Native Radio podcast, we want to talk more about the React Native side of things. You went with Native Navigation. And what were the benefits of doing that over just building it in JavaScript?
Graham Mendick:
I'll explain how I think about React Native and then come back to the question. So, React Native promises that you can use react, and you'll end up with a native app that looks and feels exactly the same as if you built it using Xcode. That's the promise of React Native, right? That is using the same native primitive. So, a native primitive is like the widget, so the same button, the same text input as you get if you're building it with a real native app. And so that… And I think that is true, but it's only true if you cover up the edges of your phone. That's the way I see it. It’s like the top and the bottom edges and the right and left edges. Because in the middle of the screen, React Native does give you the same primitives, but it doesn't give you the same primitives. A lot of the primitives live on the edges of the screen, right? And then there are the navigation primitives, right? So, for example, if you're building a native iOS app in Xcode, then when you navigate to a new screen, iOS automatically slides the screen in from the right edge of the screen. And if you're popping the screen off, then you drag from the left edge of the screen. And those things happen automatically, right? Not every iOS developer has to build that into the app. That's just automatic. That's automatic because you're using Xcode. And so, you want the same native primitives that live on the right and the left edge for you when you're building your native app with React Native because that's the promise, right? And that's the same as there's primitives at the bottom of your screen like the tab bars, they're the native primitives at the bottom and the navigation bars and Native Navigation primitive at the top of your screen. So, the more I started learning about React Native and what it's designed to do, then you realize you don't want to write everything in JavaScript. What you want to do is you want to write it in, you want the developer to render it with react components, but you want it to actually render to the native primitive on both the platform so that you don't compromise on user experience.
Robin Heinze:
Yes, that's a really important piece.
Harris Robin Kalash:
Yes. I really hate it when apps remove those UX considerations that we're used to, right? If I can't swipe back using the edge of the screen, that really bugs me.
Robin Heinze:
It breaks the user’s trust in the UX because as an iOS or an Android user, you get used to what the UX conventions are, and it can be really frustrating to try to swipe right to go back because that's just ingrained now, and to have it not work.
Graham Mendick:
And there's a lot more primitives than that so the swipe is so important. But the primitives, like I said, on the tab bar, if it doesn't have the native looking tab bar, it just doesn't look like a native app and if it doesn't have the native header… Because when you're swiping right, there's a lot of header animation that goes on especially on iOS where the title animates in and with large titles as well, as it animates that. There's a lot of stuff going on. And all that is free. If you're just building a native app, it just comes free with UI kit. And similarly, on Android, there's a lot of just native stuff that's free, like the tab bars the way they animate when you click them and stuff like all that all those are native primitives. But React Native doesn't provide them. It doesn't try to provide them. It just tries to find the native primitives for the middle of the screen. And that's where the navigation library should come in and fill in those navigation primitives around the edge of the screen. So that's what the navigation reader tries to do.
Harris Robin Kalash:
I'm curious, just going back to what Jamon asked, but I'm not sure I fully understood the sense like, were you not… When you started navigation, did you look at the current routing solutions, and were you not satisfied? Or did you just want to write your own navigation library because you wanted to experiment?
Graham Mendick:
Yes, I think so I was quite frustrated with my web router not taking off. I was finding it hard to- So, what I do is I do bursts of development, then I try and talk about it and then I get depressed because nobody reads the stuff I write or anything like that, or I can't ever communicate this. That's why I really appreciate this opportunity. So, I was in that state, I’d just done some web development, I was feeling a bit down because I hadn't thought about it. Nobody's read it. So, I thought, okay, I just try something else and try and look at React Native. So, it wasn't like I was thinking I could build the best router for React Native or anything. I just wanted to try React Native at that time. But then, gradually as I, as I learned more about it, I saw the gaps with the existing routing solutions. And remember, this is before even React Native screens. So there really was nothing out there that even tried to do this. I would say React Native Navigation had been some native primitives, but it didn't have the React component interface, right. So, there's two sides to it. You have to have the native primitives so you don't compromise on UX. But you also have to have the right components so you don't compromise on developer experience.
Harris Robin Kalash:
Yes.
Graham Mendick:
So, there was really nothing at the time I started and I still say there's not really that apart for the navigation, but it delivers both those UX and the developer experience.
Jamon Holmgren:
Do you think that React Native itself should have exposed these navigation primitives, in your opinion?
Graham Mendick:
Yes, it's a brilliant question. I think it did. If you go back to the beginning, I got into it later than the beginning. But obviously, I've learned about the history of it as I've been doing it. So, it did have a navigator iOS and it did have a tab bar iOS. And that was in the early days when it was only iOS before the Android stuff came in. And so, it did have them and they were really solid controls. I thought they were really good, looking back at them, and they helped me enormously. When I was writing the tab bar, and when I was writing the navigation, I'd look back at them to help me. So, they were a very successful control. So, I do think it should have done that. But I'm not sure why it went away from that. When Android came in, I didn't try to do that. And also, it just seemed to go down the JavaScript route for navigation very early on, so the navigator iOS got abandoned. And I think then they had several goals. Didn't they like navigate or experimental or stuff like that came enough? I'm not really sure why they abandoned it. Do you know?
Jamon Holmgren:
When you look at something that's been more or less abandoned, or pushed into the React Native community, which I was a part of that process, [Jamon laughs] I was one of the first people on the core team to split out a library, including the one I did was WebView into its own community module. The answer to that is pretty much always because Facebook doesn't need it.
[Robin laughs]
If Facebook doesn't need it, then they don't have as much of an incentive to keep it up to date or build new features that the community needs. And I'm not really blaming the core team of React Native for that, or Facebook or anything. They're doing a great job of releasing amazing features and tools for us to work with as a community. And then we provide that on top of it. But I agree with you, in a perfect world, that router that came with it originally would have been fully developed out into a good solution that the community liked. Just didn't end up happening.
Graham Mendick:
Yes. And I really appreciate that it didn't end up happening and because I think the strength even going to react, right, they never tried to implement a router. And they're very good about not advocating a router, although a React Router has basically become the router that people use, I think. They don't advocate the de facto router. They don't advocate it. They don't push it or anything, which I think is commendable, right?
Jamon Holmgren:
Yes.
Graham Mendick:
And I think that's the same as React Native. I really appreciate that they leave it out.
Jamon Holmgren:
Yes.
Graham Mendick:
But I think they do mention, unfortunately, on the Navigation page, they do recommend the React Navigation, which I've raised, [Jamon laughs] I've tried to be clear of recommending solutions, but I appreciate them saying that.
Jamon Holmgren:
I do think that they get pressure from the other side newbies coming in and saying, “Well, what do I use? How do I just Google and try to make a decision?” This is something where I feel solutions like our React Native Ignite CLI can be helpful because we have our Infinite Red stack, which does evolve does change over time, we use it to spin up new apps ourselves, and so this is the stack we recommend. But it's not an official thing. It's not an official React Native core team thing. I do think the thing that seems to and I'm getting ahead of myself, because I actually want to talk more about the open-source marketing aspect of this. One of the things that has been driving adoption of React Navigation has been its inter-operability with Expo, and the ability to run it on web as well. But yours does that to it on the web side of things. So that's an interesting aspect of this.
Graham Mendick:
Yes, absolutely. It does run on web and I would say it runs on web more successfully than React Navigation. [Jamon laughs] Let me explain why. So, it runs on web, as in, you can use React Native web and then you can get a single codebase and it will work on all three platforms without making really any code change. It will run in Android, it will run on iOS, and it will run on web-- But also, if you just wanted to build a web app, and you didn't want the native side, you can use a navigation route for that. You don't have to build it with React Native. Because what navigation route does, it provides a stack implementation for the web, basically, and you don't have to run React Native web to do that. It's just a stack implementation, right? Just a JavaScript stack. And so, that's the advantage. You get to choose which one you want to do and you can animate it just as you would on Android.
Robin Heinze:
That's interesting. One of our big projects right now is a shared a mobile app and a web app and we're trying to get as much shared code as possible. But where it is diverging the most is at the navigation level because so we have React Router on the web and we have React Navigation on mobile, and we use React Native web pretty extensively for a lot of our shared components. So, now I'd be curious to see if we could reimplement this strategy using navigation router.
Graham Mendick:
Yeah. I've got an example in the codebase that does it from- Yes, it genuinely is a single codebase and it runs on all three platforms with no code changes. You just need a separate entry point for the web, and that’s all, yes. And if you want to diverge, have a different web for the desktop, then you just take out the stack, right? You don't necessarily want the stack running on the desktop, but you can still use the page-based navigation that I was talking about earlier, just which is appropriate for the desktop. And just to go back to that Expo point, I did raise it with them because occasionally, even though I'm not a celebrity, I can get comments back from, you know? [Graham, Robin and Jamon laugh] And I did confirm a little bit text by saying I think it's a bit unfair that they package React Navigation and Expo because... So the navigation router doesn't need any dependencies. It doesn't need any installation steps. If they package the navigation really inside Expo, people could then choose which one they wanted to use, or at least make it open, but I can understand. It's a different thing.
Jamon Holmgren:
Expo is a little different. Obviously, the way that they operate, they have to pre-package the native side of things into their binary, into their codebase, and you're stuck with what you get. If you don't want something, you still get it. If you do want something, you don't get it. That is, I think changing. I think that is going to change in the future. I think they have some ways that you can maybe write some custom code and include it in an Expo even a managed Expo app like one that's actually built by their servers.
Robin Heinze:
Without having to eject-
Jamon Holmgren:
Yeah, without having to eject, exactly. So, they're doing some interesting things. And maybe in the future, Graham, you'll be able to have some interoperability with Expo apps. I think that'd be pretty cool.
Graham Mendick:
That would be cool.
Jamon Holmgren:
Let's talk about the open-source marketing aspect of this, because you've mentioned this a few times that it's been hard to get adoption, and I can identify with this. Believe it or not, I wrote a navigation library in the past.
Robin Heinze:
Not for React Native, but-
Jamon Holmgren:
It was not for React Native. I wrote it for a platform called or toolchain called RubyMotion. I was a Ruby developer for many years. And it came out in around I want to say 2012, I think was when that came out. It allowed you to write, this was before the Swift days. So, everybody was using Objective C to build iOS apps. Now basically, you could use Ruby, and it would compile down using the Objective C runtime into native code. It would actually, you were just writing, basically, you were writing Objective C, but in Ruby. The big thing there was we started using it, and I quickly found out like, “Okay, I don't want to have to build all of my own view controllers and navigation from scratch every single time I build an app. Let's build an abstraction over the top of it. I'm a Rails developer, I like things to be clean and nice.” So, I built this thing and I called it ProMotion, which I thought was a clever play on the name of RubyMotion. And you would promote a screen onto the stand or whatever, I had some explanation for this. And it was as, or even worse, Googleable your library navigation. [Jamon and Graham laugh] So, I totally get that.
Robin Heinze:
Try googling the word promotion.
Jamon Holmgren:
Promotion, exactly. Promotion is a marketing term. It's-
Robin Heinze:
How to get your next promotion? [Graham, Jamon and Harris laugh] Here are five tips.
Jamon Holmgren:
Just download your next promotion from GitHub. [Robin laughs] So, I have it right there. So, I was a little frustrated because I put it out there. It was one of my first open-source projects, and I thought, “Hey, you just put it on GitHub, people are going to find it and use it. It's really cool.” And I was getting nothing. And there was another one out there that wasn't as good that was getting some adoption. I think I was in your shoes in a lot of ways, and I ended up emailing the guy who made RubyMotion and said, “Hey, I've been having trouble marketing this. I think it's pretty cool.” And he's like, “Okay. Well, just write a blog post and we'll put it on our RubyMotion blog as a guest post.” Because he was looking for content anyway. And so, I did that, and it hit the front page of Hacker News [Jamon laughs] and it just went off. And yes, I got like 1,200 stars, even though back in those days, that was actually quite a bit. Nowadays, 1,200 is okay, but it's not crazy. But back in those days, that was a big deal. And then I got invited to speak at the conference, their second conference in San Francisco and that led to all kinds of other opportunities, including Infinite Red. Yes. So that was really cool. It was like open source was the open world. And it was in Navigation library. It literally was navigating using the native primitives. It was all iOS to start, and then I did build an Android version later, and then we integrated it into a larger thing that was Rails, so I get what you mean. And it was just being persistent about it and not being afraid to send an email to people and getting in the right place at the right time that led to that.
And also, there was a need. There was a need for that. I do think there's aspects of it where people are like, “Well, it might be better, but the cost of change is also there and not just the cost of change, but also the ecosystem, the documentation, the StackOverflow questions, whatnot.” Building an open-source community is a lot of work. I've done it many times. I'm in the process of doing it again with MobX state tree right now, in terms of rebuilding that, so I definitely hear what you're saying. Having a memorable name can be helpful for sure. So that might be something you struggle with a little bit with the name just Navigation. You might want to have something that's a little more memorable for that, and naming things is hard as we all know.
Graham Mendick:
Yeah.
[Jamon, Graham, and Harris laugh]
Jamon Holmgren:
But that can be something that just- Because people get confused between React Native Navigation and React Navigation already.
Graham Mendick:
Yeah, I still do.
Jamon Holmgren:
And so, breaking free of that. [Graham, Robin and Harris laugh]
Robin Heinze:
Yeah, I know. I couldn’t tell you.
Jamon Holmgren:
Someone was looking and I don't remember who. Was it you or Harris who suggested NavaTron?
Harris Robin Kalash:
No, no, that was not me. [Graham, Robin and Harris laugh]
Jamon Holmgren:
That was not you? Okay.
Jamon Holmgren:
So we'll say NavaTron. I don't know, maybe it's already out there. I haven't even Googled it. But that can be an aspect of this. I think that consistently putting out content about it in writing blog posts and doing video screencasts of, "Hey, this is how you do this with my navigation library. This is how you do it." You give talks. Talks are amazing for this. Conference talks, of course, in 2020 doesn't work so well, I know. But, as we move into the new year hopefully there'll be some conferences opening up and you can do virtual conferences as well.
Robin Heinze:
We should have Graham do a guest post on Redshift.
Jamon Holmgren:
Oh, that's not a bad idea.
Graham Mendick:
I'll be well up for that.
Jamon Holmgren:
We have a pretty good audience over there, a lot of React Native developers.
Graham Mendick:
Nice. Thanks for those tips. Yeah, I'm not good at motion side. Definitely not, but I have tried a lot of things. So, like one year I just applied to every conference. Every React conference I just applied. I wrote what I thought was really good abstract. It was about explaining about the stack on the web, so I was saying how you can get a Native app basically running on the web. That's what everybody wants to do, isn't it? PWA's Progressive Web Apps sort of thing. And nobody's really done that, I thought. So I just applied to every React conference, but I got rejected from every one. And I could see none of them really looked at the projects as well but you can see the traffic. And so I could see nobody was really even looking at it. So I just get a feeling like it's kind of if you've got a new idea, you have to be a celebrity. That's my fear. I know you managed it, and that's amazing. But, I think if you're talking like somebody else's idea, you don't have to be a celebrity for that. You'll get onto conferences with somebody else's idea. But if it's a new idea, I just feel you have to be a bit, famous for that. But, I don't know.
Jamon Holmgren:
It is interesting. I know as a conference organizer myself, we try to give voices to people who don't have big audiences and whatnot. I think there's an element of like, "Well, if we bring in someone with 20,000 Twitter followers, then they'll bring in ticket sales." And that's kind of this sort of overly maybe capitalistic way to look at it. We try not to do that so much. We have a pretty good voice in the developer community that we've worked really hard to get I would say putting out a lot of content over the years. But I'll tell you, I had like 2800 followers on Twitter prior to going on a big one year speaking tour of wherever I possibly could. And I grew to like 10,000 in that year. So, speaking definitely helps. And it doesn't take too many to to get there. You can start with meetups. Meetups always need people. They're really, really hungry for content. And then you can move forward from there. I definitely won't say that there wasn't an element of luck, and certainly the connections that I had made big difference. Being connected to Gant Laborde, I'll just say, is a big deal when you want to be a speaker.
[Robin laughs]
Jamon Holmgren:
Gant knows everybody, and everybody loves Gant. And Gant is one of my business partners. So, that's a pretty big advantage. Definitely don't give up. There are speaking opportunities out there. And--
Robin Heinze:
It's like being an actor, and you hear actors talk about like eating ramen for 10 years and then the break--
[Jamon and Graham laugh]
Jamon Holmgren:
Overnight success.
Robin Heinze:
Overnight, yeah. The break comes along and--
Jamon Holmgren:
You also have to be careful what you wish for.
[Robin laughs]
Jamon Holmgren:
Because when you become more popular, people start nitpicking everything. You have to grow a thick skin, and it's not easy because you're still the same person you were before you get a bunch of Twitter followers.
Graham Mendick:
Yeah, I totally agree with that. I don't think I'd be able to cope with it, but I just want to see what would happen.
[Jamon laughs]
Graham Mendick:
Also, I do appreciate the meetup thing because I do get into Meetup. So, I applied for a couple of meetups. And they do, they just want people to speak then. And so I've gotten to that.
Jamon Holmgren:
Yeah.
Graham Mendick:
But I just want like most of the audience's recruiters. So--
[Jamon, Robin, and Harris laugh]
Graham Mendick:
--it's quite hard to get them.
Robin Heinze:
It's true. It's true. Which is maybe why no one goes to meetups. Is that why no one goes to meetups anywhere cuz they know the audience are all recruiters?
Jamon Holmgren:
Can I just take a moment and talk about how absurd this is that you would not want to go somewhere because there are tons of people offering you jobs?
[Robin and Harris laugh]
Jamon Holmgren:
We're such a privileged group of--
Robin Heinze:
People who have jobs.
Jamon Holmgren:
--in this industry.
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
Yeah.
Robin Heinze:
Yeah.
Graham Mendick:
Well, talking about jobs, so I take like career breaks sometimes to work on the navigation router, right? Cuz it's very hard to work on it when you're working, right? And I--
Robin Heinze:
Oh yeah.
Jamon Holmgren:
Hmm.
Graham Mendick:
I'm a bit older, so I saved up some money. I lived off my savings for a bit, and I just did that for when I was converting it to React Native, right? I took a couple years off. And so at the end of that I was looking for work. And I applied for React Native jobs cuz I just been doing that. I learned Objective-C. I learnt the platforms and all that, but I couldn't get React Native job cuz I didn't have any commercial experience. So I just couldn't get anywhere, so I just had to get a React job in the end.
Robin Heinze:
Do what I did and get a job for Elixir. And then have your boss telling you to learn React Native on the job.
Jamon Holmgren:
We used Elixir, not intentionally, but we used Elixir to to bring in Robin and also Brian.
Robin Heinze:
Funny thing is I didn't know Elixir either. And I still got it.
[Jamon laughs]
Robin Heinze:
You still hired me. I don't know why.
Jamon Holmgren:
Well, you did Ruby. Close enough.
Robin Heinze:
True. You hired me for Ruby, and I did that for maybe two weeks.
Jamon Holmgren:
Yeah. Yeah, we used to do a lot of Ruby. We still do a fair amount of Ruby, but it's mainly like a individual team that's doing that right now.
Harris Robin Kalash:
Maybe something you could consider is hiring a marketing consultant because sometimes they can really help you like look at the messaging sort of like if I look at the ReadMe of your repo, I guess the first thing that comes off to me is that it doesn't really tell me the why, right? So, you're telling me that it's a data first router and that other libraries have it backwards. And when I listen to you talk here, I can understand that. But if I look at your ReadMe, it doesn't actually explain to me why. Then there's always this like sort of golden use case, right? I think it should always be in the ReadMe front and center. Like what is like 10 times easier using my library than other libraries and put that front and center. I think those two things will help a lot.
Jamon Holmgren:
Yeah.
Graham Mendick:
Nice. Thanks very much.
[Robin laughs]
Jamon Holmgren:
That's fantastic advice. Harris will send you an invoice.
Robin Heinze:
Graham did not know that when he signed up to come on this podcast, that it was--
[Jamon and Robin laugh]
Jamon Holmgren:
ReadMe’s are very hard to do, especially if you're the one who--
Harris Robin Kalash:
Yeah.
Jamon Holmgren:
--implemented the library.
Robin Heinze:
Oh yeah.
Jamon Holmgren:
What's interesting is--
Robin Heinze:
It's so hard.
Jamon Holmgren:
--for ProMotion, I kind of did a ReadMe driven development. I actually wrote the ReadMe that I'd want to see. And then I made a library that conformed to that. Now, of course, some things didn't work technically. But, it was sort of backwards from what you would normally do where you would implement something and then try to describe it in the ReadMe. And I really kind of did it more the opposite where I wrote out the API that I wanted and kind of tried to show the cool use case. If you actually go to the ProMotion ReadMe, you can immediately see like it says iPhone apps Ruby-style. It's like bringing Ruby sensibilities to that world, and then it shows some code that looks very pleasing like, "Okay, here are your screens." And you can just type in "onload open route screen". So those are types of things I really think ReadMes are very important, even more important in my opinion than a homepage. I actually think ReadMes are critical. That's where developers like to look.
Graham Mendick:
Right. I think I kind of abandoned my homepage. Once I started writing the documentation, I just never really updated it. So, that's great. Great.
Jamon Holmgren:
Yeah.
Graham Mendick:
Those tips, thanks.
Jamon Holmgren:
Yeah. Yeah, absolutely. So one thing I wanted to check in with you on, I saw a pull request by someone in the community that added detox testing to your library. So, how does that work now with with your library as detox kind of a first class citizen at this point?
Graham Mendick:
Yeah. Like I don't get like a lot of pull requests, but everyone like I really appreciate. And that was an amazing one, so--
Jamon Holmgren:
Yeah.
Graham Mendick:
But anybody that wants to send me a pull request, much appreciate it. But, yeah, that was from Alex Lockhart. Basically, he was adding test IDs, everything that's clickable, everything. So like the tabs, the buttons in the navigation bar, all those kind of things just making sure that they all had test IDs on them and, yeah, and that they are recognizable too and to detox and other, like Appium, I think as well.
Jamon Holmgren:
Yeah, I think that's important. You have to have that deep integration in order to for people to really want to use your library. If we were to use the library and it didn't work with detox, that'd kind of be a big blocker. So, it's really cool to see that that's landed in your navigation library.
Graham Mendick:
Yeah, and it's a lot of work. These pull requests are working, and he just did it all himself mostly. We had a good chat about it all, but like I really appreciated all that.
Jamon Holmgren:
Yeah.
Graham Mendick:
And like I would say like even I don't get that many pull requests. I've got the biggest team of people working on the project, right? The reason I'll explain why. Because I'm using the Native primitives, right? So, I'm using all the Native primitives for my iOS and Native primitives from Android Studio. I think of the UI kit as working on the navigation route of the team--
[Jamon, Robin, and Harris laugh]
Graham Mendick:
--and I think of the Android Studio tooltip as working on my navigation route. Because anytime they--
Jamon Holmgren:
That' s fair.
Graham Mendick:
--anytime they improve those controls right m y navigation will automatically get those changes. Like they--
Jamon Holmgren:
They are for free?
Graham Mendick:
Yeah, for free. They are virtually free. I have to add a prop or something like that.
Jamon Holmgren:
Sure.
Graham Mendick:
So, one example is like badges on tap bars, right? So in UI kit the tab bar controller has already got a badge. But the one on Android, there's two tab bars on Android actually. There's the bottom navigation view that goes on the bottom, and then there's a toolbar layout the swiping one that goes on the top of the screen. And they didn't have badges then Android or a new version 1.1 of the material library. And they added badges to both the bottom navigation bar and to the toolbar layout. So my library automatically gets badges on Android, right? And then they look just like the same Native badges that you'd get if you're building a Native app, so they're all working for my library.
Jamon Holmgren:
That's awesome.
Graham Mendick:
Yeah.
Jamon Holmgren:
I love that attitude. That's fantastic. And I agree because ProMotion had the same thing if something new would come out. Maybe it would break ProMotion for one day while I fixed it. And then I put it out there, and we'd have it. And that was pretty awesome. I have a couple more questions for you. One is around TypeScript and interoperability. Do you support TypeScript as a first class citizen on the library?
Graham Mendick:
Yeah, like it's all written in TypeScript as well. Like--
Jamon Holmgren:
Hmm.
Graham Mendick:
--and so all the examples are in there written in JavaScript just to make them more accessible. But like all the actual code, that's all written in TypeScript. So, generating the DTS is like the easier sheet that is part of the library. I used to actually have it separate and put it on DefinitelyTyped. And that was just so I could understand what the rules were around the touchscreen because if you put a pull request in DefinitelyTyped, they're all like correct or you're typing is right.
[Harris and Robin laugh]
Graham Mendick:
And they tell you how to write it properly.
Jamon Holmgren:
Yeah.
Graham Mendick:
So, I learned a lot by doing it on DefinitelyTyped. And now I brought them inside to make sure it's--
Robin Heinze:
That's a good pro tip.
Harris Robin Kalash:
Exactly. Yeah, great.
Jamon Holmgren:
No kidding.
Robin Heinze:
Level up your TypeScript game.
Graham Mendick:
Exactly.
Jamon Holmgren:
My second question has to do with deep linking. This is one that we hit regularity with our apps. Notification comes in, and we need to link to some screen that's not just your home screen. And you have sort of like a dedicated API to handle that, how would you handle deep linking in your case?
Graham Mendick:
Yeah. So what you're saying is you want to go to something deep in the stack, right? So you want to open a screen--
Jamon Holmgren:
Right.
Graham Mendick:
three deep, four deep. Yeah. So, what it says is it's in your control. So the building the stack is in your control. It's not something so the navigation where it doesn't own the deep link, it doesn't have any navigation. That's all up to you, so you just listen to the deep link just like you would if you were building with React Native. You listen to it. And then to build the stack, you just instead of navigating cuz what you don't want to do, say, the link is four screens deep, you don't want a open screen a an open screen be an open screen be--
Robin Heinze:
Yeah.
Graham Mendick:
You want to go straight to screen four, and you don't want those three behind it to be rendered. You don't want them to render until you navigate back to it. So, navigation route has this concept of fluent navigation. That's where you sort of do a lot of navigations in one go. So, it's the same as navigating except it's a fluent API. So instead of going navigate to screen one, navigate to screen two, you sort of just do all the navigations in one call like chain them. And then you build it. That gives you a URL in return. And then you just say, "Navigate to that URL." And that URL basically contains those four screens. And it will jump straight to that fourth one. It won't render the others. As soon as you start popping back that fourth one, it will render that third one.
Jamon Holmgren:
Okay, so you still get all the benefits. You just don't have to wait for all that to render. And, yeah, that's very cool.
Robin Heinze:
It's very cool.
Jamon Holmgren:
I like how that's handled.
Graham Mendick:
Yeah, and fluid navigation's convenient for anything. So, it's a lot of use cases for it. And that's the obvious use case. But, say you've got four screens deep but you want to change the screens in the history and the stack for some reason.
Jamon Holmgren:
Mhm.
Graham Mendick:
And people want to do that sometimes. You can just do it. You can just fluently navigate. So say you're on ABCD and you want to change it to ABED, you just fluently navigate to that link. And it will change.
Harris Robin Kalash:
Right.
Graham Mendick:
And it still won't render that screen behind it until you navigate back to it, it will just be waiting there.
Jamon Holmgren:
That's really cool. And I suppose would that be also helpful for persisting your navigation state between loads of your app. We know if the app was swiped away and then you come back to the app, you don't want to necessarily start at the home screen. Maybe you were at a spot and you want to just pull that in from your async storage. Is that another use case of the fluent API?
Graham Mendick:
Yeah, definitely. Yeah, that's a really good use case. Basically the state of the stack is just a single URL. And so, it's actually a--
Robin Heinze:
That's really cool.
Jamon Holmgren:
That's amazing.
Graham Mendick:
It's actually a URL of URLs if you want to think about it cuz every screen is a URL, and the overall stack is just the URL with each URL in it. That's how it's done. So whenever it navigates, you just listen to that event and save that URL somewhere. And then you navigate to that web starter if you want it to.
Jamon Holmgren:
We should get you to help us with maybe like a Reactotron plugin so that Reactotron and your navigation library can work, play well together. Maybe Reactotron could allow you to navigate around in your app from Reactotron or something like that. I love those types of integrations between tools.
Graham Mendick:
Yeah. Even I was thinking at one stage, of building the flipper integration where you could like control the app and do that. And the obvious one is like a Redux integration, but never did anything.
Jamon Holmgren:
Yeah, true.
Graham Mendick:
Yeah, that's right. Yeah.
Jamon Holmgren:
Very cool. Well, thanks so much, Graham. I know there's much more you can say about the library. There's a lot more here. But if people want to learn more about your navigation library, where can they go to find out about it?
Graham Mendick:
I guess the best place is the repository, and we'll put a link to that in the notes.
Jamon Holmgren:
We will. Yeah.
Graham Mendick:
And you just asked me a question on there. I love getting questions. Like even if you feel like it's a bad question or anything, I just love answering questions. So, ask me that. But if you don't feel like you want to ask a question on the repository cuz I know some people don't want to do that, you can message me on Twitter as well. I don't tweet much, but I'll always answer. And again, you can just message me if you don't want to do a public message.
Jamon Holmgren:
And go ahead and give your Twitter handle.
Graham Mendick:
Yeah, it's just my name. So, it's Graham Mendick.
Jamon Holmgren:
Perfect, and we'll put a link to that in the show notes as well.
Graham Mendick:
Nice one. Thanks.
Jamon Holmgren:
All right. Thanks a lot, Graham. That was awesome. Let's move into the weird bugs part of the show. Who here has a weird bug that they want to talk about?
Robin Heinze:
Well, it's not really a weird bug. But it's a hopefully relatable developer experience of spending a couple of days banging your head against something, and then realizing it was something really simple. I spent a couple of days trying to figure out why my React build was not optimized for production. We were theoretically minifying it, doing all the things. But the the ops team was like this, "The bundle is really huge. The performance is really bad." And I couldn't figure out why. And it took two days later I realized that we were outputting it to a different file name than the one that they were expecting. And by switching to the correct file name, they saved about five megabytes maybe--
[Jamon laughs]
Robin Heinze:
--of bundle size. So--
Jamon Holmgren:
[laugh] Wasn't it that they were using index.js--
Robin Heinze:
Yeah, they were pointing to index.js. And we were minifying to index.min.js. So, that was a fun discovery.
[laughing]
Jamon Holmgren:
Oh, yes. Well, I can sort of relate in a semi similar way where we were trying to, actually on that same project, trying to get it to work on Internet Explorer 11 and having a lot of problems. And then realizing that the client had told us two months prior we don't need to support Internet Explorer 11.
[Robin and Graham laugh]
Jamon Holmgren:
We spent like a day and a half on that. Wait. Okay. Whoops. Well, at least we don't have to do that. It was gonna be a real pain, but they looked at their numbers, the metrics, and there's just not a lot of Internet Explorer 11.
Robin Heinze:
Always double check your assumptions.
Jamon Holmgren:
Always.
Robin Heinze:
Anyway.
Jamon Holmgren:
Cool. So where can people find you, Harris? What's your new Twitter handle?
Harris Robin Kalash:
It's Nomadic Spoon. n o m a d s p o o n. I'm sorry. I--
Jamon Holmgren:
I think you forgot the i c.
Harris Robin Kalash:
I think I forgot the i c. Yeah.
[Harris and Jamon laugh]
Robin Heinze:
Nomads spoon?
Harris Robin Kalash:
Nomads spoon.
Jamon Holmgren:
Nomads spoon.
Robin Heinze:
Try again. Try again.
Jamon Holmgren:
That's someone else.
Harris Robin Kalash:
Yeah, do not follow Nomad Spoon.
[Jamon and Harris laugh]
Jamon Holmgren:
You might get better content.
[Harris laughs]
Jamon Holmgren:
Robin, where can people find you?
Robin Heinze:
I'm @robin_heinze with an E at the end.
Jamon Holmgren:
And I'm Jamon @jamonholmgren on Twitter. You can find Graham @grahammendick on Twitter. As always, thanks to our producer and editor Todd Werth, our transcript and release coordinator Jed Bartowski, and our social media coordinator Missy Warren. Thanks to our sponsor Infinite Red. Check them out at infinite.red/react-native. A special thanks to all of you listening today. Make sure to subscribe if you haven't. We're on all of the major podcasting platforms, and go tell a friend. If you like what you hear, we want to get the word out about our new podcasts that we're trying to do a good job on. See you all next time.
Robin Heinze:
Bye.
Harris Robin Kalash:
Bye.
Graham Mendick:
Bye.