Guide Large-Scaling React Apps: Part 1

key points: maintainability, scale, modular design

contributor: Matteo Baratella Yaromir Kozak

pre-scriptum: feel free to google more about topic

• SOLID and DRY design

principles, years tested for avoid wrong bones in architecture and reduce tech debt

• Effective State Management

recommend to choose according to project needs: simple - React Context, more complex - Redux Toolkit or Recoil

• Component Design Pattern

HOC (high-order-component) and custom Hooks quite useful pattern for enchant component in many ways (read more - high-order-function)

• Type safe environment

as goal - seamless net of types across all application. Avoid any (alternative 'unknown'), type guards, generics, look at TRPC

• Optimisation:

React.memo, useMemo, useCallback, Code split with React.lazy and Suspend, virtualization large-lists, efficient state management (choose right level of store data)

• use Micro-Frontends

in general its best way to provide scale independent development teams. Two main type are vertical and horizontal, exist a lot tech stacks to implement this pattern:

1) React (optional react-router with SSR) and UI composer (Next.js, Remix, Astro),

2) Next JS framework apps

3) Qwik frameworks with Streams (Cloudflare research link)

it will be covered more in next articles

• look at Mono-repository

lovely practice of FAANG-companies, demonstrated efficiency in scale and maintain and mental comfortable

PS: not best combo with Micro-Frontends, You’ll need to set a lot of rules to ensure clear boundaries, and I feel like it’s cleaner to have detached, separate apps instead

• apply Storybook

must have tool for visualise UI-lib development, validate changes, follow design tokens

• Functional programming style

the style based on atomic functions which pure, always retunes value, no exception, etc

pros: universal testing (smallest function can be under unit test), unexpected errors in functions (if max worse scenario you render no value)

• Tests coverage

always cover project with maximum available test types like:

1) Unit (framework agnostic, functions)

2) Integration (in framework, components/hooks)

3) End-to-End (look at Playwright) - mostly used in QA team but we need to handle setup of this type of test

• Features Based Folder structure

structure when you build a feature separately for be able to control it independently, example

/src
  /features
    /players
      /components
      /services
      /hooks
      /types
      /tests
    /dashboard
      /components
      /services
  /shared
    /ui-components
    /hooks
    /types
    /utils