This material is devoted to work on refactoring navigation in mobile development.
The article provides examples of possible problems, as well as ways out of difficult situations related to the work of navigation in mobile development on React Native.
We will consider the main features and problems of the mobile Legacy project, step by step we will go through a chain of actions consisting of setting a task, identifying bottlenecks, finding solutions to existing problems and obtaining the desired result.
React Native is a relatively young open source mobile app development platform created by Facebook. It is used to create applications for Android, iOS and UWP, and allows developers to use React together with their own platform capabilities.
Navigation is almost the most important element in a mobile application. When building the architecture of the application, you should pay special attention to this topic.
The most common libraries for building navigation:
- React Navigation This is the most popular library, which is often mentioned in official documentation. Accordingly, she has many stars in her piggy bank on GitHub.
- React-Native-Navigation. This platform uses the basic native APIs for iOS and Android. This is a popular alternative to React-Navigation. It is suitable for those who appreciate compliance with the platform’s agreements and don’t care too much about customization.
Less common libraries:
- React-Router-Native. This is an incomplete library. But if you are already familiar with the React Router API and make fairly simple requirements for your application, this platform can help you out.
- React-Native-Router-Flux. This library is based on React-Navigation, but provides a different API for interacting with it.
I will tell you briefly about my experience as a developer. I have been working with React Native for over two years. There are several completed projects published in app stores. During this time, I managed to get acquainted with a large number of tools in the environment of React Native. Navigation is often a stumbling block in mobile development projects. The Legacy project I was working on was no exception. This will be discussed later.
The code was duplicated in the process of refactoring the application instead of dividing the roles into two types (user and administrator). Unfortunately, the same problem was present in navigation.
The architectural features of the application were not taken into account.
All screens were divided into three types: authorization screens, administrator screens, and user screens.
Instead of a logical connection between the root stack and the Navigator Tab with role switching, there was an illogical division into user navigation roles stacks.
Moreover, the construction of navigation for each user was repeated.
I needed to solve the following problems:
- General slowdown of the application.
- The lack of a “pre-renderer” of the main screens, which did not affect the comfort of users in the best way.
- Navigation did not look native. Transition animations were noticeable and inconvenient for work.
Add a screenshot of the modal window component that served as the tab navigator.
- “Insisting” screens in the navigation stack, i.e. there was no discharge (purification). The screens that we opened were stored on the stack. Thus, a memory leak and subsequent crash of the application was almost inevitable.
Results of the work:
- The problem related to the optimization of navigation, the lack of a pre-renderer and the general slowdown was solved by updating the navigation library, using the tab navigator and refusing to use the self-written modal window as a navigator.
- After refactoring, navigation became more natural. Tracking the work of transition animations, as well as the prerender of the main screens on tabs, have increased user comfort.
- The navigation has been stacked in the navigation tab. Transition usage was better controlled. Transitions to the upper level were used.
The following methods were used for the React-Navigation version:
- popToTop - go to the main screen on the stack
- replace - replaces the current route with a new one
- reset - clears the navigator state and replaces it with the result of several actions
I managed to get rid of most of the duplicate navigation screens and build a more logical structure.
In the refactoring process, all navigation was redesigned. Part of the refactoring of navigation also involved getting rid of double screens and creating a unified navigation structure. The screens that were supposed to be located outside the tabs were in the root navigator, and the screens of the navigator tab itself can be seen in the screenshot.
Summing up, I would like to once again note the importance of navigation libraries, as well as pay attention to the use of the most effective strategies for working with them and an in-depth study of technical documentation. Otherwise, you will spend a lot of time and effort on refactoring and refining an existing project and its code base.
Choosing a navigation library is an important step in developing your application. Any decision made without due thought and caution can damage scalability or create other problems.
Useful links:React navigationReact nativeProblems of development the legacy mobile projectReact-native-navigationReact-router-nativeReact-native-router-flux