Sharing code between platforms: my approach to ReactJS and React Native
Technical Opinion

Sharing code between platforms: my approach to ReactJS and React Native

Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.

I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.

That’s where React Native lands. It has a slightly different motto: Learn once, write everywhere. It might seem the same but with a closer look, you’ll spot the difference: it’s still JavaScript code, but with a dedicated one for each platform. And that changes everything. Each platform has its peculiarities and user expectations vary from one to another.

React Native implements a bridge between web and native components. Instead of reinventing the wheel, it leverages the hard work designers and engineers at Apple and Google have done to release their native SDKs. As an alternative to having dedicated apps developed with Objective-C (or Swift) and Java (or Kotlin), you’ll have dedicated apps written in Javascript. This way it’s easier to process your application logic, store state and take use of the huge JavaScript technology stack, and still deliver the looks and feels of a native application, bypassing the use of WebViews by rendering native ones.

I-Love-Magic

At this point you might be wondering…

…the title said something about code reusability and this guy keeps talking development philosophy. Sorry about that, it’s part of the thinking process. I just want to emphasize: don’t expect full reusability on the UI components. You’ll be able to use a couple of generic widgets seamlessly across both platforms, but that’s the beautiful thing of React Native, it encourages and gives the tools to write dedicated UI code for each platform when needed: it’s as simple as adding a `.ios.js` or `.android.js` suffix.

React Native not only solves the performance issue present on other hybrid solutions, it improves the application quality with a native user experience.

Now let’s say you have already implemented a React web application. It’s up and running, you have used the whole Redux pattern stack, configured webpack for bundling, created actions, reducers, all HTTP requests for API integration, tests, etc. You don’t want to re-implement everything (even if it’s just copying and pasting from the webapp). It’s not just a matter of development time, you would have to manually keep track of updates on both of them, fix bugs on both codebases, and so on. Reusing code is a good idea in the short and long terms.

 

Sold! Tell me how…

You can easily inject your web application code as a dependency of your mobile code, using npm. This way you normally access your actions, reducers or helper functions from React Native as any other dependency. And further on, it’s possible to separate the logical part, that is shared between applications, in a different directory.

The view part will have to be done from scratch. Not only because it’s necessary to replace the HTML elements with React Native components, but also because the components will probably have a very different behaviour on the mobile app.

Wait a second, if all platforms share so much code, why don’t we put everything under the same codebase? Well, source code is not the only part of it, each project has a very distinct development environment, build scripts, tests and so on. They could actually reside in separate folders under the same repo: mobile, web and modules. But what if someone has to release a bug fix on a webapp component, it affects other devs that are only working on the mobile components and the other way around. That’s not scalable. Splitting is good.

 

 

Wrapping Up

React Native still has a lot to evolve and it doesn’t replace real native coding, yet. But it opens mobile development doors for a huge number of web engineers, that now are a few API docs away from building good-quality mobile applications. It makes possible to share most of the core logic between web and mobile applications, not only reducing development time, but also creating applications with a more consistent behavior. Together with a native look and feel, it improves user experience and product standards.

 

Interested on seeing a sample application on this subject? Drop me a line and I’ll be glad to prepare part 2!

About the author

Bernardo Smaniotto

Bernardo started working as a backend engineer at Cheesecake Labs and later joined the frontend team, working on ReactJS and AngularJS web apps.

Need a team for your projects?
We'd love to hear your ideas!

Connect with us!
  • Jonathas

    Good post!

    • Bernardo Smaniotto

      Thanks!

  • Cool stuff, here’s the drop for the second part 😀

    • Bernardo Smaniotto

      Sure, I’m already building some code samples, stay tuned! 😀

  • Nicolas Cuillery

    I’m a bit confused about the codebase. You prefer code splitting over a mono-repo architecture but, as an explanation, you linked this article https://code.facebook.com/posts/1189117404435352/react-native-for-android-how-we-built-the-first-cross-platform-react-native-app/ which clearly said the opposite :

    >One lesson we learned was that working across separate iOS and Android code repositories is difficult,
    >even with lots of tools and automation […] Fortunately, Facebook is moving to a unified repository for
    >both platforms — only one copy of common JavaScript code will be necessary, and syncs will be a
    >thing of the past.

    So what is your opinion then ?

    In any cases, thanks for the post. I’m totally interested in a part 2, having feedback about code reuse in RN is great !

    • Bernardo Smaniotto

      Hi Nicolas, thanks for your feedback.

      Probably I wasn’t clear enough. When I suggest splitting code among different repos, I mean separating business logic from view. So you would still have:
      – one repo for android+ios (as facebook suggests)
      – one for your webapp view
      – one for the shared logic (all your API requests, actions, reducers, helper functions, etc)

      I’m coding some repo samples and will write another post soon, so stay tuned! 😀

      • Nicolas Cuillery

        Thanks for the update, it’s clear now !

      • eXilz

        Thanks for sharing, I’ll be waiting for your examples because right now, I don’t feel like this is a very convenient way.

  • Aislan Maia

    Great post! I liked it!

    Just in time, I’m about to start a new project that will have to be deployed in web browser and mobile, and your approach seems really a good one. Looking forward for more detailed view on “separating business logic from view” in part 2. Keep up the blog posts! ^ ^

    • Bernardo Smaniotto

      Hi Aislan, thanks!

      Already preparing part 2 😀

  • Rafael Schär

    thnx a lot! cool, would luv to see a second part, it’s exactly what we are designing our architecture for right now.

    • Bernardo Smaniotto

      Hey Rafael! I’m really interested in your experience with this approach, anything that you found problematic? My main concern is it may force you to think too much ahead about whats going to be shared or not among views and logic. Although I didn’t go deeper about it in this post, it’s a good topic for the next one 😀

      Hope to hear back from you!

  • Manuel Dugué

    Really interesting topic you are discussing!!! And I’m curious how you would suggest sharing logo between react and react native. Can’t wait to see your follow up!

  • brianyang

    I would really like to see a sample application on this subject. It would be very interesting to see an example. Looking forward to part 2!

  • Leandro F

    Legal Bernardo! Sabe de algum curso em Florianópolis sobre o assunto?