Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 347 Skylight Smart Displays powered by React Native.

Mazen Chami:

Hey everyone, I'm Mazen and this is React Native Radio. Today I'm joined by Alex Lolow, who actually works at a company that I'm a big fan of and I think this will be a fun discussion that we'll have. Thanks for coming onto the show, Alex.

Alex Lanclos:

Yeah, nice to meet you Mazen.

Mazen Chami:

Likewise. Yeah, and I'm happy to hear that you live in my neck of the woods. Not a lot of React native people out here. As far as I know, I've only met two or three from the Durham area, so yeah, can you please introduce yourself to our listeners?

Alex Lanclos:

Yeah, absolutely. So, hi, I am Alex Lolow. I am a principal software engineer here at Skylight. I've been working here for almost three years, which is kind of crazy. Started whenever it was a team of around five or six engineers and now we have more engineers today than we had full employees when I joined, which is a very humbling thing to think about, to be

Mazen Chami:

Honest. So you were there from the startup age to now with your full fledged product. That's awesome. We'll get into more our topic in a little bit, but before that, let's hear from our sponsor. Infant Red is a Premier React native consultancy fully located in the us. We're a team of 30 senior plus level React native developers and support staff and have been doing this for nearly a decade. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash Radio. Don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's get into a topic skylight in React native. Alex, can you give me your elevator pitch for your app for people that aren't familiar with Skylight?

Alex Lanclos:

Yeah, sure. So I say that our app slash product is a little unique, so our product suite is the one-stop shopper families. It'll help you plan your meals, manage your grocery lists, get your children to do their chores, reward them when doing them, sync your personal work calendar seamlessly and more, and that's just for our calendar product. Our original claim to fame was our skylight frame device, which was how can you share memories to your loved ones who aren't immediately by you? And we've carried those sort of traditions across our entire product suite today.

Mazen Chami:

That's awesome. Yeah, you have a hardware element to this app essentially. So before we talk about the app, which is fully React native, the frame that you call it, it was never built in React native and what is it built in and what were the reasons behind that?

Alex Lanclos:

Yeah, absolutely. So the Frame itself has always been this hodgepodge of Android, if you will. So originally this product suite with the Frame was started by Michael Siegel, our CEO as a project that he was working on while he was in the Harvard Business School and literally slapping an Android device inside of a wooden frame. It always had early hardware problems as far as how much we could actually load into this thing, especially as an early stage startup. And so they were concerned about software limitations and so Skylight itself has been around surprisingly for six, seven years now at this point, and so they wanted to make sure that they could give their best foot forward and decide to go with a native Android implementation, which sounds a little sacrilegious whenever we're talking on a React native podcast. I know, but they wanted to go with something that was closer to the metal a little bit that didn't have to worry about a JavaScript bridge, especially back then whenever React native was still very much so in its infancy and as it's built out today, it's a Kotlin application, so very much so native Android development on Android operating system.

Mazen Chami:

Sure, nice. Yeah, and I assume now with the new architecture, there's nothing stopping you all from probably porting it over to React native and leveraging the code base that you currently have for the mobile application within a unified code base on there.

Alex Lanclos:

Yeah, that's something that we've actually have touched on a little bit. I pride myself in the fact that our React native code base today is extremely easy to work in. We generally ship features on the client side for the mobile app a little bit faster than we do on the Android side, strictly due to the fact that we've spent a lot of effort actually digging it out from the Brownfield that it was whenever I started to a rather beautiful greenfield application that all of us engineers here to work on, whereas the Android side still has a little bit of warts and Jetpack Compose is a relatively new tool set on the Android ecosystem versus the old school XML style view development, and so there's still some up and up on that.

Mazen Chami:

Yeah, yeah, I hear you well. Okay. I think that's the hardware. We can kind of put that aside for a little bit despite it being the face of the product. At the end of the day we'll kind of focus on the mobile application where specifically me that's where my interest is. Tell me a little bit, when did you start using React Native and why? Because I feel like when we were chatting before started recording I heard some pain points in there.

Alex Lanclos:

So I started working in React native personally and professionally around the end of 2017, so that was right around I think dot four nine React native,

