Solito with Fernando Rojo

Hello, and welcome to PodRocket.  Today, I'm here with Fernando Rojo,   who's the co-founder and CTO of BeatGig and the  creator of Solito. How are you doing Fernando? Great. Thanks for having me. Excited to have you on the show and hear about  some of the projects you've worked on. I think

in addition to the two I mentioned, we may  even talk about some of the other things   you've worked on before because you've  done a lot in the React Native space. But I guess, what you prefer to talk  about BeatGig first or Solito or how do you want to tell your story and talk  about some of the things you've worked on? Maybe I can introduce how I got into React Native  and BeatGig and how I ended up at Solito. So I first went through YC a few years ago and I was  building my first React Native app then. We were

building a social network. So that was just for an  actual iOS app. And that was my first venture into React Native I'd only used JavaScript before then.  That company ended up not working out. And so then   my co-founder and I, with a few other people  started working on BeatGig and the challenge there was we needed to build a website and an app  and React Native was in this early days of having web support too. And so as we started building  that company, I decided, "I'm going to make a big investment in trying to have a cross platform  stack, keep our engineering team very nimble."

And what I learned over the last year and a half  building that product is that the hardest part of sharing code with an app at a website is  navigation code, because the patterns are very,   very different. Code aside, just the mental model  of using the same code on an app at a website has just a lot of inconsistencies. And so that began  my journey of working on what became Solito and it's something I've been thinking about  for the past year and a half on accident.   I didn't expect it to take so long. And so  recently I released that as its own library.

Awesome. And just for folks who are not as  familiar with mobile dev and mostly a lot of our audiences web dev, what is navigation on  mobile, obviously going between different screens, different parts of the app, but what are some of  the difficulties there? How does it differ from the way you think about doing  navigation in a web app? An easy way to think about it is on web,  you have this really nice API, which is the

address bar at the top of your browser. And  that acts as the majority of your state for   what would be your navigation. In this case,  navigation is just where are you in a page and then you have events that trigger  you to change from one into another.   So web is very flat. You're typically on one  page at a time, you go somewhere else. So let's say you're on the home screen and you go  to search, the home screen completely unmounts   and then you open the search screen. And they're  two distinct components in React terms that are never alive at the same time. Now consider the  alternative in a native app. Imagine you're on

Spotify's iPhone app and at the bottom they  have these tabs and you're on the home screen. And maybe on the home screen, you open an album.  So then inside of the home screen, you get this stack animation that comes in on top, and then you  switch tabs to the search to the right. So now you have two tabs that are both alive and if you go  back to home, it actually is presuming its entire   state. So already there, we see that web has a  very flat simple navigation pattern that is almost

entirely described by the URL, whereas on native  apps, iOS and Android, you have these complex, basically completely undefined states that  have nested states, you preserve the state of the previous screen you were at. There are  many other considerations to have in mind. Got it. And some of that, I do  think, especially in today's age of SPAs on the web, you do have some of  those concerns and you can have state