Kashish Grover

Posted on Apr 22, 2018

Bootstrapping your React Native App

#firstpost #reactnative #javascript #appdev

Well, hello there. This is my first post here at Dev.to, and I am excited to be a part of your community. 😇

I have been playing around with React Native for a while now and I love it. Not a day goes by where I don’t think about how cool this world of hybrid apps has become. It’s currently on version 0.55!

Production apps are built around something which is on version 0.55, you ask? Well, yeah. So many companies are using it. Instagram, Myntra, Treebo, Airbnb, Uber, and Facebook of course. But what’s the big deal? Why is there so much hype around it and why am I here today writing to you?

Why React Native?

The most important thing is that your app will implicitly support iOS and Android through one single codebase. You save time coding, and you save money hiring.

Not just that, if your ecosystem involves you using React already, you can make sure that most of your apps, whether web or native, look and work the same way.

Also, it’s a myth that you need to know React before you start with React Native. I started with React Native. :)

I won’t tell you how to make an app.

Well, figure it out. I have been trying to along with so many other people even today. Google it, find out how to do things, visit Stack Overflow, GitHub issues, and even join slack channels with developers who might be able to help you figure out why you are stuck and what you can do. Talk to your peers because half of your problems are JS related anyway.

So many times you will realise while coding an app in React Native — there might not be a right answer to your problem, yet. But I guess in my opinion, that’s the fun part. How often do you otherwise see issues a couple of weeks old with comments just a couple of hours old for a problem you are trying to solve? You are not alone.

Meanwhile, amazing developers around the world are building some of the most amazing libraries for you. Take React Navigation for example. A once hated library, it has gained momentum to a point where just a few months ago, it was on 0.something.beta27. It’s almost at version 2 right now with almost everything you may need for your navigation hiccups.

Isn’t that crazy?

I’m here to help you make decisions

There is so much going around in the React Native world that it is rather hard to keep a track of everything. As someone who is just starting out, you may ask me — where the heck do I begin?

I would have only one advise — start building, today itself, and get cozy. It gets really easy really soon. You will find yourself going to Facebook’s React Native docs really often, so bookmark that first thing.

Starting up

Way 1: Install Expo’s XDE to initialise and run your project — Just visit https://expo.io/ and they will help you. Their documentation is one of the best I have read.

You can also globally install create-react-native-app (CRNA) and do

$ create-react-native-app my-app
$ cd my-app
$ yarn start

And that’s it! you can go ahead and now use it with Expo’s Android/iOS app or you can use a simulator on your machine to run your new project on.

Deep into your app development, someday, you may realise that this new feature you want to build doesn’t have any API’s available for in react native yet, and you would like to write your own native code for iOS and Android. That day, you can always choose to eject your project. You can find a full tutorial around it here. 🙂

Way 2: The bare-bones

To keep your dependencies low, you can also initiate your app using the react-native-cli.

Install react-native-cli
$ react-native init AwesomeProject
$ cd AwesomeProject
$ react-native run-ios or $ react-native run-android
Change code and have fun

Android/iOS: Which way to go?

When you are just starting out, don’t think about your target platform. Think about your business logic first. But then even if you’re not actively focusing on both platforms, try to build for them together.

Don’t assume that it’s cross platform and you’ll do iOS first and Android later. Well it is true that it is cross-platform. But there still are a lot of little things like iOS and Android handling margins differently, or Android using elevations instead of box shadows.

Even though these may be small things, handling them concurrently is the way to go. But at the end of the day, it depends on what devices you have. If you use a linux/windows/android ecosystem and don't have a Mac or an iPhone, you clearly will build for Android. :P

Parts of your app

Components

Start out with React Native’s own components, and use them heavily. You have View, Text, Button, Touchables, ScrollView, KeyboardAvoidingView, WebView, Flatlist — basically all the kinds of components you will ever need for your app. All UI libraries are simply based on these components.

Just like Bootstrap, Material UI, etc. for web, you will find a few libraries available for React Native too. One of the most popular ones is Native Base. We at Treebo are also building a complete library for both React and React Native. We call it Leaf UI, and it is our open source gift for the community.

The whole point of these UI libraries is that they ease your job of applying certain kind of components — like Toast notifications. You might end up spending a lot of time if you try to make them yourself.

But always remember that no matter what, simplicity is the key. The more the dependencies, the harder it gets to keep a track, and you don’t want to end up in a dependency hell. That’s why a best practice is to have your own auxiliary components. For example, create your own Button which internally returns TouchableOpacity from React Native or the Button from Native Base. Tomorrow if you find a better solution, you will just have to change one file.

Handling Images

Images might be a big part of your app, and React Native has an Image component which easily renders local and remote images. One thing you should remember is that there is no native support for SVG’s available and that is a very sad thing. :(

We do have a library called react-native-svg available, which lets you write custom SVGs. But this will limit you a lot because you cannot render locally stored or remote SVG’s, and you will have to write them yourself. A not so great alternative to rendering SVG’s is to use WebViews. This would be performance heavy, so you are better off using PNGs or JPEGs here.

Sad? Well I have found one solution for SVGs which fits my need. It’s this awesome CLI which I found a while back which converts SVG files to React Native Components which you can use with react-native-svg. I don’t know how scalable this method is, or in how many cases it will work well. But I have used it rather heavily. :)

For icons, a lot of people use fonts. You have a library called react-native-vector-icons which uses fonts. You can use your own fonts too! Check out Icomoon.

Navigation

Navigation is one of the most important aspects of any app. It is also something which isn’t provided to you out of the box in React Native.

