Moving Fast

Faster Iteration of UI components

Without diving into the app, we can use storybook to quickly render "dumb" components that don't manage any state internally with mock props. By leveraging the same tooling, we can quickly follow the web team who originally adopted storybook. Along with hot reloading, storybook dramatically accelerates our UI development cycle. Our designers can even easily tweak styling directly in storybook.

Easier React Native Upgrades

It was painful and time consuming to upgrade our React Native fork which fixes issues specific to our use cases. Nowadays, releases are more stable. Compared to spending days before, it only took us few hours to upgrade our fork to 0.55 from 0.53 recently.

However, our web team usually upgrades React and/or other shared dependencies faster than the iOS team. Being on different versions of shared frameworks may cause non-obvious problems which leads to time-consuming investigation. For instance, the iOS app encountered an instant crash in a full-release build although it ran fine locally. After bisecting commits on master, it turned out that the web-only webpack 4 upgrade broke the iOS build due to shared base configs. However, we were able to learn from those issues and apply the knowledge to our infrastructure which ultimately benefits all the teams.

Over The Air Patches (OTA)

A few days ago, we were able to quickly deploy a post-release fix for cameras and skip the approval process. We can’t even begin to count how many OTAs we’ve shipped. Being allowed more room for mistakes, engineers can ship often with confidence and avoid coordination, which unblocks everyone.

And More…

In the past three years, React Native has proven to be a great platform which allows engineers to move at an unparalleled speed. Getting it right has required a fair bit of learning, so we’d like to dive deeper into how we’ve learned and adapted to some pain points without sacrificing overall productivity.

Learn to Adapt to Pain Points

Like any technology, React Native is not perfect, but it excites us to see Facebook and the community at large actively working towards improving or eliminating its weaknesses like large-scale re-architecture and better flow type coverage.

React Native is certainly a revolutionary and fast-moving framework, so the challenges we face today are quite different than what we faced three years ago. For instance, while learning to reuse front-end tooling, we started with React Native Webpack Server, but after a year found out it was abandoned. We eventually had a non-trivial migration to Haul for React 16.

Next, we want to share how we conquered our top five pain points with React Native. Hopefully, it will help you too!

1. Immature Long Lists

Immature long lists have been a well known issue since day one. Without a doubt, we have encountered the same problem in our core component: the chat view. Alternatively, we use UITableView for smooth scrolling performance and dynamic cell heights. Furthermore, our chat view is extensively controlled by Javascript. It computes all the data sources in Javascript, passes them to Objective-C as properties, renders the entire table view in Objective-C via Yoga directly (the same layout engine React Native uses), and finally sends events back to Javascript for user interactions.

It’s worth mentioning that this chat view is so far the only native view we have, which means the hundreds of other of React Native components we have are able to provide a satisfying 60fps performance.

2. High-Priority Updates

Facebook is solving this problem by re-architecting the threading model:

It will be possible to call synchronously into JavaScript on any thread for high-priority updates.

We also found a quick workaround for high-priority UI updates while we worked on synchronous keyboard layout animation. All the keyboard layout solutions are one frame behind when start dismissing keyboard and therefore results in a noticeable gap between TextInput and keyboard.