Defining Delivery Phases for a Modular React Native App

Delivery Phases - Part 2

Successfully restructuring a React Native application requires more than just a solid architectural plan, it demands a well-defined delivery strategy. Breaking down the transformation into manageable phases helps ensure that each step is carefully executed, tested, and validated before moving forward.

In this article, we explore the concept of delivery phases as a structured approach to frontend restructuring. We’ll discuss how to plan, organize, and execute these phases to minimize risk, maintain app stability, and enable continuous progress. Whether you’re leading a team through a major overhaul or incrementally improving your app, understanding delivery phases is key to achieving a scalable and maintainable React Native codebase.

Phase 1: Define Import Aliases and Ordering

Benefits of Import Aliases

Import aliases can significantly help with app restructuring in a React Native application. Here’s how they can be beneficial:

1. Simplified Imports:
   Import aliases allow you to create shorter and more readable import paths. Instead of using complex relative paths (e.g., ../../../components/Button), you can set up an alias (e.g., @components/Button), making it easier to manage and understand.

2. Improved Code Organisation:
   Using aliases clarifies which parts of the application are being imported, especially when components are spread across different directories.

3. Easier Refactoring:
   When restructuring the app, files or directories may move. Aliases help avoid updating numerous import statements throughout the codebase, reducing errors and smoothing the refactoring process.

4. Enhanced Collaboration:
   Import aliases promote a consistent coding style. New developers can quickly understand the project structure without getting lost in relative paths.

5. Reduced Cognitive Load:
   Clear and consistent import paths reduce the cognitive load on developers, allowing them to focus on functionality rather than file locations.

Proposed Import Aliases

• Define import ordering and grouping: Organising imports by grouping related imports together enhances clarity and readability in import statements.

Initial Folder Structure

The initial folder structure to help reorganise the codebase may be:

• shared:
  • components: Components used throughout the app with their own logic (e.g., ErrorScreen, LoadingScreen).
  • hooks: Hooks used throughout the app.
  • localisation: Copy translation files.
  • providers: All shared providers.
  • services: Services used throughout the app; APIs that are not global should be colocated with the feature.
  • store: Shared Redux store and functionality, (if using Redux).
  • slices: Shared app state and thunks,(if using Redux).
  • themes: Shared themes.
  • ui: Shared UI used to create components.
  • utils: Shared functionality.
• modules: Self-contained features or functionality.

Alias Definitions to Support Folder Structure Transition

Alias	Points To	Description
@/src	./src	Fallback alias import when location is uncertain.
@/navigation	./src/navigation	Navigation-related files.
@/shared	./src/shared	Shared components, hooks, utils, etc.
@/modules	./src/modules	Feature modules.

Next Steps

• Update references to files to use alias imports.

Phase 2: Reorganise the App to Use Shared Folder

• Move shared components from ./src/components to ./src/shared/components.
• Move reusable ui components from ./src/components to ./src/shared/ui utilising atomic design principles.
• Move files from ./src/utils,lib, etc to ./src/shared/utils.
• Move files from ./src/store to ./src/shared/store.
• Move other files in ./src to the equivalently named folder in ./src/shared.

Phase 3: Migrate Identified Modules/Features to the Modules Folder

Steps to Consider When Identifying Modules and Features for Migration

1. Analyse Current Codebase Structure
   Review the existing code organisation to understand how components and features are currently grouped.

2. Identify Logical Boundaries
   Look for natural boundaries in the app’s functionality where code can be grouped into cohesive modules (e.g., user authentication, payments, profile management).

3. Assess Feature Independence
   Select features or modules that have minimal dependencies on other parts of the app to simplify migration.

4. Evaluate Reusability
   Prioritise modules that can be reused across multiple screens or workflows to maximise the benefits of modularisation.

5. Consider Team Ownership
   Align modules with team responsibilities or expertise areas to improve collaboration and maintenance.

6. Review Code Complexity and Size
   Target larger or more complex features first, as modularising these can yield significant improvements in maintainability.

7. Check for Shared State and Data Flow
   Identify modules with clearly defined inputs and outputs to avoid tightly coupled state management.

8. Document Module Boundaries and Interfaces
   Clearly define what each module includes and how it interacts with other parts of the app.

9. Plan for Incremental Migration
   Choose modules that can be migrated incrementally to reduce risk and allow for continuous testing.

10. Validate with Stakeholders
    Confirm the identified modules and migration plan with relevant stakeholders to ensure alignment and support.

Further Information: Design Patterns

As applications grow, they become more difficult to maintain. While small applications may not require a formal design pattern initially, the Rewards App codebase has substantially grown, and the absence of a design pattern makes the app difficult to understand and maintain.

Introducing the MVVM (Model-View-ViewModel) design pattern into the app will address these issues.

Brief Overview of MVVM in the Rewards App

• View:
  Should follow the Single Responsibility Principle (SRP) — each component has one responsibility.

• Components:
  Should adhere to SOLID principles, including:

  • Open-Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle

• View Controllers:
  Implemented as custom hooks that provide functionality to components.

• View Models:
  Import APIs from the API services.

• Redux State:
  Managed locally within the feature.

For a deeper dive into using MVVM with React, see:

Persson Dennis - How To Use MVVM in React Using Hooks and TypeScript

Series

This article is part 3 of the series on restructuring a React Native application frontend.

• Part 1: Introduction and Vision
• Part 2: Delivery Phases
• Part 3: Component Structure Guidelines
• Part 4: Module Structure Guidelines - Coming Soon
• Part 5: Design Patterns - Coming Soon