The 80/20 of React Native

When building a React Native app, what twenty percent of your effort brings eighty percent of the result? After building my first app with React Native, three axis immediately popped out: static typing, versatile components, and lean deployments. To test my hypothesis, I thought it would be fun to implement the DO UI Kit from InvisionApp as an iOS and Android app. And this experiment led me to build a premium start kit for React Native that can be used as a turnkey solution for new React Native projects.

The React Native DO Starter Kit

React Native and its ecosystem has brought us with such a level of productivity that the task of going from a Sketch file to an actual app is becoming almost trivial. But at the condition that you rely on the right tools. So what twenty percent of efforts will bring eighty percent of the result?

Static Typing

Not using Flow or Typescript will produce substantial technical debt in your project. These type systems are a must as they enable you to smoothly scale your codebase over time. The ability of refactoring your code with high confidence is a critical element of keeping your development cost efficient. I always try to put the maximum pressure on static code analysis. As described in a previous story, I use types as a single source of truth between different components. And every time I stumble over a bug, I ask myself: “Could this have been caught by static analysis?”. If the answer is yes, I refactor the code accordingly.

I used both Flow and Typescript to build React Native apps and I’m slightly leaning over Flow simply because of its integration within the React ecosystem. Flow integrates seamlessly with any existing JavaScript code which lowers the barrier to entry when prototyping. On the other hand, TypeScript does seem to provide safer type environment: because it does not integrate out of the box with vanilla JavaScript code, it forces you to think more about your types than Flow. I also noticed some other differences. For instance, Flow doesn’t force you to declare the props type of your component. Hopefully issues like this one can be mitigated with eslint in order to make certain Flow annotations mandatory in your React code.

Versatile Components

Which base libraries every React Native project needs? A state management library, a navigation library, and a UI library. These need to be chosen carefully. For state management, I’ve always used MobX and have no experience with Redux so any comparison from me would ill-advised.

For routing the different screens of your app, React Navigation is a well-designed and robust library, quickly becoming the de-facto standard. I was previously a user of react-native-router-flux and React Navigation won me over quickly. The library seems to provide the right primitives needed to build your app navigation.

While there are many UI libraries available for React Native, NativeBase is arguably the leader in that category. NativeBase provides a large collection of cross-platform components that can easily be customized. And these characteristics are important: not only the number of use cases covered by this NativeBase is substantial, but it also provides a powerful theming system. After installing NativeBase, you can run a script that will install a default theme for your components. From there, you can edit the theme files as you wish in order to implement the visual design of your app.

Providing a Custom Theme to NativeBase

Lean Deployments

Use create-react-native-app to bootstrap your project. The generated project uses expo. Thanks to expo, you don’t need to install XCode or Android Studio to develop your app. The different development versions of your app can be shared to beta testers very easily via a link or QR code. As you go further in your development, you might want to “detach” the project in order to have your custom built setup. This is useful if you need to write custom native code for instance. However, expo covers a lot of use cases and it is possible to publish a full-fledged app on the Apple App Store and Google Play Store without “detaching”.

Lifecycle of an Expo Project

Last but not least, expo enables you to update your app instantaneously in the same manner as updating an HTML page. No app store update needed. If your project is “detached”, you can still update the JavaScript bundle of your users in the same manner. These types of seamless updates have always existed for the web and they are now possible in mobile apps.

That’s all

Do you agree with my 80/20 analysis? I look forward to reading your feedback.