And this was at a time where I was working at a food delivery business based out of the Southern United States that had two native repositories and we had an extremely small team and we had kicked the can a little bit on trying to utilize React Native. At the time we felt like it was too new around the end of 2017 we're like, let's give it a shot. It was too painful to maintain the two separate native repositories and we want to spend our engineering budget on other parts of the ecosystem. At that time, auto linking was not a thing, so we're talking about you had to have in my opinion, some idea about how the Native side worked. You had to know how Gradle built, you had to know how at the end of the day, how to utilize the build system that iOS provides through either through Xcode or Obfuscating that a little bit with Fast Lane and so on.

And so the upgraded process for Reactive was also quite tumultuous. I remember dot 60 whenever auto linking was first introduced took an extremely long time to implement. So that's a little bit about my professional background in React. Native Skylight itself has been utilizing React Native for its mobile app since it was first introduced, which I think was right around I think six six when they first started utilizing it and whenever I joined back in the beginning of January, 2023, I think they were on dot 70 and was already a little outdated at that point and we've been using it since.

Mazen Chami:

Awesome. Yeah. What is your architecture stack and what were some of the reasons behind it? For example, are you all using Expo?

Alex Lanclos:

Yeah, we are. I was talking a little bit earlier about the back in the day aspects of React Native where Expo as a tool set was a, you had to use the full managed expo solution set or you couldn't use any of the tools at all. And I remember like, oh, why do you need expo? Just roll it bare. You're giving up so much fundamental access to what you can do with your application back then now. I think you'd be quite silly if you're not choosing to use Expo in your React native application today.

Mazen Chami:

Totally.

Alex Lanclos:

I think that you don't necessarily have to roll a full managed workflow at Scotty. We still utilize a bear solution set. I think there's a couple other reasons as to why we do that, but in general, expos tool sets are very, very, very expansive and to go a little bit further into the stack that we utilize here at Skylight, when I joined it was a pure JavaScript application redux and then this is Pret thunk Redux. Oh yeah,

Mazen Chami:

That was fun.

Alex Lanclos:

Yeah, just a little bit class components, you name it. It felt like you just cherry picked an application out of 20 17, 20 18 and just stuck it there and I picked that up in 2023. Today we follow Atomic Design for our class component component architecture itself types grips through and through functional component sets. Actually shout out bootstrapped a few of our early atoms from McKnight.

Mazen Chami:

Nice. That's awesome.

Alex Lanclos:

At the time our styling library we were utilizing was Drips. Yeah,

Mazen Chami:

That's a package by Fernando Roho, if I'm not mistaken, right?

Alex Lanclos:

That's correct. At that time we wanted to start to introduce some more break pointing and we liked the design token solution that he had provided. However, that's been a point of contention for us here at Skylight where we're actually migrating over to Uni styles. Uni styles V three I think was the thing that I had been waiting for quite some time and their immediate query solution, I think in general we found that components themselves also tend to have a little bit better performance.

Mazen Chami:

Totally. I'm a fan of uni styles and I've been using styles on all my projects including client projects too, and we've had a lot of success with it and feel it's very performant in that sense. And I was speaking to Sek who's the creator of it recently and he's transitioning to wind, so a tailwind for React native sort of thing, but hopefully we'll have him one day on the podcast is what I'm saying. It's a pretty cool solution. So kind of hear you moving in that direction almost sounds like what we've been hearing in the industry these days.

Alex Lanclos:

Yeah, I think providing a best in class styling solution and React native to ecosystem is a problem that I don't think the community has kind of adopted as there's one head to crown sort of situation. I think the React ecosystem has kind of fallen behind the tailwind side of things. I'm still not a huge Tailwind fan personally, however, I don't let those biases keep parts of my team from utilizing it on their Pure React website solutions. The last bit of note about that application, we use ENT for local state management, reanimated for all of our animation based logic and we use Expo router for all of our navigation. We had made that migration from React navigation to Expo router earlier this year.

Mazen Chami:

Nice. Yeah, that actually, honestly being frank with you, that sounds like an exact stack of what I'm using on my current project right now. Sistin is pretty fun and ergonomical in my opinion to use. So you must be excited from plain redux I guess is the word to use here to existent.

