So, You Wanna Get Hired as a React Native Developer

Thoughts on learning React Native from interviewing & hiring React Native engineers

Though there are more choices than ever in cross-platform mobile development, React Native remains an excellent way to build high-quality mobile applications while leveraging skillsets and technologies (and sometimes even code) that many in your organization may already know.

One of the most common questions I see on React Native forums is people asking how to start learning React Native. Because React Native is a bit more of a niche technology than React itself, there’s much less written on the topic and a great deal of what’s out there is out of date.

In this article, I’ll discuss how developers can get started with their efforts to land a position as a React Native developer, based both on my experience in learning the framework myself, and in interviewing and hiring other engineers.

Priority #1: Learn React

This is simply the most important factor: if you are a strong React developer joining an existing React Native project, you can be productive from day one. That doesn’t mean you’ll be a project lead on your first day, but you should be able to make meaningful contributions to a React Native codebase almost immediately.

Most likely, 90% of your work on a React Native project will be exactly the same as your work on a ReactJS webapp. In fact, as a hiring manager interviewing candidates for a React Native position, I do not really care if you have React Native experience, provided that you are solid in working with React.

So what does is mean to learn React inside and out these days? You should understand and be comfortable discussing all of the following:

• Learn the core React concepts like components, JSX, the virtual DOM, etc.
• Learn everything you can about functional components and hooks. Love ’em or hate ’em, hooks are a core concept in modern React development.
• Understand how to master API integrations (fetch, Axios, etc) and state management (Redux, Recoil, MobX, etc)

Priority #2: Learn the Differences

Once you know React, it’s time to brush up on the differences between React on the web and React Native. You don’t need to memorize all of this–just be aware of it and know when to consult the documentation. Most of these differences you’ll pick up on easily just by spending some time with a React Native project.

No HTML DOM Tags

This one is easy, but fundamental: you’re not working with HTML anymore. Instead of HTML DOM tags like <div />, <p /> , <img /> and <a /> , in React Native you’ll get used to using some RN component analogs: <View />, <Text /> , <Image/> and <Button /> . These native components are similar to, but not exact copies of their web-based equivalents, so be sure to consult the documentation to understand their props and behaviors. A full list of core components is available in the React Native documentation.

Specifying Styles

One of the biggest differences between React & React Native is styling and layout: React JS on the web, at its core, uses familiar CSS styles and classes the same way you would in any HTML page. React Native, on the other hand uses inline styling that looks more or less CSS-ish, but has some different syntax and different behaviors.

Out of the box, React Native components typically use inline style props instead of class-names. The short example below shows the differences between typical styling in the two environments:

/////// React on the web ///////
// styles.css
.box { background-color: #f00;}

// Component.jsx
<div className="box" />

/////// React Native ///////

// Component.jsx
const styles = { box: { backgroundColor: "#f00" }}

<View style={styles.box} />

Differences to note here are:

• In RN, the style property is an object containing the style specification
• The style declaration keys are camelCase
• Though it looks like CSS, it’s not–not all CSS declarations are supported, and some things behave differently

For exact details on what is and what is not supported, see the documentation on styling in React Native .

As with React on the web, there are packages available to help simplify and organize styles. Styled Components are a great way to help organize your styles, and have the added benefit of largely standardizing the usage and behavior patterns between React & React Native.

Layout

Layout in React Native is somewhat stripped down from what you can do on the web, but in my opinion, is much simpler: all layout is done with Flexbox. Get familiar with how display: flex works on the web and you’ll have a good understanding of how layout works in React Native.

On occasion, you will most certainly come across some behavior that is not quite the same as you would expect from CSS & Flexbox on the web. A couple of examples from the React Native documentation:

Flexbox works the same way in React Native as it does in CSS on the web, with a few exceptions. The defaults are different, with flexDirection defaulting to column instead of row, alignContent defaulting to flex-start instead of stretch, flexShrinkdefaulting to 0 instead of 1, the flex parameter only supporting a single number

and

In some cases React Native does not match how CSS works on the web, for example the touch area never extends past the parent view bounds and on Android negative margin is not supported.

Similarly, you may find minor differences in layout and behavior on Android & iOS. Just be aware of the potential for these differences and test your app and layouts accordingly.

Animations

Animations are, to some extent, an extension of “styling & layout”, but they deserve to be called out separately. On the web, you might be used to implementing animations directly in your CSS, or possibly using a JavaScript library built on top of CSS animations. In React Native, you’ll need to take a different approach, using either the built-in Animated API, or a third-party library such as react-native-reanimated which both function in a similar matter.

These APIs work by constructing style attributes containing dynamic parameters computed from “animated values”. Here’s a stripped down sample from the Reanimated documentation, showing how a useAnimatedStyle hook is used to animate an Animated.View component:

// when the button is clicked, animate the offset from 0.0-1.0,
// use that offset to compute a transform.

function Box() {   
  const offset = useSharedValue(0)  
  const animatedStyles = useAnimatedStyle(() => {        
    return { transform: [{ translateX: offset.value * 255 }] }  }
  )  
  
  return (<>      
    <Animated.View style={[styles.box, animatedStyles]} />            
    <Button onPress={() => (offset.value = 1.0)} title="Move" />        
  </>)
}

The built-in Animated component works in a similar fashion, though I recommend using Reanimated due to enhanced functionality and performance. Notably, Reanimated allows the use of isolated JavaScript worklets which can run on the native applications main UI thread, enabling a higher frame rate and better interactivity with touch events.

One other note on the example above: the “transform” style property is different than its CSS counterpart, so be sure to consult the documentation to understand how it works.

Events & Interactions

Event handling and interactions are very similar in principle to React on the web, but the details are very different: the specific events fired by individual components are not the same. In particular, you’ll want to use specific native components to handle interactions–you cannot simple add events like onClick to any tag the way you might be used to with HTML. In fact, you won’t be dealing with “clicks” at all, but instead with “touches” and “gestures”. Furthermore, these events are only available on certain native components such as Button or the more general purpose Touchable . The React Native documentation goes into more detail on using these touchable components.

The Development Environment

This is probably the first difference you’ll encounter working with React Native, but that doesn’t mean you need to understand it all upfront. You’ll probably startup your development environment by running either react-native run-ios or react-native run-android , depending on your platform of choice and how the project is setup. From there, you’ll get all of the familiar functionality of running a React webapp. You’ll be able to edit your code and styles, and see them hot reload in realtime.

There are some notable differences in the development environment, however, from React on the web. First, you’ll notice right away that you’ll be running your app in the iOS Simulator or the Android Emulator, rather than in a web browser! This shouldn’t be a surprise, but if you’re not already familiar with these tools, take some time to browse around them and see how they work: note the ability to configure and emulate certain device functionality and sensors. That will let you interact with your app the same way you would on a device.

Also different is that React Native uses the Metro bundler instead of Webpack. For the most part, this difference should be invisible to you–but if you happen to need to debug your bundling process, clear your cache, or make a configuration change, being familiar with Metro should at least give you some clues as to where to look.

Debugging Tools

Debugging with React Native is generally quite similar to debugging on the web, with some gotchas. In general, it’s possible to use the Chrome or Safari development tools to debug your React Native application, but you may also opt for the standalone react-devtools .

Some of the gotchas:

• Some projects use a different JavaScript engine, and the debugging tools and workflows may differ a bit depending on which you use. As always, consult the documentation
• You may come across modules with native functionality which don’t play nicely with the debugger or require a slightly different workflow. For example, the Reanimated worklets described previously cannot be debugged with the standard debugger.

In short, be aware of the rules & limitations of the JS engine and dependencies you’re using, and find a tool & workflow that works for your project.

Priority #3: Dig into the Build & Deployment Process

If you are joining an existing React Native team and project, you probably won’t be the one responsible for the build process and deployment on day one, but it’s an important area to get familiar with.

Note: If you happen to use the “Expo workflow” (discussed in more detail below), you may find that it takes care of most of the build process & deployment issues for you automatically (at a cost of some flexibility).

As you dig deeper into your React Native development, you’ll want to familiarize yourself with the native build tools for each platform: Xcode and Android Studio. The truth is you can get quite far in your development process without touching these tools, but at some point, you’ll likely need to fire one up to run a build or to change a build setting.

Both Xcode and Android Studio are complex tools that you won’t master right away, but I recommend just familiarizing yourself both of them by opening up projects, doing builds, learning how to modify build settings, etc.

Other Topics to Be Familiar With

There are a number of other topics you’ll need to be familiar with as a React Native developer, even if you don’t necessarily deal with them on a day-to-day basis. A few of these topics are discussed briefly below.

Expo vs “Bare Workflow”

As soon as you start doing any React Native development, you’re likely to encounter Expo, which is a set of tools and workflows to help accelerate React Native development. Expo does some cool things, like enabling over-the-air app updates and managing the full build process so you don’t need to work directly with Xcode or Android Studio as much. The tradeoff is that you give up some control over your build process and project settings.

I personally prefer not to use the Expo workflow in my projects, but that’s a personal preference based on the kinds of apps I’ve worked on. A reasonable approach is probably to use Expo until you have a reason not to. At some point, for example, you may wish to make some Xcode project modification that is not exposed or supported by Expo. Or some native modules will require you to make changes to your native project files. That’s probably your cue to “eject” from Expo and manage the project files and build process yourself.

One side note on Expo: their team also develops a number of useful React Native modules for things like audio support, asset management, OpenGL, and much more. These modules are published by Expo and have dependencies on their “core” module, but don’t actually require the “Expo workflow”–so you may well end up “using Expo”, even when using the “bare workflow”

FlatList

At some point in building a mobile app, you’re likely to need to display a long list of items. The naive approach, of rendering all of your items into a scroll view, is likely to encounter major performance problems as your list grows. Instead, you should familiarize yourself with FlatList , a component that recycles views and renders only what it needs for what’s being displayed on screen, similar to RecyclerView on Android or UITableView on iOS.

React Navigation

Navigation is another area that can be very different between a React webapp and React Native. While React webapps often use a library such as React Router, most React Native apps use a library called React Navigation. You’ll want to familiarize yourself with the library, as well as common native navigation patterns like stacks, modals, tab bars, and drawers, each of which use their own separate sub-libraries.

Native Modules, Native Components & the JavaScript Bridge

You probably won’t be writing native modules and components as a new React Native developer. In fact, you may never need to do so. But you should have a good understanding of how React Native works and how it connects JavaScript code to native functionality.

In short, React Native lets JavaScript communicate with and control native code using the JavaScript Bridge. The Native Modules system is the interface that exposes native code to JavaScript (via the bridge). Native Components are actual native views wrapped up to be exposed and used as components in Component. Consult the documentation if you need to go deeper on these concepts or build your own native integrations.

JavaScript Runtime & Hermes

When working with React Native, you may come across references to Hermes. Hermes is an alternative JavaScript engine you can opt into using for your RN app.

You don’t need to know the ins and outs of Hermes or how it works — but the key takeaways are 1) it exists and some projects use it, 2) it should perform much better than the default JS runtime, 3) there may be subtly different behaviors, 4) it may modify your build and debugging process slightly. My advice here is to use Hermes, but test your app thoroughly and make sure you can build & debug as needed.

The “New Architecture”

As you start working with React Native, you’ll start seeing references to the New Architecture. The New Architecture to a set of major architectural improvements to RN, notably in the module system and in the renderer. These changes are, at the moment, labeled as experimental and entirely opt-in.

As with Hermes, it’s important that you are aware of the new architecture, but you most likely won’t need to do anything about it in your app for the time being, unless you are involved in fairly low level work. For further reading, see the React Native documentation on “Adopting the New Architecture”.

Your Crash Course is Complete

If you have a good understanding of what’s outlined in this article, you fulfill the criteria I look for when interviewing React Native engineers–even if you’re not an expert in every aspect, and even if you don’t have previous professional React Native development experience.

Best of luck on your journey in learning React Native and landing a new position!