There is no doubt that using React Native saves time. This rapidly growing framework from the Facebook team, allows you to develop fully-featured, cross-platform native apps with JavaScript. The biggest advantage to the programming language is that it saves programmers time. As a result, it drives down the cost to develop custom mobile applications. Moreover, if you’re already familiar with React.js, Facebook’s library for web applications development, you’ll find it easy to use. It uses the same component approach and mostly the same tools. This React Native guide is to give an overview of how to start developing in this language. It’s not a bad idea to acquaint yourself with native languages but it’s not necessary to start.
While it sounds good, there may be some obstacles along the way and you may be wondering what they are. It’s the little differences. I mean there are the same capabilities in React Native that there are in React.js but in React Native it’s just a little different. In this post, I’ll lay out some of the key differences and show you how to navigate React Native.
React Native guide: Key takeaways to get you started
Table of contents:
Set up
To begin this React Native guide, let’s look at the source. If you’re wondering how to start with React Native, lean on Facebook. Just like with create-react-app, their other brilliant contribution to the community is the boilerplate generator along with React Native command line interface, or CLI. These tools allow you to set up a React app by running a single command. Prepare to wait a while longer for CocoaPods dependencies to install. It’s definitely worth it, because CocoaPods, as an iOS package manager, lets you use tons of third-party resources for your future iOS app. When it’s all done you’ll get a file structure as in the picture above. Let’s dive in and go through files and directories that you might be seeing for the first time (I’ll focus on the essentials to kick off your project).
- android — in this folder, you’ll find a whole Android related codebase that will be used to bootstrap your app for Android devices.
- iOS — here is where you’ll find your Xcode project and all the files required to bootstrap your project for iOS devices.
- metro.config.js — it’s a default config file for Metro, which is a JavaScript bundler that comes with React Native.
- .watchmanconfig — that’s a config file for Watchman, a tool by Facebook for watching changes in the filesystem. React Native docs recommend you have it installed for better performance.
- index.js — an entry point for your React Native app sits inside. It was easy to predict, as easy as predicting that you won’t find ReactDOM anywhere inside. Since we’re working on a native app, there is no document object model as it is in web apps. From now on we will be working on native views and user interface components instead. What’s the implementation for it then? It’s using AppRegistry, an API provided by Facebook, that takes our app’s root component and registers it, so the native system can load the bundle and run it. What we should be aware of at this stage is a separation between reconciliation and rendering in React’s design. Thanks to that React Native and ReactDOM we can use their own renderers while sharing the same reconciler, provided by React core.
Combining ideas of React and DOM could ring a bell — what’s about Virtual DOM, one of React’s foundations? React Native provides a kind of similar mechanism which creates a tree hierarchy to define the initial layout and creates a diff of that tree on each layout change to optimize the renderings. For further reading, check out the layout engine called Yoga and how shadow tree, ViewManager, and UIManager works in RN.
Environment
With React.js it’s pretty straightforward. You develop your app to work inside of a browser and as long you’re providing performing code, it works well. When you’re developing with native devices in mind you have to be sure it will work on iOS, Android or both. In this part of this React Native guide, I’ll look at the tools that come in handy.
For Android devices, there’s Android Studio. For iOS development, you’ll have to use Xcode. Both pieces of software are free (Xcode works only on OS X though) but prepare for about one hour of installation and configuration process (RN docs list all the steps). Both are fully-featured development environments with lots of useful tools. The most important is the possibility to emulate/simulate native devices and test your app in its natural environment. You can choose from a range of devices to be sure it works perfectly on each one or even plug in a real device and test your app directly on it.
Will these two separate environments share a whole codebase so you could really develop two native apps at once? Partially yes. In most cases, about 90% of the code will be shared, but the remaining 10% has to be platform-specified and we all have to accept it. Here’s a pro tip I received when starting with React Native — focus on Android development, it’s always more error-prone. If an app will work on Android, it will almost certainly run on iOS. The rule doesn’t apply in the other direction, however.
Under the hood
As you can see, there’s no Webpack config file and that’s because there’s no need (in most cases) to include it in your development process. Babel is included by default though, so you can write either in ES6+ or use the older ES5 syntax. The RN docs include a list of supported ES6+features.
That’s for JavaScript, but for this React Native guide, we need to dig deeper. I’ll lay out the current rules of this mechanism but big changes to come very soon. New features will make the following explanation partially outdated. When this time comes, I’ll provide you a proper update. In case you are interested in the upcoming changes, feel free to research Project Fabric and follow the RN blog to keep up.
I’ll keep it as short as possible because giving you a detailed explanation of how React Native works is not a goal of this article. On the other hand, using any tool without knowledge of how it works is never a good way to go, especially for a developer. Therefore let me introduce you to the Bridge.
While using React Native we are actually dealing with multithreading. JS thread is what we are mostly responsible for. On the other, less familiar, the a side is location where native threads live. In between, we have the Bridge. It’s responsible for communication between JavaScript and native parts of an app. On their own, these threads are not aware of each other and do not share the same memory. Communication is through JSON messages. It’s happening in an asynchronous manner to avoid blocking the UI and to provide a satisfying user experience.
The initial loading of an app is made by a native thread called UIManager which loads the native modules (we will get back to that later). Our app’s logic sits on the JS side of a Bridge, but the results of user actions are sent to the other side. When it reaches there, native threads take care of it — firstly shadow tree gets the message and creates a UI tree, then Yoga layout engine calculates the changes to be made and finally view gets changed thanks to UIManager’s work.
We could jump into details but it’s not the case right now. More important is that the React Native architecture focuses on giving the best possible performance for your app, while allowing you to develop it in a way you want (as long as it’s a React approach). What’s more, the upcoming changes are going to make the whole process even smoother.
UI components
And now something completely different, a new way of thinking about UI elements. We stick to JSX syntax, however, we’re not rendering our code into DOM elements, but (eventually, on the other side of the Bridge) native modules. Provided components are in fact mapped native components, written in Java/Kotlin for Android or Objective-C/Swift for iOS (keep in mind that the components may look slightly different on both platforms, but all are fully customizable and supported with synthetic events and props of their own). Moreover, React Native APIs, which the docs list in the same place, allow you to use additional functionalities of native devices such as an on-screen keyboard, camera or clipboard to give users complete experience. Of course, there are numerous possibilities — third party libraries of components or even a chance to create custom native modules.
Take a quick peek on some of the most common components you’ll be using all the time.
- View — It’s a classic container, an equivalent of div. you can nest views in each other, styled and can have from zero to many children of any kind.
- Image — That’s a component you will use to display different types of images. You might need to use a background image in your app and, since background-image is one of the properties that are not supported, ImageBackground component will come in handy.
- Text — It allows you to display text. Whether you treat it as a header or paragraph depends on customization. And many, many more which you’ll learn while mastering RN.
Styling
In the final part of this React Native guide, we’ll look at styling. Remember that the DOM tree is no more a thing in React Native? With no DOM tree, there are no document-scoped styles (applied on body selector), so there’s no style inheritance by default. Styles in React Native are component-scoped. The most recommended tools to deal with it are StyleSheet and styled-components.
StyleSheet is a tool provided by Facebook’s team. It allows you to create actual style sheets as JavaScript objects. For a person experienced with JS, it will seem very familiar and intuitive way to apply it later. There is no concept of the selector (unlike CSS where it is a core idea) because programmers inject styles into each component separately. This way we no longer need to keep each class name unique.
The other tool I mentioned, styled-components comes straight outta web development (where it’s a popular CSS-in-JS library). Its syntax is a bit different, because the main idea here is about creating custom components with integrated styles. The common thing for both approaches is that no matter which tool you’ll choose, you’ll be dealing more with JavaScript than CSS-like styling. It brings lots of possibilities to add logic, pass properties and make styles of your app fully programmable.
A significant difference is in creating layouts. React Native’s layout engine implements flexbox and only flexbox. Fortunately, it is a great tool to create responsive layouts in a very intuitive and efficient way. What’s different is flex-direction defaulting to column and the flex parameter only supporting a single number. There are also some other styling restrictions in React Native we have to keep in mind. Among others:
- viewport dimensions and animations are available, but not as directly as it was.
- only measurement units you can use are pixels and percentage.
- there’s no gradients or media queries like we know.
Differences in styling will require you to develop new ways and techniques in order to keep it maintainable, consistent and understandable across the whole app. Digging more into the subject will bring you closer to conventions and patterns you should stick to.
Conclusion
That’s all for this React Native guide. What you already know about restrictions and new possibilities will be very useful while taking the first steps in React Native world. I guarantee that, along with your own research and framework’s further development, new possibilities will open up for you. You’ll get an ability to develop native apps for both major systems at once and save a lot of time while using skills you already have. Totally worth it.