Alex Lanclos:

Yeah, well I guess the note here is that the way our Redux implementation was, it was ingesting all of the API data and local state management and kind of introducing it all throughout and so you had your actions, reducers, selectors and so on. The way we ingest API information is actually through Tan Stack Query and so we are a rest shop here at Skylight, so Rails backend, the way that we take that, we would like to have that separate dichotomy of API cached information support that cache layer pretty thoroughly and have existent as our local state management that persisting specific user touches how they interface with the UX itself. If we need to introduce information across multiple screens versus utilizing React context, we may use it in that case, but that's rather sparing. But yeah, coming from a spot where it was a full vanilla Redux application and trying to break apart that state management was a bit of a bear.

Mazen Chami:

Yeah, yeah, that's actually again, we use 10 Tech Query to ingest the API stuff. That's awesome. What about testing? What do you all use for testing?

Alex Lanclos:

So I think that our testing here at Skylights a little interesting. So one, we have an amazing QA team. Whenever I joined we had a singular manual QA who just knew the product back and forth and he was a person that was fully capable of just helping us get the product through without any specific issues. He would catch any regressions and lifesaver. As the team has grown, you can't lean on simple manual QA as your total wall slash barrier to having bugs go out as regressions. So we're finally getting to the point where we can spend some effort on writing some more automated intent tests. The tool that we use today is Maestro, which I think from the React native community has kind of been adopted as the defacto solution in my opinion. They're really easy to write. There have been a couple tools that have used in the past and they've all had specific issues one way or another. Maestro seemingly has kind of gone down that path of trying to obfuscate some of the lower level things that we've generally had to deal with and had zero concerns there.

Mazen Chami:

Nice. I was hoping you would say Maestro is then that officially checks off the last piece on our box. Correct me if I'm wrong, but you all have a in-app purchasing capability, right?

Alex Lanclos:

That is correct.

Mazen Chami:

So I guess my next question leads into that and probably maybe not, but have you had to build any custom native implementations and if not, what are you all using for your payment solution?

Alex Lanclos:

Yeah, so the payment solution itself because, and a little touchy of a subject, even though we sell a physical hardware product

And we've deemed the mobile application, especially in the eyes that are as far as charging US fees, we try to state that our application is an application that pairs with our physical device. It is a partner application, however we can get past that. So we are utilizing React native IEP, which is just a simple library that allows us to interface with Google and Apple's store solutions for the sake of purchasing downstream. So our plus purchasing sku, we now have a frame and a calendar plus skew itself and we're hosting those effectively through the Google Play and app stores. Now. You kind of talked a little bit about the native modules sort of things, the things that we're actually having to utilize native modules for widgets surprisingly, so we've got a couple different libraries that care about trying to interface on the native side. One signal is a really good example of that for push notifications they require on the iOS side for you to have the custom notification service. We have a custom share extension that we also have, so you're on Google photos, you want to be able to share the specific assets from outside of the application ecosystem. Their share extension is needed for that and widgets. So we have started to proliferate those out. We have a little bit more on the iOS side than the Android side, mostly due to bandwidth issues native side, so we've got a list widget, we've got a tasks widget, we've got your calendar, Vince Widgets, and we're trying to expand that footprint more and more.

Mazen Chami:

Yeah, thanks for bringing that up actually I didn't know that existed. I just pulled up my phone and I added a widget to my home screen now. Thank you.

Alex Lanclos:

Absolutely.

Mazen Chami:

Yeah, and I think as our listeners are listening, I mentioned this, I think I mentioned this before we started recording, I bought a skylight frame for my wife shortly after the pandemic, so kind of early on from what you were saying, but you all had the whole calendar piece and the partner application at the point, but she wasn't necessarily invested in it. We were the type of family that used our dry erase board. We wrote on a dry erase board our weekly schedule and did a standup have view like, oh, these are our meetings, we have conflicts here, let's figure it out. And then as our family grew, our son was born about three years ago. That's when I was like, Hey, remember that frame? It's probably time that we leverage it more managing his medical appointments and as he gets older we have school and all that and we've grown to use it daily now actually, funny enough, I tried to erase our dry board still has our weekly schedule on there.

