Building Cross-Platform Component Libraries for Web and Native with React

Hello everybody, my name is Perttu Lähnälahti and today I'm going to talk about how to build cross-platform component libraries for react and react Native. Before I dive into that subject, I just want to introduce myself briefly. My name, as mentioned, is Perttu Lähnälahti. Don't worry, it's a really difficult one. I had it wrong once even in my passport. The reason for the difficult name is because I'm originally from Finland, currently living in this beautiful Helsinki, Finland. I have a website, Perttu.dev. You can find this presentation as an article there and also a bunch of other stuff as well. You can also find me on GitHub and Twitter using this handle here. And the slides for this presentation, you can find them at this address. You can also find this project there, which will allow you to test it out and build your own components using the way I'm going to show you. So yeah, let's dive into the subject of today's talk. So what this talk is going to be about is, of course, how to build cross-platform components so that you can actually use them in both react and react Native projects. My idea is that the requirements for react Native knowledge are going to be pretty slim. Just knowing the basics of difference between react Native and react is supposed to be enough in this case, and I hope it's going to be. Using react Native, we're going to look into how to actually use that to build cross-platform components that we can use on both web and Native, in this case iOS Android, and also how to build these platform-specific components so that we can have the same components, but the code being different between these two platforms. The reason for this, we're going to talk later more about it, but the basic idea is that we want to have a single code base and share as much code as possible. Towards the end of the talk, I'm going to dive a little bit into the styling and the pros and cons of this approach that I'm going to show you. Then a few additional points. So we're not going to use react Native Web. The thing I'm going to mention soon, and we're also going to use Styled Components and storybook. For those who haven't used Styled Components, it's a really awesome css in JS solution that allows us to style our cross-platform components really easily, in this case. storybook is just something that I'm now using to show the components in a separate context from actually building a real application. This project or this approach that I'm going to show you is actually based on a customer project that I did a little bit of time ago. So that customer, I can't mention the names, but it's a big government owned news organization. They actually had three react Native apps and one web app that was powered by react, basically their main website. They were serving, I'd say, close, maybe even over a million people every day. So the user amounts were huge. My team was asked to build a new feature that would allow live content on their platform. This would mean video, polls, chats, and of course, live updated articles about different things. There were a few requirements. So despite having these three or four different platforms, four different apps, they actually wanted a single code base. So this feature that we would build as a separate component library, it would need to work in all of these four projects, which was quite the requirement. And it also needed to have a unified experience so that it looks and feels same, despite you using it on a different app, different native app, different web app, and so on. And time schedule was also really tight. So I think they wanted to get an MVP out in less than three months or so, which for a company of their size was quite a big undertaking, but we managed to get a pretty good version out. Now, some of you who've used react Native and perhaps react Native Vapor are now at this point wondering, okay, this seems like a really good option to use react Native. However, we actually didn't have that choice. So the reason why we didn't use react Native was multitude, but they came down to this. So of course, there were the good things. We could use the familiar components like view, text, and image that we are already familiar with. And the company's developers were familiar with using in their react Native apps. And those are really easy to build for both web and native if you have a completely new react Native web project. However, in our case, it was already an existing and a huge react app. So we couldn't just bundle in react Native there and get that working. But we were limited to having it so that we need to have react code working in react project. And we need to have react Native code working in react Native project. And also in case we were kind of limited also by these view, text, and image components, because we needed proper html text like H1, H2, H3 to actually get all the seo benefits. So yeah, without further ado, let's actually talk about how we're going to do this. How we're going to do cross platform components. So there's actually this feature in react Native where you can actually do platform specific extensions for files. So those who have used react Native already know that if you have an iOS component or Android component or a view, you can just put the.iOS before the.js extension and react Native bundler will automatically know which component to use and bundle in the javascript bundle for which platform. And it works really well. What most people I think miss most of the time, because when we did that, there wasn't that many mentions of this, is actually that there's also.native extension, which tells basically react that, okay, use this component in the web app and this one with the native use it in the Android and iOS. And the difference comes from that the other one is of course managed by Webpacks for the web and then Metro bundler, the react Native bundler for the.native. And using this, you can actually already create components that work on either or platforms. You can put them in a single repository and use that, but that doesn't actually allow you to build cross-platform components yet. There's still separate components in separate files. But let's dive into actually looking into how to do this. So going back to the editor, you can actually see that this project that I've built, it's a basic react Native type template. The only thing I've added there is the source folder with the components and the utilities folders. Other than that, I've also added two different storybook instances. So there's scripts for running storybook on web and then running storybook on react Native. And that was actually something you just saw here. So if I can go back. So this is actually, these are now the two separate storybook instances. You can see the basic button there and you can see the basic button on the mobile as well. So yeah. Now if we go back to the code editor, we can actually see that let's open up the component for the basic button. In this case, it's called my button. So let's go to the my button file. And we can actually see that that single file that is currently, if we look into the.stories file, we can actually see that it's used by both the native and the react side. And the way that's possible is that my button is a component that consists of button opacity and paragraph. Now those aren't any traditional react Native or react tags that you might be familiar with, but instead they're customly defined. You can actually see that they're imported from this utils.tags file. So let's actually look into that and we can probably get an idea how this works. So let's first look at the tags file. So that's really simple. It's basically, we're just exporting variables like heading one is equal string H1. And react actually is quite smart and can actually handle these as the tag names straight away, which is really cool. And we also have the tags native. And as we mentioned before, if we have these background specific extensions, this means that react Native and react know which one of these files goes to which one. So if we look at the native one, we can see that we're first importing all these image text, touchable, highlighted, and opacity from react Native. And then we're assigning them the same names we have on the text side. So we have the heading one, it's always a text element, a text component. And that actually allows us to build the thing. So we're exporting these two components in the My Brother component and using them. And then when react actually takes this component, it checks that, okay, which one, what is pattern opacity for react and what it is for react Native. And that works. This is actually, this is almost stupidly simple, but it works really well. As I mentioned, we've been running this in production for millions of people. Now, okay, next you might be wondering, how do I actually style this? So if we go back, let's look at the components. So let's open the style button. And on the react Native side, we can see that it's a blue button. And on the react side, we can see that it's a blue button as well. The styles are a little bit different because react Native has a flex one by default, so it takes all the available space. But they still work the same way. So you can click them. They don't do anything, but they are clickable. So then let's look at the actual code behind that. And this is actually where the style components comes into play. So let's open my style button. We can see the style button is okay. It's very similar to my button from the previously. It has the pattern element and the pattern text. But actually, those components are not the same that we imported from the text, but instead they're here below. And using the style constructor, we're passing the pattern opacity and the paragraph elements to the style constructor and then adding styles. And that styles the component. So this way you can actually style cross-platform really easily. It works on both. The style components uses react Native css, if I remember right, to actually turn the same css styles for the different platforms. And I think that's pretty cool. We're still having ‑‑ we have single code base, but on two different platforms. Now then how about if we actually want to do something with the button? So we want it to be clickable. So if we go back to the storybook, we can see that there's a working button in both. And what that actually does is it works, but doesn't really do much. When you click it on either one, it actually locks to a console that pressed. So let's look at the code behind here. Because this is where we actually will start to see where you have to start to do certain things to still be able to work with a singular component. So let's open up the working button, and we can actually see that there's the on press event that then does the console block pressed. And it's actually being called. I don't have the command line open, but ‑‑ or available for looking, but I can verify that it does show up the press text. And this is actually what enables that. So what's happening here is because on react side, when we're using normal DOM elements, every element is clickable because you use them mainly through mouse. But on react Native, because it's always ‑‑ well, I'd say almost always a touch screen, it's called an on press event there. And if we actually just put on press here, it will complain because it will expect that the button is an html element button. And if we put on click, it might actually complain that you don't have the on press event, and on click event doesn't exist on react Native. So we actually have to do this kind of a platform check that, okay, platform, that's exported from you to the platform. What that does is it basically just exports a constant variable on which platform it is. It's a native for native and web for web. And then we do a check here that, okay, which one it is. And we apply the correct prop, whether that is on click or on press for react and react Native. And these kind of things can get a little bit complicated if you have, like, mismatch between prop names between react and react Native. You could easily do a handler for these or like a helper function to allow you to build these more easily. In this case, or you could just do typescript hacking a little, that will probably help work as well. In this case, I just wanted to know how, wanted to show you how it works under the hood. So it's not the cleanest, but you're still working in a single code, single file. So it's actually pretty easy to keep check up to actually understand even this conditional code and conditional props. Okay. So yeah, now we have, now we've shown how to do actually functioning components, how to style them so that they're still the same file, but serve from two completely different platforms. How about in a case where we have a, we have a component that is actually the implementation details between the platforms varies a lot. Well, let's, let's actually take a look at that. So let's go back to the storybook and we can see here that we have the WebView component and we open up that. It opens react advanced in a small iframe. And the same goes actually for the react Native app. But this is not an iframe because react Native doesn't have support for iframe. This is actually a component called react Native WebView that we're then just wrapping and assigning the URL as a, as a, as a parameter, as a prop. So, so let's look at the code a little more. Let's open up the WebView components here. And we can actually see a straight away that WebView.native and WebView.dsx are two separate files. So that tells us that, okay, there's a difference between the implementation between the two platforms. On the native side, we can see that that's actually a container. Well, that's just a wrapper that we imported from tags. And then we have errant WebView, which we see that is actually a WebView imported as an error in WebView from the package called react Native WebView. This allows us to use WebView on our react Native app. However, because react Native WebView is, as the name tells, it only works on react Native, we have to have a separate kind of implementation for the web version. So there we can actually see that the WebView component is just an iframe. And despite these being two different components, the WebView.stories automatically knows which one to import. And this would also work if you used it in a real react or react Native version. It would automatically know the bundle would know which component should we use. And hopefully this, you're finally getting the idea of how this actually works. It's really simple. Really easy. And in my opinion, way more maintainable than using, for example, having two separate code bases or adding react Native web to a react project. So yeah. Then let's talk about a little bit why this isn't the perfect solution. So you might have already noticed that there were no responsive design things. The iframe, for example, on the web didn't take the full page or anything or it wasn't matched. Same goes for the buttons. They were just automatically that width. That's partly because doing actually responsive design with style components is really easy. The problem is that react Native doesn't support those same responsive design tags like viewport and so on. Instead, there you have to monitor the viewport size manually through the javascript bridge and then change the styles based on that. So usually in those cases, you either have two options. Either you make a helper function to detect in the styles whether you're using whether the component is being used on web context or native context and you apply the responsive design tags based on that or you do a completely javascript based solution. Or then third, there's that you separate those two components into two different files. That also works. Another very similar thing is the animations. So react Native doesn't support web animations and react doesn't support the react animated library that well, at least. You can go around this using react Spring which is a cross platform animation library. We did this in one project. It worked relatively well. So it's possible. I didn't have time to show it to you. But you can find it in the repository. And then, of course, the last bit is the problem mismatch. So in some cases, like the on click, on press, you have the same exact prop basically. But they have different names. So you have to do this platform specific detection that okay, which one we are now and which kind of prop should we assign this function, for example. But in my opinion, those bad things, so to say, aren't that bad. So this kind of approach could actually be something I would highly suggest you to try in your project if you need to support both react and react Native platforms. One thing I want to mention about the component library in the project files, you can actually find a script to how to package this into an npm package so it strips out the platform specific code from the different distributions of the library so that you don't accidentally end up using react Native code or bundling that together with your react web app. But hey, yeah, that's all I have. Hopefully you've learned something new. And hopefully I got you interested in trying out this platform specific code approach. And that's all I have. Thank you. And I'll see you next time.