Be native in React Native

How I transition to React Native from my knowledge of React.

This article is written as an individual review assignment for PPL CS UI 2021.

Disclaimer: This article might need at least a little knowledge of React, JavaScript, and software development in general.

The Essence

What is React Native?

If I can describe React Native in six words, it would be the hybrid mobile development version of React (hybrid means compatible with both Android and iOS).

A React developer’s transition to React Native is smooth like butter, and believe me, the learning curve is almost zero. However, just like their names are different, they are NOT entirely the same. Mobile development nonetheless still requires a different mindset and tools compared to web development — at least for the case of React and React Native.

The Difference

From my experience, here are the three major differences you should know for an easier transition from React (aside from the mobile configurations):

Navigation

In a mobile app, URLs cannot be searched and accessed globally unlike on a web browser. The users have to navigate through series of clicks to get to where they want.

This is because a mobile app stores its own local route “history”, while a web app can rely on the user’s browser to store the route history of any public domains worldwide web can offer.

For React Native, the recommended navigation or routing library to use is React Navigation (react-navigation). You can read more here. It works rather very differently than React Router.

In React, developers will just state all the available routes, either static or dynamic (such as those with ids), in the Router component. Any limitations on user access to a page will be handled specifically for that page.

For React Navigation, the developers should specify and provide only the set of routes and pages, or referred to as screens, that can be accessed by the user. All routes are static; any dynamic data are passed to route params. This is an example of how our Dietela team handles authentication, different user roles, and pre-conditions:

getNavigation takes `user` as param and returns a default route with an array of {route, screen} pairs for that specific user’s navigation

Another common issue is nested navigation. For context, React Navigation offers three types of navigation: Stack, (Bottom) Tab, and Drawer.

Stack is not visible to the users and works similar to a browser — you go to a screen then the next, and the history is stored in a stack. Meanwhile, Tab and Drawer can be seen by the users at the bottom and the side of their mobile screen respectively.

So, how can it be nested? An analogy is when we want to see our watch history on YouTube. We are introduced to the Login page (parent Stack). Once we logged in, we are provided with four bottom tabs (inside the Stack exists a Tab), where we then go to the Library tab. When we press “History”, we get redirected to the page containing our video watch list that is still within the Library tab (inside the Tab exists a Stack).

This case also happens in our Dietela product for our client users. To help you visualize, here is our nested navigation structure:

RootStack (supplied by getNavigation function)
├── ClientTabNavigation (line 25 in getNavigation)
│    ├── ProfileStack
│    │    ├── Questionnaire1
│    │    ├── ...
│    │    ├── Questionnaire5
│    ├── Recommendation
│    ├── WeeklyReportStack
│    │    ├── WeeklyReportChooseWeek
│    │    ├── WeeklyReportForm
│    └── Chat
├── ...
└── other routes

An example flow is the user can sign in as a client from the RootStack → go to “Profile” tab from the ClientTabNavigation → and access any of the five questionnaire routes in ProfileStack.

Built-ins

Despite being under the umbrella of JavaScript compiler and runner, React Native usually has older versions of the language used and the React library itself. Developers should be aware that some syntaxes are not introduced in React Native environment yet. Remember that even the slightest difference in React Native (RN) versions can contribute to a lot of dissimilar built-ins, but the major version classification is between RN ≥ 0.60 and RN < 0.60.

Furthermore, React Native has its own markup language instead of using HTML for components and its own third-party dependencies as well. Look at the documentation below to learn more on the available built-in components:

Core Components and APIs · React Native

Fault Tolerance

Compared to React, React Native has a very low fault tolerance. It is sensitive to any warnings, console errors, bugs, and even unoptimized functionalities. The performance of the app will be greatly impacted, and the worst case is the app will crash as soon as it encounters a bug.

Hacks?

(1) If you already have a responsive website and wish to migrate it to a mobile app, or

(2) If you already have a responsive website with no time to build the mobile app version, or

(3) If you wish you can develop a website and mobile app at once,

The easy way out is to build a website first with whatever framework or library you’re comfortable in, deploy it to live production, and integrate it with React Native’s WebView.

By installing react-native-webview and adding your website domain to the WebView component, you can already have a mobile app that runs based on your website. Yay!