It's outdated at this point. I tried erasing it and I had to use some rubbing alcohol. It's been on there for so long because we've fully transitioned to Skylight and some of this other upsell stuff that you mentioned like meals and rewards, those are very cool features that I think we'll be looking at going down the route at some point. So this sounds like a lot of different things that you're doing, especially I know calendar syncing I've looked to in the past, which is kind of how I found about Skylight can get tricky with all that kind of stuff. So I guess have you had performance issues with your application and how have you had to optimize that down the line?

Alex Lanclos:

Yeah, absolutely. So in general, yes, calendar syncing is quite difficult with all the different providers that exist today with Cozy Google, apple, we have our own baked in event solution itself and trying to ingest all the information, being able to display that like kudos to the Google engineers and their monthly implementation just absolutely astounding and trying to replicate an equivocal UX has been a challenge to say the least as far as performance slash how do we improve the performance performance itself in the application, one of the things that we typically use is flashlight. So I don't know if you've heard of Flashlight. That is a tool that we use for testing the actual performance itself. So I hook up an Android build, hook it up to my Mac and start playing around and I'm trying to see, okay, where am I running into bottlenecks as far as where am I throttling the GS thread, do I have any dips in the UI thread?

What does my memory consumption look like over time? I think in general in time you're manipulating images and uploading and trying to load those into memory. That can get a little tricky and especially as we support a frame and calendar where you can upload assets both photos and videos for, that's something that you have to keep a close eye on. And again, some of those heavier components like our month view and week view components instead of our application are quite heavy. And so we use that tool pretty heavily when it comes to diagnosing some issues during the development lifecycle. Outside of that in general, we utilize flash lists for most of our lists in the application. To date, we've dabbled in legend list, legend list twos out and we're still considering trying that out in a couple different spots to see how it plays out from a performance side.

I think one of our earliest issues that we had with Flash List itself was how well integrated it was with the Reanimated library and some of the things we were trying to do where we had to custom roll our own animated flash list. So the jury stole out as to which tool we're going to use in the future, but that's here nor there minimization across the board. However, react compiler is a thing that exists now, so we've dabbled it in a little bit. The platform team, which is the team that I effectively overrun as far as the mobile side is concerned, the engineers keep trying to take it over for me and I won't let it go. So I'm going to be playing around with React compiler probably next month, see if we can get it over the hump. Hermes V one is the thing that's now in experimentation, so we're going to dabble in that a little bit and we migrated over the new architecture as well. So I've had a love-hate relationship with new architecture at this point though. So

Mazen Chami:

Tell me more. I think actually before I move forward and I'll mention to our listeners, we interviewed Alexandra Murrow from Flashlight in r and r 3 28 and then also Jay Meistrich for Legend List in 3 25. So our listeners are familiar with these components and you mentioned Flash list too. We interviewed Han Nvi on that too, but we'll include that in the show notes for sure. But I want to hear more about your, I kind of said this many times on the show, but tell us a little bit about your journey from the legacy architecture to the architecture. If you see what I did there?

Alex Lanclos:

Yeah, do eight two was officially the point of no return. It's a bit scary to say the least. We are on.seven nine right now. I've got a branch off the side where I've migrated up to dot eight one, I'm rolling through some regression hot fixes before it makes it full live into production and I've been eyeing dot eight two waiting for Expo 54 to fully support it before we go down that path and new architecture slash the architecture, it was a bit of a journey. We had several components that just did not play nice whenever we migrated over, so that required a fairly extensive refactor on some of our atoms that we had that were proliferated throughout the entire application to say the least. I think text input might've even been the worst one, like the worst offender reanimated itself, I'll put it this way, we are still dealing with a couple warts, if you will when it comes to new architecture.

