Sharing a Codebase with React & React Native: The Holy Grail?

Rate this content
Bookmark

When we started building the Cleo app, we noticed that a lot of functionality, design and types were shared between web (React) & mobile (React Native). We investigated whether these could be shared within the codebase too… join me to find out what we discovered.

7 min
14 May, 2021

AI Generated Video Summary

The speaker discusses their experience with React Native app development and their goal to deliver high levels of product value. They wanted to build new features for both the Facebook Messenger and Native app, so they explored the possibility of sharing code between the two platforms. They attempted to share a file of branded colors using symbolic links and Yarn workspaces, but encountered issues. Ultimately, they decided to duplicate the shared code and rewrite it with strict type safety.

1. React Native App Development and Shared Code

Short description:

Hi, my name's Oli and I'm one of the front-end engineers and tech leads at Clio. I'm going to talk briefly today about one of the experiences we had when starting out our new React Native app at Clio a couple of years ago and specifically an experiment we did to try and achieve high levels of delivering product value and drive our mission to fight for the world's financial health. Clio started as a Facebook messenger chatbot where users could ask their questions about their money and receive responses about their finances. Clio needed a front end, and this came in the form of a number of React SPAs accessible through Messenger via web views and driven by our Ruby on Rails back end. However, there were two issues we identified with it. The first was that building on top of Messenger is quite a large business risk, and we were at the whims of Facebook and their app type for a savage personal finance manager living within their ecosystem. So, naturally as a small team of React developers covering the core product, we chose React Native to build out the next version of Clio. But back to the problem at hand, we now had users split between the Facebook Messenger and the Native app, both of whom we wanted to build new features for and both of whom we wanted to give the best possible product experience to. The question we posed to ourselves was, could we build this once within our monorepo and have it run in both the web and native products? Could we share the types, the business logic and the visuals across the two platforms, such that we halve the amount of work required to deliver new features? The short answer is not very easily, but please don't leave me there. We ran an experiment. We boiled this down to a single challenge. Would it be possible to share a single file containing a const object of our branded colors between the web and native app? As I mentioned before, we have a mono repo containing the web, the native app and the Rails back-end code, so any solution would need to work with that. Our first attempt involved SimLinks. Surely this could be as simple as using a symbolic link to reference the shared file within each project's route and within minutes we had the web rendering colors from the shared file. On to React Native. After some experimentation, we quickly ran into an issue. The first issue on the Facebook Metro Bundler, GitHub, Metro doesn't like SimLinks. We were about to spare one. Fortunately we hadn't invested too much time going down this route.

Hi, my name's Oli and I'm one of the front-end engineers and tech leads at Clio. I'm going to talk briefly today about one of the experiences we had when starting out our new React Native app at Clio a couple of years ago and specifically an experiment we did to try and achieve high levels of delivering product value and drive our mission to fight for the world's financial health.

To outline the problem we were facing, I'll start with a quick history of Clio. Clio started as a Facebook messenger chatbot where users could ask their questions about their money and receive responses about their finances. For example, asking about your balance or how much you spent on Ubers this month or receiving a push notification when you went over budget because you spent too much at McDonald's. And we quickly found that whilst the text and chat interface was great for engaging with Clio's tone of voice, it sucked for anything more complicated.

Clio needed a front end, and this came in the form of a number of React SPAs accessible through Messenger via web views and driven by our Ruby on Rails back end. You can see an example of what those web views look like on the screen shot on the right there. So Messenger worked great for us as we scaled up the product and allowed us to launch in the US and quickly grow up to a million users just in the space of a couple of years.

However, there were two issues we identified with it. The first was that building on top of Messenger is quite a large business risk, and we were at the whims of Facebook and their app type for a savage personal finance manager living within their ecosystem. The second was that Messenger was a big limit to the user experience we wanted to give our users. Clio needed the visual freedom to express herself as that savage friend who looks out for you and your money, and this wasn't achievable on Facebook Messenger.

