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

Hello, everybody! My name is Perttu Lähtenalahti, 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ähtenalahti. 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 beautiful Helsinki, Finland.

I have a website, perttu.dev. You can find this presentation as an article there. And 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 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 that's going to be it. And 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 and 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 more later 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. We're not going to use React Native web, which I think 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 cloche 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 building a real application. So, yeah. This project or this approach that I'm going to show you is actually based on a customer approach that I did a little bit of time ago. So, that customer, I can't mention the name, but it was a big government-owned news organization and they actually had three React native apps and one web app that was powered by React. Basically their main website. And they were serving, I'd say, cloche, maybe even over a million people every day, so the user amounts were huge.

And they asked, 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. And there were a few requirements, so despite having these three or four different platforms, four different apps, they actually wanted a single codebase. 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 the same despite you using it on a different app, different native app, different web app, and so on. And the 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 have used React Native and perhaps even React Native Web are now at this point wondering that, 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 and the companies 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 project. And also in case we were kind of limited also by this 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, 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 Vue, 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. The difference comes from that the other one is of course managed by Webpack 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 are still separate components in separate parts. 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 built, it's a basic React native pipe 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. This is the two separate storybook instances. You can see the basic button there and you can see the basic button on the mobile as well.

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 see that single file that is currently if we look into the .stories file, we can 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. And you can see 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. That's really simple. It's just exporting variables like heading1 is equal string h1. And React actually is quite smart and can handle these as the tag names straightaway, 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 opposite, and then we're assigning them the same names we have on the text side. So, we have the heading1, it's always a text component. And that actually allows us to build the thing. So, we're exporting these two components in the component and using them. And then when React takes this component, it checks what is pop opacity for React and what it is for React Native.

And then when React takes this component, it checks what is pop opacity for React and what it is for React Native. And that works. This is almost stupidly simple. But it works really well. As I mentioned, we've been running this in production for millions of people.

Next you might be wondering, how do I actually 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 there is a blue button. On the React side, we can see there is a blue button as well. The styles are a little bit different. React Native has a flex one by default. So, it takes all the available space. But they still work the same way. So, they don't do anything. But they are clickable.

So, then let's look at the code behind that. And this is actually where the style components comes into play. 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 button element and the button text. But actually, those components are not the same that we imported from the text. But instead they're here below. And using the styled constructor, we're passing the button opacity and the paragraph element, the styled 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 styled 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.

And I think that's pretty cool. We're still having we have similar 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, it actually logs 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, 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 you 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 platform check that, okay, platform, that's exported from YouTube platform. It basically just exports a constant variable on which platform it is. It's a Native for Native and web for web. And we do a check here, 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 would probably help work as well. In this case, I just wanted to know how, wanted to show you how it works, like, under the hood. So it's not the cleanest, but you're still working in a single file, it's 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 served from two completely different platforms. How about in a case where we have a component that is actually the implementation details between the platforms varies a lot? Well, let's actually take a look at, so let's go back to the storybook and we can see here that we have the web view 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 web view that we're then just wrapping and assigning the URL as a prop. So let's look at the code a little more. Let's open up the web view component here and we can actually see 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 tax. And then we have errand webview which we see that is actually a webview imported as an errand webview from the package called React Native WebView. This allows us to use a 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 you can see that the webview component is such 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 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 I frame, for example, on the web didn't take the full page or anything or it wasn't matched. The same goes with the buttons. They were just automatically that width. That's partly because doing actually responsive design in 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. You either make a helper function to detect in the styles whether you're using whether the component is being used on that context or native context and you apply the responsive design tags based on that. Or you do a complete JavaScript-based solution. Or then third, you separate those two components into two different files. That also works.