I think candidly the Android performance was promised, right? Like you're saying, oh, you're killing the JavaScript bridge, your Android performance should improve drastically. And what we found is that there are still, I think there are specific shadow node delays when it comes to how quickly it was able to render on the Android side that they've started to fix and it's actually experimental flag setting in eight one and fully rolled out in eight two that I've been eyeing fairly extensively. We've got Reanimated that's trying to improve some of its performance issues and so I think my largest issue from migration was less of the whack-a-mole, if you will, of trying to fix the problems that'd be and more about trying to solve for the problems that started to come up due to the fact that the ecosystem was effectively freshly adopting new architecture and you had libraries that were making this one off swap be like if you want to use this new version, you have to make the swap. That was the case with uni styles V three latest in MKV with nitro modules again Reanimated V four, flash list of V two. And so we were just staring down the barrel of we're going to have to make the swap eventually, let's pull the plug and just go. And I think today we're still dealing with a couple of those small issues.

Mazen Chami:

That sounds familiar and I think now that we're at the point of no return, it's going to be interesting to see what the future holds, but I'm optimistic. I feel like this is just going to get easier for us until I think it'll get easier for us. But I say that point is going to come when we stop referencing the old architecture and have officially moved on to 82. We're still going to have stragglers behind, we're still going to have just today, I think it was this morning I got tagged in an issue for left to right to left support. There was a bug in an older version, new architecture versus old architecture. But the interesting thing about that is now that meta is fully focused on the architecture and we're not going unquote back to it, we can't replicate it, right? Because we can't do the legacy architecture and then come back to the architecture and see the difference between the two. So now what happens sort of thing. So it's going to be a song and dance for a little bit while things get ironed out there.

Alex Lanclos:

Yeah, I'm still very bullish on React native. I think it's this case that when you're making such a massive swap and look, I've been around the block a couple of times. I saw something fairly similar when we were making the migration over to auto linking in dot 60. The ecosystem is going to resolve its performance issues when it comes to Android on React native with hoping eight two and Reanimated itself. Some of these things are just hard to solve for they're low level. When you're looking at what Herbo modules and nitro modules are really doing under the hood, you're looking close to C level issues and my background actually originally is electrical engineering in embedded systems and so I know that pain very well and kudos to the team itself for one, going down this path and Endeavor and doing the migration. I'm excited to see what comes forward over the course of the next six months.

Mazen Chami:

Yeah, that's awesome. I kind of want to ask you about have you dealt with any cross-platform differences while using React native? And I kind of asked this because there's one platform we've kind of neglected here. I know you all have Web, I use it, I wouldn't say regularly, but I use it every now and then and I have checked the source code and it does seem like it's using React native, so it's probably a monorepo or a one repo for all three platforms, is that correct?

Alex Lanclos:

Yeah, so this is a rather new development for us. So we had our app dot r skyline.com domain that whenever I joined and up until fairly recently was a very, very, very old React website conjoined at the hip to our rails repository and no one wanted to touch that thing with a 10 foot pole. One of the goals of mine was to utilize all the technology and tool sets and all of the logic that we had built already in the React native side and take over that dashboarding side of things, which is now just our skylight.com and that is a fully deployed React native web implementation Expo router for instance was like, I got to have this before I ship sort of thing.

In a perfect world unis a full uni styles migration would've been another thing that we would've done. However people wanted access to it earlier and earlier and earlier to the point where it's okay, it's good enough. I think that you'll probably see much more scalable UX on that side over the course of the next year or so as we're paying down that debt a little bit. But from across platform discrepancy sort of thing, again, I've seen it over time and in general the ecosystem has gotten really good to where the differences felt are fairly minimal. I think the text input component is the most notable where how they treat Line Heights, the actual pressable aspects of it, your keyboard manipulation itself from Android versus iOS is fairly different. And so we've always rolled our own custom text component that kind of wraps around the base level react native one and try to massage out some of those differences whenever we can.

But that is just historically one of the worst offenders that, and we've had weird safe area issues on some Android devices as a good example. And so we've got random Yomi devices that are like, Hey, yeah, it's bleeding into my native button area. I'm like, we've got PHI find, I don't know what's going on. And we have to kind of work through that. And on the side, this very may very well be an early styles thing with React native to web, but we've also had really weird flex issues where we have style arrays and it just injects a random flex one into the style and it causes quite a bit of headache and we've had to play whack-a-mole on those specific issues.

Mazen Chami:

