In this episode, Mazen and Jon Major are joined by Fernando Rojo, Co-Founder and CTO at BeatGig, to discuss the ins and outs of working with React Native Web on Next.js.
In this episode, Mazen and Jon Major are joined by Fernando Rojo, Co-Founder and CTO at BeatGig, to discuss the ins and outs of working with React Native Web on Next.js.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast, brought to you by the Metaverse, experience your racist uncle in 3D-VR episode. Episode 224, React Native web on Next.js with Fernando Rojo.
Jon Major Condon:
So, Mazen, how was teaching your React Native course for Gaza Sky Geeks?
Mazen Chami:
Actually went really well. Very surprised by the high level they had and how quick they grasped this new topic of React Native. They're usually coming through a crash course on React and JavaScript specifically, and most of them decided to push themselves and do React Native and TypeScript, and they killed it. The final projects were great, I tweeted about it. Feel free to go to my Twitter and check it out. Actually, something that was pretty cool out of all this, two of them are in the process of interviewing for React Native jobs. So I'd like to say my little crash course helped them get that, but it was all their abilities and their eagerness to learn. So if you're out there looking for contractors, think they're really good at what they do.
Jon Major Condon:
That's awesome. Taking a React Native crash course, going from zero to being hired at a company.
Mazen Chami:
And this was my first thing, having like a technical talk in Arabic, fully Arabic.
Jon Major Condon:
That's right. How did that go? Did you stumble a bit on that?
Mazen Chami:
Not really. They have their own dialect that's different than mine, so I think that was... There were some parts where I had to stop and give slang words so that we can get the message across, but it went pretty well. I surprised myself.
Jon Major Condon:
All right. Well, things have changed a little bit today. Our friendly CTO and host of the podcast is out sick. So I am Jon major, I'm going to be your host for today. I'm going to try to make up for that loss. But I am a software engineer here at Infinite Red and also the editor in chief of the React Native Newsletter. I am joined by my bright co-host, Mazen, as well as our guest Fernando Rojo, who I will introduce in just a moment. Mazen lives in Durham, North Carolina, he's a former pro soccer player and coach, and he's a senior React Native engineer here also at Infinite Red. What is up, Mazen?
Mazen Chami:
Not much. I like the bright today. Maybe it's the background, you can see behind me.
Jon Major Condon:
So Fernando Rojo is the co-founder and CTO at BeatGig, a marketplace for booking artists. He graduated from UPenn in 2019 and was part of a Y Combinator's winter 19 batch. His first startup PATOS Shoes partnered with J.Crew and was featured in Forbes, NBC, and Huffington post. Today, Fernando maintains a number of React Native libraries, including Moti and Dripsy. I have no idea how you have all that time. But Fernando, how's it going?
Fernando Rojo:
Good. It's great to be here.
Jon Major Condon:
Awesome. All right. Well, this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the US and Canada. If you're looking for React Native expertise, you can learn more on our website at infinite.red/react-native. Don't forget to mention that you heard about us through the React Native Radio Podcast. Also imagine working with this amazing team. So feel free to go to careers.infinite-red. All right. So let's get into today's topic. Mazen, you want to kick us off?
Mazen Chami:
Yeah. So, today's topic is React Native web on Next.js. Fernando, tell us a little bit about your story. I hear it's an interesting one. Where did you grow up? Jon Major just introduced you went to UPenn and started PATOS there. Tell us your story.
Fernando Rojo:
I grew up in Ann Arbor, Michigan. My family's from Argentina, but I was born in Ann Arbor. I was basically obsessed with computers my whole life. I would always get in trouble installing viruses and using the little softwares and building little things. I had a YouTube channel when I was, I think 11, that was dedicated to doing things that were tricky. So I used, I think it was called FrontPage, the Microsoft software for building front ends, and I had videos showing how to use that, other ones, like how to download YouTube videos onto your iPod. And that really got me obsessed with the internet. I would have a few hundred people just commenting on my squeaky voice and saying, "Thanks for this little tip."
Mazen Chami:
That's awesome.
Fernando Rojo:
And I think there I just got really excited. I lived a few blocks away from the Michigan football stadium growing up. Every game there'd just be crazy crowds of people. One day I realized that while all the other kids in the block were selling lemonade and I was doing that too, there was so much traffic on our little street. I realized no one could find parking. So I asked my parents, if I could park someone in our driveway. They paid me $10, and that was pretty exciting. So my parents had a rule and that you can only allow two cars to park in the driveway. But after a few weeks, they just stopped watching me because it seemed like I had things under wraps and Michigan was playing Ohio state, huge game. And I tripled our price and I parked nine cars that weekend and suddenly it was something like a seven-year-old making 250 bucks on a Saturday, and-
Jon Major Condon:
Oh, my goodness.
Fernando Rojo:
I think at that point I realized I wanted to be an entrepreneur. So I got really into just finding ways to bring in little money and doing things on the internet. That was just always my passion. So, when I got to Penn, my first semester, freshman year, I was visiting family in Argentina and I'm walking through an artisan fair and I come across this guy selling some shoes that I thought were just so cool and they seem really high quality. So I bought 50 pairs, took them home with the ambition to start a shoe company, and that took my time up for the next few years.
Mazen Chami:
That's awesome. And so, it's an e-commerce website built on Shopify, is that correct?
Fernando Rojo:
Yeah, that's right.
Mazen Chami:
Cool. And has it evolved since you started it in college, or is it still same old, going strong?
Fernando Rojo:
Quite a bit. Yeah, it actually started out being just women's flats. That was the original V1 shoe that I found on the street with these incredible Latin American patterns on them, very bright patterns. I quickly realized a few things. One, Argentina was not the ideal place to import from. So I eventually actually found another set of local artisans in Peru to work with. And the shoe changed a lot. So I actually designed a new product from scratch, working with these new artisans in Peru, shoes that I could actually wear, men's shoes, and new women's sneakers. So the product evolved a lot over time and we ended up launching a Kickstarter in 2016. So I took a semester off from college, launched a Kickstarter there.
Fernando Rojo:
We raised around $60,000 that month. That really got the business moving more, and eventually I wanted to do more complicated things on my Shopify website. And at that point, I started tinkering with the template. So I'm in these Shopify DotLiquid files, trying to figure out what Dots SCSS is and what DOThtml means. I'd seen these things a little bit as a kid. I had had a HTML website when I was a kid called Cool TV, that was pirated shows and movies. I did get that shut down. But I'd seen some CSS before, but now I was really trying to make edits to my website. And that's when I started getting more and more into code.
Mazen Chami:
That's awesome.
Jon Major Condon:
Did that come out in 2019, you said?
Fernando Rojo:
I launched the PATOS brand on Kickstarter in 2016.
Jon Major Condon:
2016, Okay.
Fernando Rojo:
And yeah, I think that was... I want to say September or August of 2016. Because I remember I took my junior fall off and worked on that for a few years full time. Then in 2019, my co-founder and I have another business called Basement, went through Y Combinator. So we were trying to launch a social network that limited you to your 20 closest friends, called Basement. We went through YC, we raised some money for that crew for a while. That's my first React Native app I ever built. Eventually it didn't work out, tried a few other things and ended up working on BeatGig full time.
Mazen Chami:
What is BeatGig? Can you tell us about it?
Fernando Rojo:
BeatGig is a marketplace for booking artists for live music performances. You can think of it like Airbnb for live music. We have a few thousand artists, you can open it, browse all their prices. It's the only place where you can actually browse the price of any artist in general and see how much they cost a book. We started out targeting only fraternities and sororities across the country, and about 60% of the country's sorority and fraternity concerts now go through our platform. After COVID, around February of 2021, nearing the end of it, we got into the bar and nightclub market and we've since been growing a lot in that market. So our focus has shifted from fraternities and sororities alone to also getting into the venue space and more B2B markets.
Jon Major Condon:
Well, that's awesome. Quick aside, how is the legal process of booking these artists? I guess, finding these artists and being like, "Hey, do you want to join BeatGig as an artist?"
Fernando Rojo:
That is actually one of the big things that BeatGig abstracts for our users. If you want to book an artist, the legal issues are pretty annoying. First of all, you need to just figure out terms, in general, with an agent. What are you supposed to book? No one knows these kinds of things. You need a writer, all these just weird things. We, at this point, have this just down to such a system. So we have two tiers of artists. We have more local bands, people who might not be part of the big agency but just literally open the app, sign up for BeatGig and get booked. So this is a pretty big user base now of artists who run their entire careers through our platform and get booked at bars and nightclubs.
Fernando Rojo:
And then we have the other sect of artists, which is the DJ Khaleds the, Keshas, the artists who come from a major talent agency and sign up. In those cases we actually have deals with all the talent agencies in LA, and they basically onboard each one of their artists through the agency. When you book an artist through BeatGig, you don't have to deal with contracts, all these complicated things our platform actually does. And for large enough shows, we have dedicated people that are part of your booking that will go back and forth with the agent.
Jon Major Condon:
Awesome. So then we got connected, I believe, through Jamon, on Twitter. He asked a question, "Has anyone done Expo web with Next.js and you responded yes, I believe. And that's with BeatGig, correct?
Fernando Rojo:
Yeah, that's right. BeatGig is built with expo for the iPhone app and Next.js for the website.
Jon Major Condon:
So, what was the reasoning of deciding the tech stack? I see there's a BeatGig app on App Store, of some kind. I assume there's probably shared components.
Fernando Rojo:
We do share a good amount of code across the website and app. I actually spoke about this at Next.js conf, this year, a talk titled... I think it was Zero To 10 Million With React Native and Next.js, was the best title I could come up with.
Jon Major Condon:
Yeah. We listened to that talk. That was a really good talk.
Fernando Rojo:
Thanks. It was really fun to work on. This stack and the journey of working on it has been pretty long, in some sense. Like I mentioned before, when we were in Y Combinator, that was my first time building with React Native, and we just built an iPhone app. After that, we pivoted into a version of our product that we also wanted a website for. I built this new iPhone app, and then I wanted to build a website. And so I built up them both totally separately. And these were really early days of Expo web. I think Evan had just put a beta out or something. Something just felt really wrong that I was doing that. I know how to build a website, I know how to build an app, and switching between the two is a huge context shift.
Fernando Rojo:
The fact that even on native it defaults to flex, and on web it defaults to a block, for display. Little things like that were just really weird mental model shifts. So I tried a few apps like that, then I built a full website with just React Native. This was before React Navigation had web support. I feel like I tinkered with a lot of different ideas when we were in full pivot mode. I think we shipped four or five different apps in six months. We were trying a lot of different stuff. So when we started building BeatGig, I felt that I had learned a lot from just trying to ship so many products with a stack in different forms.
Fernando Rojo:
My key takeaway was, I love Expo for native and I love Next.js for web. And there has to be a way where we can share enough code between the two where we don't sacrifice the user experience on either. The main issues I was facing were animation, navigations, and responsive design, mostly, like I mentioned in that talk. And so that's where most of my open source time has gone, is solving those problems and unifying the stack. Because we're a team of two, it's just one co-founder one front end. Two engineers, that is. We have a bigger team, but we've all was just been building, the two of us. And it just always felt like if you unify the stack, you could have one engineer building three teams worth of work.
Jon Major Condon:
Sure, yeah.
Mazen Chami:
So, other than animation, I think you mentioned, what were some other difficulties or challenges that you ran into, using this stack?
Fernando Rojo:
The hardest part of unifying Next.js year with three React Native is without a doubt, navigation. When you open a website, you have a very flat navigation pattern. You click a page, it takes you to that page, and it's all in the URL. The URL, with some exceptions, is the source of truth for the entire navigation state. With native, this isn't the case at all. You typically go from tab to tab, for example, and your previous tab stays mounted. So if you're on the home tab on Spotify and then you click search and you go back to home, you preserve your scroll position. That screen is essentially still mounted. On web, there's no such pattern, which is a lot simpler. Web is actually a lot better, in that sense, that you just have to create a page, and that's it. But on if you're maintaining this entire complex state of your navigation.
Fernando Rojo:
And so, trying to pair the two is very fundamentally hard. And I'm still, to this day, struggling with this. I feel that I have built a few different versions of a library to pair it. And I now actually feel pretty confident in the solution I have, but it involved a lot of bringing web patterns to native and bringing native patterns to web. So in my latest abstraction for solving this problem, I only ever go around the app with URLs. So, on native, with react navigation, you typically do something like navigation.push, or navigation.navigate, and you give a screen name. Rather than doing this, I now only use URLs on React Navigation and Next.js, and I use React Navigation's linking config to handle which screen to go to. So that's just one giant step in the mental model for cross-platform navigation.
Fernando Rojo:
I've broken it down to three steps. There's, how do you go cross pages? Which is the API for navigating from one screen to another. How do you render them? With Next.js it's a pages folder, and React Navigation, it's a stack or tabs, these actual component-based renders. And the third problem in general is just models. If you're on a artists screen and you want to click edit, it might be artist/Drake/edit. But on native, that's just an actual screen that pops up in general, it's a standalone screen, whereas on web, it has to pop on top of a base screen. So those are all considerations that have been pretty tough to handle, but I think I've developed some pretty good patterns for them, and I actually have some plans to release some exciting stuff around it soon.
Mazen Chami:
That's pretty cool. And I'm assuming what you're talking about was your expo-next-react-navigation package, is that correct?
Fernando Rojo:
Yeah. Expo-next-react-navigation is my first ever open-source library. It's a library that exports a link component and use router hook that... or use routing hook, I think is the name I chose at the time.
Mazen Chami:
Use routing.
Fernando Rojo:
Yeah. And it does exactly what you expect, which is just, it gives you one component and it works on both web and native. But I haven't loved the API in the long term because of this reason that you're often having to piece together screen names with URLs. So, on web sometimes you want to use a specific URL or an AZ path on Next.js, and then on Native you might have a different screen name. It works well, but I would say, from a user experience perspective of having a best API for unified coding, that has been a shortcoming. So I'm working on a whole new version of this library that I've the code names, Solito, the idea being-
Mazen Chami:
I love your package names, by the way.
Jon Major Condon:
I know.
Fernando Rojo:
Thanks. So this one is-
Jon Major Condon:
I think you should bring back Fuego.
Fernando Rojo:
Fuego is my second one. I would've loved to continue that one, had we still used Firestore on the front end. I think the reason I had these kinds of names is, I came from more of a building product on the marketing side. I built shoes, not code. And I never took a computer science class. I didn't really learn the functional naming for things. So my first instinct, when I was building a Firestore class was just to call it Fuego.
Mazen Chami:
And that's cool.
Fernando Rojo:
So, for expo-next-react-navigation, I did go the functional name route. It's a mouthful. And the next evolution I'm calling Solito, with the idea that you can be a solo developer and build for everyone, with a good user experience and a native feel on every platform you're building for.
Mazen Chami:
Kind of ducktailing a little bit, what is the state management system that you use and you prefer?
Fernando Rojo:
I've gone all over the place with this. I started with Redux, back in basement days, and I'm so glad I don't use that anymore. I know people like it, but I have strong, I would say, opinions against using it at this point. I've come to believe that the API we use is just so important and any mental overhead that could be automated isn't necessary. So for BeatGig, all of our data management is using SWR from Vercel. And the way it works is our backend is written in Python, and we have Swagger integration on our backend, which for those who don't know, is like a graph Qr for REST, where essentially it takes all your endpoint, standardizes their fields and gives you just a schema to view your backend, in plain terms. So what we do is, every time the backend deploys, it cogens an SWR library for the front end, publishes that to npm and the front end imports that.
Fernando Rojo:
So I never write fetch with a string/user or anything like that, I just import use Git user as a function,and I call that. So, that's been pretty great. I think we've been able to abstract that part away. And so, most of our state management is just data and it's all going through the rest of SWR. Every now and then we do need global data, just like every app. You need state across components. Typically, I just use context with use state. I never use reducers, ever. The mental overhead to me, it's just complicated. I don't like switch statements. They don't really make sense to me. I used to when I used Redux, but now I don't. So for state management, I'm usually just doing context with use state. And it's a bit bulky because I usually create two contexts, one for the set state function and one for the actual state itself.
Jon Major Condon:
Yeah, same here.
Fernando Rojo:
It's a pretty common pattern on obviously. But I remember at the beginning that it wasn't really intuitive to me that you might not want the button or whatever's triggering the state change to also rerender when it fires something. So I like separating it like that. I've recently started using Zustand for the first time.
Jon Major Condon:
What's that?
Fernando Rojo:
It is a global state management hooks library from... I want to say his name Dai-Shi. I'll have to look that one up again. I've really loved it. It's essentially doing everything that context does without a provider. And you optionally can have a provider, and it also bakes in the dispatch functions for you. The API feels like a context selector, which I've really liked. So you can use the selector style function from Redux, which I do like, but you get the benefit of basically writing your whole context in one function when you first initialize it and you don't have to create different ones and export a bunch of different functions.
Mazen Chami:
That's awesome. I was just checking out the Zustand and GitHub profile, and it looks pretty cool. And we need to give that a...
Jon Major Condon:
Yeah. Put that in the show notes.
Mazen Chami:
Yeah.
Fernando Rojo:
One state management solution I should mention is URLs. Pretty big part of what we do actually, and I've come to like this a lot, I really like using URLs as our so source of truth. There are some complications with it, but in general, adding query parameters as React state, is a great pattern because it makes it so much more likely that someone can send a link to someone else in their company or just hit refresh. It's hard sometimes when you have asynchronous initial states. So for example, this is a problem of all the time, our artists open BeatGig and go to their dashboard, and then they see a calendar of their upcoming events.
Fernando Rojo:
A lot of the times, it's a manager who has, say, 10 artists. So, similar to Google Calendar, you want to be able to check which calendars you're viewing. So in this case, you want to be able to check which artists you're viewing. The issue is, you can't set an initial state of an asynchronous call. Let's say that you want to filter which artist you're selecting, and we're using the URL as a source of truth for that. So we'll put the artists' IDs, say, in the URL. The way I structure this now is, I fetch the artists' IDs when you first load the calendar, I check the URL to see if you have any in there.
Fernando Rojo:
If you do, I basically filter out that are invalid. You open yourself up to someone using invalid state when you put a URL query parameters as your state. So I filter out those, and then I just need to basically reset the initial state to whatever artist IDs I fetched. I think an unsolved or undiscussed problem is when your initial reacts date has to be fetched asynchronously, but you don't want to just show a loading spinner. I want to show the calendar, fetch, and if there hasn't been initial state set, then in-use layout effect, I'll usually set my initial state.
Mazen Chami:
That's pretty cool. And on that basis, we're talking about web and mobile here, how much of that business logic are you airing between all platforms? I know you mentioned there's, there's a bunch of shared components. How much of the business logic is now shared?
Fernando Rojo:
Little by little, I'm finding it easier to share business logic over some other things actually. So something that expo-next-react-navigation did was let me share query parameters across web and native. And it inspired me to create something called a useParam. I feel like a lot of people have had a similar idea, a hook that state manages a certain query parameter. What this hook does is, it falls back to use state if Next router is undefined. So what that means is, it uses next router as your query parameter state management, and on native when Next router's just going to be undefined, it'll use normal React state, but its initial value will be the URL query perimeter. So assume you're on an artists list screen, you're on the artists search and you click an artist and... I'm trying to think of a better example.
Fernando Rojo:
Well, let's use that. Imagine you're on an artists list and you click on an artist, and you want to default the offer amount to the artist's asking price. So an artist goes for, let's say, $15,000 and you can send an offer. So when you click an artist, it defaults the query per to be that asking price. And as they type, it to changes in the URL. With Next.js, it's very obvious and predictable what's going to happen, the URL's going to change as you type. Now with native, what happens, there are no URLs with native. So what this hook called useParam does is, it sets the initial state of the screen to the React Navigation route parameter.
Fernando Rojo:
So it'll create a use state function where the initial state is route.params.offeramount. And then it returns a set state function, which on native just calls set state, and on web updates the URL query parameters. So in that case, I'm actually sharing a 100% of the business logic, and I'm also using... React Navigation has a great linking config which I'm using to parse in the different URL query parameters on both web and native. So I navigate to that screen using URL and I update the state using a single function that under the hood gives me the same API across platforms.
Mazen Chami:
That's pretty cool. Yeah. Having it all shared makes it much easier to maintain, I'm sure, in the long run also. Can you tell us a little bit more about why you built Moti? I'm a big fan of Reanimated 2, and I see Moti is built on top of it.
Fernando Rojo:
Building Moti has been a lot of fun. The initial idea came about when I was trying to do very simple animations on web and native. I've always found it very difficult to do a fade-in, in React Native because you have to maintain state. So you have to basically maintain is mounted, default something to zero and then animate it to one, and then that's zero opacity animated value. Now I started building with CSS where you just would use animation key frames, way simpler. You just predefine the animation, and it worked. That, from the start always had me thinking, the animation API in React Native is too bulky. And there were some cool things like Animatable, a lot of cool libraries that used the native animated API rather than Reanimated, that were simplifying animations.
Fernando Rojo:
So, when Reanimated released a beta for V2, I realized that the API was going to get a lot simpler and a lot more powerful. And at the same time, I was having a ton of trouble having parody for my animations between web and native. I actually liked animating more on web, because I could just parse transition opacity and it fades in when it changes or things like that. And so, all I wanted was a library that would take a state value and animate when it changes. And I tried Framer Motion and I was just blown away. I was like, "This is perfect." And so I thought, "I'll just try to copy Framer Motion's API, and build that with Reanimated under the hood." So I just made a quick hook that would take in a style object, apply things like with timing and with spring to it.
Fernando Rojo:
And a big conclusion I had is, importing a function is a pretty blocking thing to coding really fast, in my opinion. I'd much prefer to just deal with typed objects than having to import things and chain functions. I find Reanimated to be an incredibly performant great technology. And I thought that just adding an object layer on top of it that looks totally declarative and the typical React code you're writing, would let you just do a fade in in three lines and not have to import hooks or of bulk up the rest of your code with things that should be abstracted into just a plain prop.
Jon Major Condon:
So I actually used Moti pretty recently, and the API is great. What I haven't gotten to use from you recently, which I'd like to is Dripsy, which seems to be like Theme UI or... What's the other one? It's like Styled Systems. You want to tell us a little bit about Dripsy?
Fernando Rojo:
Dripsy is essentially Theme UI for React Native. In 2020, I built a website called penguincbd.com. I got hired by this CBD company to build their entire brand from scratch. I built their website, logo, all kinds of things, when I was doing some contract work. And I loved that project. They since got acquired recently, and it was just a super fun thing to build. And I decided to use Theme UI for that. I never actually used a plain React library for building an e-commerce site. So when I was building Penguin CBD, I did that, and I loved it. I loved the API, I thought Theme UI was just really powerful. And so then, after that I started building BeatGig and I was looking for a great styling solution for native and something that would also handle a responsive design the way Theme UI did, where you just parse an array and something becomes responsive.
Fernando Rojo:
I found that to make me move so quickly. So my first instinct was, "All right, how can I possibly bring this API to native?" And I made this thing called Expo Theme UI, which I eventually renamed to Dripsy. Over time, I started taking the dependencies of Theme UI and just turning into my own library. And one of the learnings I had from that is to not rely so much on another library in general, and just to build my own but be inspired by the APIs. But yeah, Dripsy is essentially Theme UI-inspired library for themeing and responsive design on web and native, with the exact same API across platforms.
Jon Major Condon:
Awesome. Yeah, I'm really excited to try it out. I'm a big fan of Theme UI and Systems.
Mazen Chami:
And that said about Dripsy, do you use a design system? Does BeatGig have its own design system?
Fernando Rojo:
BeatGig does have a design system based on Dripsy. So, Dripsy is the building block for all of our designs. I get asked a lot how we handle responsive design on web and native, and I just send a link to Dripsy. I would say I've abstracted much less than you might expect. I know that design systems are super popular right now, and I am pretty pro them, but ours is pretty nimble. I would say there are four components from our design system that I use all the time. But for the most part, Dripsy is theming, lets me set default styles such that I don't need to use the design system that often. So for example, with Dripsy in the theme, you have a text key, and let's say you do text.body, anything you set there will by default style any text component.
Fernando Rojo:
So I just set text color to be text, right? So I have colors.text as white and text.body.color is just text. So then that pulls from my colors.text. There's a component I have called an entity, which I stole for from Vercel's design system. I just was looking at their design system, and I would say our design's pretty heavily inspired by theirs. I like how intense the colors are. If you just go to vercel.com/design, they don't actually have the code public, but you can deduce from their APIs, how to remake theirs. This entity is an incredible design system component that I use for every dashboard screen, like lists and forms. It's just absolutely amazing.
Fernando Rojo:
So I do use a design system, and I've been getting more and more into it for things like badges and cards and notes. I use it a lot for that. Very often I am just writing a view, and with our padding keys I'm able to just use Dripsy and do padding color in three, and then I just use our third scale. So I found that to be pretty easy, and I write a lot of my styles in line because a lot of the boiler plate is handled at the Dripsy theme.
Mazen Chami:
And that's pretty cool. I just want to say, it seems like whenever you find a roadblock, you turn around and create a package that unblocks you, and you make it public, and I love that. That's awesome.
Jon Major Condon:
Very helpful.
Fernando Rojo:
Yeah. It's been fun to do that.
Jon Major Condon:
So, Jamon often says React Native web is what ReactJS should be. In your talk you mentioned that some things were easier using React Native web than using ReactJS and native web tools.
Fernando Rojo:
I think React Native is better in principle than ReactJS on its own, simply because it's abstracting the UI away from the metal a little bit and giving you a much stricter contract on what you expect to happen when you create a component. CSS classes and CSS in general as a low level API does not lend itself to a component-based as a design system. It's like if you had a component that can be edited without props in state. I think you should be able to open a component and viewing its hooks props and just any state you see there and know, essentially, exactly what its behavior's going to be. And CSS really breaks that rule. What React Native does with Style Sheet API and React Native web by bringing that over to web is, make it much clearer what's happening, make styles way more predictable by removing global styles and adding a UI layer.
Fernando Rojo:
I mean, react itself is this amazing paradigm, but they mix together two things, which makes sense, but HTML itself is what... it feels like it's forked and React, a bit. We change it a little bit and we parse props that are a bit differently and we can parse objects to it or for style and things like that. What React Native does is it adds a layer on top, so you never actually directly in with HTML, but instead you interact with a layer that feels like HTML using text instead of span. But it has some safe resets for styles and abstracts away some of the platform quirks that you shouldn't have to run into.
Jon Major Condon:
Makes sense. So you have a new startup idea, would you use Expo, web and Next.JS again?
Fernando Rojo:
I would, I would. I think it's a futureproof way to build. There are still always some difficulties, but given that the hardest pieces in my mind are navigation design and animations to do across platform, and I feel that I have pretty strong solutions for these at this point, it's a brainer to me. I remember talking to Charlie Cheever from Expo, I want to say two years ago, after building Basement, and having a conversation for the first time hearing his perspective on Expo. And he said something that really stuck with me, that when you're building a website... This really reminded me of when I made my first website as a kid, you just open an index DOThtml file, you type some text and you drag into your browser.
Fernando Rojo:
And our current way of coding is nothing like that really. I mean, I think Expo and Next have a certain magic where they try to mimic that experience, but I would say until a few months ago, I didn't really understand what Babbel is, and I still don't. I actually, very actively, tried to not learn things that are related to build tools and config. I try to not understand Webpack and Babbel and stuff like that, leave that to better people so that I relieve my cognitive overload. And I would definitely build with this stack again because I think that it gets you a bit closer to this index.html file paradigm, where you are on Expo in it, you open your iPhone, you have an app, right? Try doing that with Swift.
Fernando Rojo:
Now, I think it's obviously behind in some capabilities in general with React Native to native, but it's improved so much, especially over the last year. Now that we have these libraries like Moti and Dripsy, pairing it all together is a bit more low-risk, because the library have first class support for web. So you could use them if you were just building web. For example, my website, obviously it's just a website, just fernandoroho.co, I don't have an app for it. But I use Dripsy for it, because it's the fastest way I know how to code something. I just made a theme and wrote it up, and that was it. And I use views and text instead of divs and spans, and I got all these little default flex styles and things that I'm just so used to, that I think make for a great way of building a website
Jon Major Condon:
Right on. Well, if you don't have anything else that you wanted to share, I think we are at the end of our time, so I'm just going to wrap up. And first of all, thank you Fernando for joining us today. This was a fun one. If you'd like to nerd out about more React Native, do check out Jamon's Twitch stream at rn.live or youtube.infinite.red. You can also join our slack community at community.infinite.red. We have almost 2000 React Native developers in there, and you can be the next one. So where can people find you, Mazen?
Mazen Chami:
@MazenChami.
Jon Major Condon:
Right on. And Fernando?
Fernando Rojo:
The easiest way to find me is probably on Twitter, @FernandoTheRojo, and the other one is GitHub. I'm pretty active on GitHub issues and things like that, just Nando Rojo. And if you find me on Stack Overflow, you've gone way too deep,
Jon Major Condon:
Good stuff. You can find React Native radio @reactnative R-D-I-O, on Twitter. So again, thank you for joining us. As always, thanks to our producer and editor Todd Werth, our assistant editor and episode release coordinator Jed Bartausky, our social media coordinator, Missy Warren, our designer, Justin Husky, and our guest coordinator, Derek Greenberg. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/reactnative. A special thanks to all of you listening today. Make sure to subscribe on all the major podcasting platforms, React Native Radio. Reminder that Infinite Red is hiring React Native engineers. If you are a senior level React Native engineer located in the US or Canada, go to careers.infinite-red, and we'll see you on the other side.
Mazen Chami:
Take care.
Fernando Rojo:
Thanks.
Jon Major Condon:
Till then, bye.