It is extremely important to do this right since the beginning because the whole skeleton of your app will depend on navigation. I highly recommend React Navigation. I remember how difficult it used to be to use it when it was still in its beta phase. The documentation was super confusing too, maybe it still is for beginners. Since then it has seen a tremendous amount of contributions and as of recent, it is at a release candidate version 2.

To navigate from one screen to another, you simply pass navigation as a prop between components and do this.props.navigation.navigate('CoolScreen');

Take the following example of the boilerplate that Expo gives you.

Here, you see three screens and a TabBar at the bottom. The TabBar is a navigator which controls these three views. In React Navigation, you can nest your navigators. Also in any navigator, you can mount any number of screens.

So the code looks like this:

Here, your TabNavigator is used as a screen in the RootNavigator. You could nest them like this or in any way that suits your logic. :)

If you think this library is not for you, there are a few other options which are as follows:
— React Native Router Flux
— React Native Navigation
— React Router Native

State Management

There are two types of data that control a component: props and state. props are set by the parent and they are fixed throughout the lifetime of a component. For data that is going to change, we use state.

Your whole app can be built around component specific states which are communicated between children and parents through props, or you can take help from libraries like Redux and MobX. There are other options too, but these two are the most popular.

It completely depends on you, and how vast your app might be by the number of features. Using internal states is really easy to understand and use, but it gets difficult to track at scale. Imagine having a hundred screens using a hundred components. And now imagine using internal states here. And that’s why the likes of Redux or MobX were created. These sit on top of your whole app and provide you with stores and actions, which can be used by any of your components
whenever needed.

I like both MobX and Redux, and I would be just fine using either of them. Use the one that fits your use case.

Data Storage

Redux and MobX both provide you with Stores, which are basically entities which store your data when you make calls to the API. This store is shared across components and make sure that all your data is available to you when you need it. They are saved in the memory, and are not persistent.

For persistent data, you can use databases or text files as usual. AsyncStorage of React Native is an API which works on top of a database. It stores key-value entities in your system. You will find yourself using this heavily for storing things like authentication tokens, persistent app states,
etc. For example, keeping track of an intro screen which you show when the app is run for the first time.

Styling

Styling is rather straightforward. Think of CSS but in CamelCase instead of kebab-case. This is available to you through the inbuilt StyleSheet API.

If your plan of action also includes making a web application using react, you can very well use a popular library known as Styled Components. This lets you easily write styles using tagged template literals and CSS. This results in a 1:1 mapping between your style and your component, making it much easier to keep a track of.

The StyleSheet Way:

The Styled Components Way:

Which one do you think is more scalable? 😉

Networking

To load data from the internet in your app, you need APIs to talk to it. React Native implicitly gives you support for fetch and WebSockets. Read the full tutorial here.

Let’s talk about DEV Experience

I have so much fun building using React Native primarily because of my
ecosystem. On my primary monitor I have VS Code and the simulator. On my
secondary monitor, I have my logs and debugger.

Project Structure

Project structure of your app is important to be figured out before you start
developing it. There are a two well known alternatives, and they both have their
advantages and use cases.

Folders by feature

This should be your go-to project structure when you are
talking about scalability. If your app has fifty features, you are better off
keeping files related to all these features in separate folders. This makes
finding files super easy.

Folders by type

This is the most common structure you will see being used in
boilerplates. Why? Because boilerplates don’t have enough code to split it by
feature. So here, you would split your files under Components, Containers,
Screens, Assets, etc. So in summary, this works great for small projects with
less features.

Bug tracking

Tracking bugs in production cannot be taken lightly. I recommend either Sentry or Bugsnag for React Native. Even Play Store will give you bug reports but it’s better to have one place to track all your bugs.

Debugging

For using the in-app developer tools, you can go through the tutorial given in the docs here.

VS Code and React Native Tools

React Native Tools is an absolutely amazing extension for VS Code. So many people simply use VS Code as a code editor. With tools like this, it can become a debugging powerhouse.

Using React Native tools, you can easily debug your code by putting breakpoints or watches, quickly run react-native commands from the command palette, and use IntelliSense to browse objects, functions and parameters for React Native APIs.

Linting

Do yourself a favour and use a linter. I use eslint. Yes, it gets annoying at times but over time you will automatically start writing correct code. This will simply prevent you from making stupid mistakes. It will tell you when you should have written a component as a functional component, or when you defined a variable and never used it.

Keep your codebase clean, and be a great host to a new developer who starts working with you on this project tomorrow.

There is so much to React Native. Here in this humble post, I have barely tried to scratch the surface. I have tried to talk about things that I know about in a summary. I hope this gave you an insight of the possibilities, and that this is enough for someone who is just starting out.

I am no master at React Native, and there is probably a lot that I missed out in this article, but I just wanted to share my experience. :)

If you have any questions, do ask me, and I will try my best to answer them.

Thanks, human. Now let’s get started.

Top comments (8)

Andrew Emerson • Apr 23 '18

Nice post and a good React Native primer. I work as a native Android/iOS engineer and will be taking the leap with my colleagues into RN in the near future.

Do you have any feedback on the "native feel" of apps built in RN? Any limitations where you would be better off using the native platform directly?

Kashish Grover • Apr 23 '18

Thank you so much for appreciating. Regarding the native feel, React Native does it good justice. A lot of companies who have started using it heavily did not shift the whole product in one go, but they did it feature by feature, screen by screen.

On that note, if you ever feel like you need to go native for something which might need some performance heavy lifting, you can always make your own APIs to suit those needs. :)