Interesting. That's good to know. Yeah, I guess maybe because coming from the React native side and I just worked on a proof of concept for our web implementation from my current client, I see a lot of stuff that we were doing just your using Flexbox and I gather that the scaling of all your components and the little tiles that you might have on the calendar on our skylight.com console, that's pretty cool. Kind of looks like we're getting close to wrapping up, but I have a couple of questions I want to ask you real quick. Can you give any advice to companies out there that are considering React native?

Alex Lanclos:

Yeah, absolutely. So in general, react native as a solution solves I think ballpark like 90% of companies out there. There are problem sets, especially if you are a startup where you are strapped for cash, you're looking to get MVPs out, proof of concepts. I don't know why you would ever spend the effort to ramp up two separate native repositories for it. I think just in general you're trying to be cost efficient, go with something that's simple, but beyond that, most applications consist of lists, buttons, text and images and some hodgepodge implementation of those four components. In my opinion, those are not hard things to implement on React native. They render extremely performant UI from that. The interfaces that you can implement with these things are very solid as far as job markets are concerned. You're going to be able to find a ton of JavaScript engineers out there that are either A, have some bit of proficiency in the React side or have full proficiency on the React native side. So you're not going to struggle to find engineers to pick up a project in React native, especially for long term and a bit of showcase it right? There are a ton of large companies out there that utilize React Native Daily Plus that Skylight do. And so I don't think that you should be concerned that you're spending effort on a tool set that you're going to eventually have to migrate out from. It's something that you can support throughout the entire lifetime of your company. Yeah,

Mazen Chami:

And I think it speaks volumes that you all are one, using React Native two on the bleeding edge, you are basically at the, even though 82 is out, I get that we don't necessarily consider React native versions as the latest anymore, right? We consider expo versions as the latest, whatever it comes with and it sounds like you're about to release that to your users and quite a large set of users there too. So I think that speaks volumes for that too. And you touched on this a little bit about how you'll always find JavaScript developers out there, but what advice would you give to New React native developers that are looking to move into the industry or even get settled in React native?

Alex Lanclos:

So again, I've hired engineers that have zero native experience or zero React native experience, and they are fantastic engineers. You try to shield them a little bit from some of the native level things if you will. You explain a little bit about, hey, this is a view, not a dev, but in general, JSX is JSX and engineers in general are smart and so they're capable of picking up those pieces as you go. I think that if you want to be really good at React native, spend a little bit of time to actually understand what's happening under the hood on the native side. Start to figure out how build systems work, how does Android utilize Gradle? How can you set up A-C-I-C-D environment so that you can actually utilize Fastlane for generating your IAP file, your IPA files for iOS. I think that almost every engineer that I've seen that's spent the effort to do that fully understands and grasp React native more broadly and they are able to troubleshoot issues more thoroughly and able to, I think in general, appreciate what React native then gives back to them.

Mazen Chami:

That's awesome. Last question I would like to ask you is, would you still choose React native? If you could go back with the knowledge that you have today, if you were to start Skylight over again?

Alex Lanclos:

Absolutely. A thousand percent our application set, especially on the mobile side, there's zero need for it to ever be a native level application. You hear things like links and you have Flutter and the heydays of Cordova and so on, right?

Mazen Chami:

Yeah.

Alex Lanclos:

I don't see a need for us to ever implement a solution that's just not React native. The ecosystem of engineers is there, the implementation is streamlined, zero problems there. And in general, yeah, I'm just excited to see what React native looks like a year from now. I kind of mentioned extremely bullish on it and super excited for the broader support for the architecture.

Mazen Chami:

Yeah. Awesome. Yeah, and I'm here hoping that one day your frame will be in React native too and that would be awesome for the community too. Well, I think we're officially out of time, Alex, I really appreciate you coming on the show. It was fun chatting with you. I'd like to kind of end this whenever we have a guest is asking where can people find you on socials or where are you online?

Alex Lanclos:

Absolutely. So I'm most easily found on LinkedIn. I've got an X, but I don't frequent it enough. Gantt tried to show me a couple different tools that I haven't fully adopted yet, so it's a battle on me, I guess, but easily most on LinkedIn.

Mazen Chami:

Awesome. Alright, well thank you Alex for coming on and to our listeners, we'll see you all next time. Bye.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editors, Jed Bartausky and Tyler Williams, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.