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

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.

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.