So, naturally as a small team of React developers covering the core product, we chose React Native to build out the next version of Clio. We were able to upskill and start delivering Clio's React Native app in a couple of weeks, and we've been iterating on it ever since. Clio had a new home and you can see some of the early designs of the React Native app on the left, and fast forward to today's more recent designs and an example of how we've really taken advantage of breaking out the bounds of Messenger.

But back to the problem at hand, we now had users split between the Facebook Messenger and the Native app, both of whom we wanted to build new features for and both of whom we wanted to give the best possible product experience to. So when evaluating two designs, such as the one shown on this slide, we started seeing similarities in what we wanted to build and deliver, here both showing lists of spending grouped by category, both coming from the same API and both with the same TypeScript typings and even looking the same, the same icons and the same way of presenting information.

The question we posed to ourselves was, could we build this once within our monorepo and have it run in both the web and native products? Could we share the types, the business logic and the visuals across the two platforms, such that we halve the amount of work required to deliver new features? To us, this was the Holy Grail, a miraculous power that provided happiness, eternal use in an infinite abundance. The short answer is not very easily, but please don't leave me there. We ran an experiment. We boiled this down to a single challenge. Would it be possible to share a single file containing a const object of our branded colors between the web and native app?

As I mentioned before, we have a mono repo containing the web, the native app and the Rails back-end code, so any solution would need to work with that. Our first attempt involved SimLinks. Surely this could be as simple as using a symbolic link to reference the shared file within each project's route and within minutes we had the web rendering colors from the shared file. On to React Native. After some experimentation, we quickly ran into an issue. The first issue on the Facebook Metro Bundler, GitHub, Metro doesn't like SimLinks. We were about to spare one. Fortunately we hadn't invested too much time going down this route.

2. Challenges with Yarn Workspaces and Shared Code

Short description:

Our second attempt lied with Yarn's workspaces. Setting up the shared file as a package and adding that dependency and native projects turned out to be more complicated than expected. We got into a rabbit hole of issues, from hoisting dependencies to fixing version mismatches. It became clear that investing more time into this approach wasn't worth the minimal impact it would have. So, we decided to fall back to our original plan of duplicating shared code where needed. However, we took the opportunity to rewrite the code with strict type safety. If you have any ideas on how to tackle this problem, please let me know.

Our second attempt lied with Yarn's workspaces. Our theory was that setting up the shared file as a package and adding that dependency and native projects would allow them to be bundled. Not so simple, it turned out. In the few hours we timeboxed for this, we got into a rabbit hole. No hoisting native dependencies, updating Metro Bundler config to handle those hoisted SimLink dependencies, updating continuous integration and deployment scripts to handle the changes, deduplicating hoisted dependencies and fixing dependency version mismatch between the web and the native app. The list was growing and it started to feel like a bit of a Star Wars meme.

We were getting somewhere but starting to lose sight of our initial purpose, to be able to deliver features easier and quicker to users, to really drive that product value and deliver our mission. It felt like a good time to lean on our engineering principles. Do the simple thing first. Innovate in our product and not our tech stack. And tech that can be helpful and useful. I think reading those it quickly became obvious we'd probably overstepped the mark a bit. And as you can probably see where this is going, our search for this mythical Holy Grail was a bit in peril. And whilst we were sure it was possible to achieve, it was becoming quickly obvious that the continued time investing to set up and maintain this probably wasn't worth the tiny impact that it might have given us.

So we fell back to our original plan of duplicating shared code where needed. This didn't turn out to be such a bad thing. Like, rather than just copying and pasting the code, we took a chance to rewrite it with full strict type safety enabled. But if anyone has any ideas or thoughts on other ways we could tackle this problem, I'd love to hear from you, either in the Q&A session or feel free to ping me on my email. We're always open to new ideas and improvements in how we deliver features at Clio, and it would be great to hear from you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn