DEV Community: Siva Samanthapudi

React Mastery Series – Day 34: React Forms at Scale – React Hook Form, Validation & Enterprise Form Architecture

Siva Samanthapudi — Sun, 09 Aug 2026 13:47:36 +0000

Welcome back to the React Mastery Series!

In Day 33, we designed a production-ready API architecture with:

Service layers
Axios and Fetch
Interceptors
Authentication
Error handling
Request cancellation
Retry strategies
TypeScript API contracts
TanStack Query

Today, we're moving to another area that looks simple initially but becomes surprisingly complex in enterprise applications:

Forms

A simple form might contain:

Name
Email
Password
Submit

But a real-world enterprise form can contain:

100+ fields
Dynamic sections
Conditional fields
Nested objects
File uploads
Async validation
Server-side validation
Multi-step workflows
Dependent fields
Complex business rules

At this scale, form architecture matters.

Controlled vs Uncontrolled Components

Before looking at libraries, we need to understand how React handles form state.

Controlled Component

React owns the input value.

function LoginForm() {
  const [email, setEmail] = useState("");

  return (
    <input
      value={email}
      onChange={(event) =>
        setEmail(event.target.value)
      }
    />
  );
}

The flow is:

User Input
    ↓
onChange
    ↓
React State
    ↓
Component Re-render
    ↓
Input Value

This provides complete control.

Advantages of Controlled Components

Controlled inputs are useful when you need:

Immediate UI updates
Conditional rendering
Custom formatting
Real-time validation
Input-dependent behavior

For example:

{accountType === "business" && ( <BusinessDetails />)}

The Problem at Scale

Imagine a form containing:

200 Inputs

If every keystroke updates React state:

User types
   ↓
State update
   ↓
Component render
   ↓
200 fields potentially participate

For small forms, this is usually fine.

For very large forms, it can become expensive if the component tree isn't designed carefully.

Uncontrolled Components

With an uncontrolled input, the DOM maintains the current value.

function LoginForm() {
  const emailRef = useRef<HTMLInputElement>(null);

  return (
    <input ref={emailRef} />
  );
}

You can read the value when required:

const email = emailRef.current?.value;

The React state doesn't update on every keystroke.

React Hook Form

For complex forms, React Hook Form is a popular choice because it is designed around efficient form handling and uncontrolled inputs.

Basic example:

import { useForm } from "react-hook-form";

type LoginForm = {
  email: string;
  password: string;
};

function Login() {
  const { register, handleSubmit } = useForm<LoginForm>();

  const onSubmit = ( data: LoginForm ) => {
    console.log(data);
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)} >
      <input {...register("email")} />

      <input type="password" {...register("password")} />

      <button type="submit"> Login </button>
    </form>
  );
}

The library manages much of the form state and validation lifecycle.

Why React Hook Form?

It provides useful capabilities such as:

Form registration
Validation
Error management
Submission handling
Field arrays
Watchers
Form state
Controlled component integration

It also minimizes unnecessary re-renders in many form scenarios.

Validation

A form isn't complete just because it collects data.

We need to validate it.

Example:

const {register,handleSubmit,formState:{ errors}} = useForm<LoginForm>();

Then:

<input {...register("email", { required: "Email is required"})}
/>

Display the error:

{errors.email && ( <p>{errors.email.message}</p>)}

Validation Rules

We can add multiple rules.

<input
  {...register("password", {
    required: "Password is required",
    minLength: {
      value: 8,
      message:
        "Password must contain at least 8 characters",
    },
  })}
/>

This works well for simple validation.

But enterprise forms often require more complex schemas.

Schema Validation

A common approach is to define the validation rules separately from the UI.

For example, using Zod:

import { z } from "zod";

const loginSchema = z.object({
  email: z
    .string()
    .email("Invalid email address"),

  password: z
    .string()
    .min(
      8,
      "Password must contain at least 8 characters"
    ),
});

Now the validation rules are centralized.

Integrating Zod with React Hook Form

import { zodResolver } from "@hookform/resolvers/zod";

const {
  register,
  handleSubmit,
  formState: {
    errors
  }
} = useForm<LoginForm>({
  resolver: zodResolver(
    loginSchema
  ),
});

Now React Hook Form uses the Zod schema to validate the form.

Type Inference

One of the advantages of schema-based validation is that we can derive TypeScript types.

const loginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8),
});

type LoginForm =
  z.infer<typeof loginSchema>;

Now the validation schema and TypeScript model stay aligned.

Form Architecture

Instead of putting everything inside one component:

LoginForm.tsx

500 lines

split responsibilities.

features
└── auth
    └── forms
        └── login
            ├── LoginForm.tsx
            ├── loginSchema.ts
            ├── login.types.ts
            └── login.service.ts

This becomes much easier to maintain.

Multi-Step Forms

Enterprise workflows often use multiple steps.

Example:

Step 1: Personal Information
        ↓
Step 2: Address
        ↓
Step 3 Employment
        ↓
Step 4: Review
        ↓
Step 5: Submit

The key architectural question is:

Where should the state live?

For a multi-step form, the form state often needs to survive navigation between steps.

Example Multi-Step Structure

registration
├── RegistrationForm.tsx
├── steps
│   ├── PersonalDetails.tsx
│   ├── AddressDetails.tsx
│   ├── EmploymentDetails.tsx
│   └── ReviewDetails.tsx
├── schema
│   └── registrationSchema.ts
└── types
    └── registration.types.ts

Each step owns its UI.

The parent owns the overall workflow.

Conditional Fields

Real-world forms frequently contain conditional fields.

Example:

Account Type

Individual
Business

If the user selects:

Business

show:

Company Name
Registration Number
Tax ID

Example:

{accountType === "business" && (
  <>
    <input
      {...register(
        "companyName"
      )}
    />

    <input
      {...register(
        "registrationNumber"
      )}
    />
  </>
)}

Dependent Fields

Consider:

Country
   ↓
State
   ↓
City

Changing the country should update the available states.

Changing the state should update the cities.

This creates a dependency chain:

Country
   │
   ▼
States
   │
   ▼
Cities

These dependencies should be handled explicitly rather than scattered across many components.

Dynamic Fields

Suppose a customer can add multiple beneficiaries.

Initially:

Beneficiary 1

The user clicks:

+ Add Beneficiary

Now:

Beneficiary 1
Beneficiary 2

React Hook Form provides useFieldArray for this scenario.

const {fields,append,remove} = useFieldArray({
  control,
  name: "beneficiaries",
});

Render:

{fields.map(
  (field, index) => (
    <div key={field.id}>
      <input
        {...register(
          `beneficiaries.${index}.name`
        )}
      />

      <button
        type="button"
        onClick={() =>
          remove(index)
        }
      >
        Remove
      </button>
    </div>
  )
)}

This is extremely useful for enterprise forms.

Nested Forms

Consider an object:

type Customer = {
  name: string;

  address: {
    street: string;
    city: string;
    country: string;
  };
};

The form can represent the nested structure:

<input
  {...register(
    "address.street"
  )}
/>

<input
  {...register(
    "address.city"
  )}
/>

<input
  {...register(
    "address.country"
  )}
/>

The resulting data remains structured.

Async Validation

Some validations require a backend call.

Example:

Username
↓
Check Availability
↓
Available / Already Exists

Or:

Customer ID
↓
Backend Verification
↓
Valid / Invalid

This should be treated differently from simple synchronous validation.

Server-Side Validation

Frontend validation isn't enough.

Imagine:

Frontend
   ↓
Amount <= 100,000
   ↓
Submit

But the backend responds:

Transaction limit exceeded

The server remains the final authority for business rules.

Therefore:

Client Validation
       +
Server Validation

are both necessary.

Handling API Errors

Suppose the backend returns:

{
  "field": "email",
  "message": "Email already exists"
}

The form should ideally map this error to the appropriate field.

Conceptually:

setError("email", {
  type: "server",
  message:
    "Email already exists",
});

Now the user sees the error next to the correct field.

Form-Level Errors

Some errors don't belong to a specific field.

For example:

Unable to process your request.
Please try again later.

This is a form-level error.

Keep these separate from field-level validation.

Field Error
    ↓
Specific input

Form Error
    ↓
General submission problem

Submission State

A production form should clearly represent:

Idle
 ↓
Submitting
 ↓
Success

or:

Idle
 ↓
Submitting
 ↓
Error

Example:

const {
  formState: {
    isSubmitting,
  },
} = useForm();

Disable the submit button while the request is processing:

<button type="submit" disabled={isSubmitting}
>
  {isSubmitting ? "Submitting..." : "Submit"}
</button>

This also helps prevent accidental duplicate submissions.

Preventing Duplicate Submissions

Imagine a payment form:

User clicks Submit
↓
Request starts
↓
User clicks Submit again
↓
Second request

This can create serious business problems.

A good form architecture should:

Disable submission while processing
Handle idempotency where required
Show clear progress
Handle retries carefully

Form Reset

After successful submission:

reset();

But don't blindly reset forms.

For example, if a server validation error occurs:

Submission Failed

the user should normally retain their input.

Reset only when the workflow requires it.

Dirty State

Enterprise applications often need to detect unsaved changes.

For example:

User edits profile
↓
Clicks Back
↓
"Are you sure you want to leave?"

React Hook Form exposes information such as:

formState.isDirty

which can help implement this behavior.

Autosave

Some applications require automatic saving.

For example:

User edits application
↓
Wait 2 seconds
↓
Save Draft

This can be implemented with:

Debouncing
Mutation APIs
Dirty-state tracking
Optimistic UI where appropriate

But autosave should be designed carefully to avoid excessive network traffic.

File Uploads

Enterprise forms may include:

Passport
Salary Certificate
Bank Statement
Profile Photo

File uploads introduce additional concerns:

File size
File type
Upload progress
Security
Cancellation
Retry
Server validation

Don't assume a file selected in the browser is automatically safe.

The backend must validate uploaded content as well.

Accessibility

Form architecture isn't only about state management.

Forms must also be accessible.

Use:

<label htmlFor="email">
  Email
</label>

<input id="email" {...register("email")} />

Associate validation messages with the relevant input where appropriate.

Good forms should work with:

Keyboard navigation
Screen readers
Focus management
Error announcements

Focus Management

After validation fails, users should be able to quickly identify the problem.

For example:

Submit
↓
Validation Error
↓
Focus first invalid field

This becomes especially important in long forms.

Form Performance

For large forms, avoid unnecessary subscriptions.

Instead of watching everything:

watch();

consider watching only what you need:

const accountType = watch("accountType");

This can help keep rendering more targeted.

Enterprise Form Architecture

A scalable form might look like:

features
└── payments
    └── forms
        └── payment
            ├── PaymentForm.tsx
            ├── PaymentHeader.tsx
            ├── PaymentDetails.tsx
            ├── BeneficiaryFields.tsx
            ├── ReviewStep.tsx
            │
            ├── hooks
            │   └── usePaymentForm.ts
            │
            ├── schema
            │   └── paymentSchema.ts
            │
            ├── services
            │   └── paymentService.ts
            │
            └── types
                └── payment.types.ts

Each part has a clear responsibility.

Example Architecture

The overall flow becomes:

User
 │
 ▼
React Form
 │
 ▼
React Hook Form
 │
 ▼
Schema Validation
 │
 ▼
Form Hook
 │
 ▼
Service Layer
 │
 ▼
API Client
 │
 ▼
Backend

The response then flows back:

Backend
   ↓
API Client
   ↓
Service
   ↓
Form Hook
   ↓
Success / Error
   ↓
UI

Common Mistakes

1. One Giant Form Component

Avoid:

PaymentForm.tsx
2000 lines

Split the form into meaningful sections.

2. Mixing Validation With UI

Instead of putting hundreds of validation rules directly into JSX, consider a schema.

3. Client-Only Validation

Never trust frontend validation as the final business rule.

4. No Submission Protection

Always consider duplicate submissions.

5. Ignoring Accessibility

A visually beautiful form can still be difficult to use.

6. Overusing Global State

Form state usually doesn't belong in Redux simply because the form is large.

Keep it local to the form workflow unless there is a clear reason to share it.

Senior Engineer Mindset

A junior developer asks:

"How do I create this input?"

A senior developer asks:

"How should this form manage validation and state?"

An architect asks:

"How will this form behave when it has 100 fields, multiple teams, server-side validation, autosave, accessibility requirements, and changing business rules?"

That's the difference between creating a form and designing a form architecture.

Key Takeaways

Today, we learned:

✅ Controlled components give React complete control over input state.
✅ Uncontrolled inputs can reduce unnecessary state updates for large forms.
✅ React Hook Form provides scalable form management.
✅ Schema validation separates validation rules from UI.
✅ Zod can provide both validation and TypeScript type inference.
✅ Dynamic and nested forms require deliberate architecture.
✅ Client-side validation and server-side validation serve different purposes.
✅ Submission state and duplicate-request prevention are critical in production.
✅ Accessibility should be part of form architecture from the beginning.
✅ Large forms should be decomposed into reusable sections and hooks.

Coming Next 🚀

In Day 35, we'll move into another critical enterprise topic:

React Authentication & Authorization Architecture

We'll cover:

Authentication vs Authorization
Access tokens
Refresh tokens
Protected routes
Role-Based Access Control
Permission-Based Access Control
Route guards
Token expiration
Session management
Secure frontend architecture
Handling unauthorized API responses
Logout across multiple browser tabs

This is where we'll connect React, API architecture, routing, state management, and security into one production-ready design.

Happy Coding! 🚀

React Mastery Series – Day 33: React API Architecture – Axios, Fetch, Service Layers, Interceptors & Error Handling

Siva Samanthapudi — Sun, 09 Aug 2026 08:33:10 +0000

Welcome back to the React Mastery Series!

In Day 32, we explored State Management Architecture and learned how to decide between:

useState
useReducer
Context API
Redux Toolkit
TanStack Query

Today, we're going to look at another area that becomes increasingly important as a React application grows:

API Architecture

In a small application, you might write:

const response = await fetch("/api/users");

directly inside a component.

That works.

But imagine an enterprise application with:

100+ APIs
Multiple backend services
Authentication
Token refresh
Standardized error handling
Request logging
Retry mechanisms
Multiple environments

Putting API logic directly inside components quickly becomes difficult to maintain.

We need an architecture.

The Problem with API Calls Inside Components

Consider:

function Users() {
  useEffect(() => {
    fetch("/api/users")
      .then((response) => response.json())
      .then((data) => setUsers(data));
  }, []);

  return <UserList />;
}

It looks simple.

But now imagine every component contains:

API URL
Authentication
Headers
Error Handling
Retry Logic
Response Transformation
Logging

The application becomes tightly coupled to the backend.

Better Architecture

A scalable architecture separates responsibilities:

React Component
       │
       ▼
Custom Hook
       │
       ▼
Service Layer
       │
       ▼
API Client
       │
       ▼
Backend

Each layer has a specific responsibility.

Layer 1 – Component

The component should focus on UI.

function UserList() {
  const {
    users,
    isLoading,
    error,
  } = useUsers();

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Unable to load users.</p>;
  }

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          {user.name}
        </li>
      ))}
    </ul>
  );
}

The component doesn't know:

Which URL is called
How authentication works
Which HTTP client is used

That's intentional.

Layer 2 – Custom Hook

The hook manages React-specific behavior.

function useUsers() {
  const [users, setUsers] = useState<User[]>([]);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    getUsers()
      .then(setUsers)
      .catch(setError)
      .finally(() => setIsLoading(false));
  }, []);

  return {
    users,
    isLoading,
    error,
  };
}

The hook connects the UI to the service layer.

Layer 3 – Service Layer

The service knows how to communicate with the backend.

export async function getUsers() {
  const response = await api.get<User[]>("/users");

  return response.data;
}

The service doesn't care which component called it.

It simply provides an API operation.

Layer 4 – API Client

The API client contains common HTTP configuration.

import axios from "axios";

export const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  timeout: 10000,
});

Now all services use the same client.

Why Create an Axios Instance?

Instead of:

axios.get(...);
axios.post(...);
axios.put(...);

everywhere, use:

api.get(...);
api.post(...);
api.put(...);

This gives us a central location for:

Base URL
Headers
Authentication
Interceptors
Timeout
Error handling

Axios vs Fetch

Both are valid choices.

Feature	Fetch	Axios
Built into browser	✅	❌
Automatic JSON transformation	❌	✅
Interceptors	❌	✅
Request cancellation	✅	✅
Simple API	✅	✅
Automatic status handling	Manual	More convenient

There is no universal winner.

Choose based on your team's requirements and existing architecture.

Request Interceptors

Suppose every authenticated request needs:

Authorization: Bearer <token>

Instead of adding it manually:

api.get("/users", {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

we can use an interceptor.

api.interceptors.request.use(
  (config) => {
    const token = getAccessToken();

    if (token) {
      config.headers.Authorization =
        `Bearer ${token}`;
    }

    return config;
  }
);

Now the header can be added centrally.

Response Interceptors

Response interceptors allow centralized processing of responses.

api.interceptors.response.use(
  (response) => response,

  (error) => {
    console.error(
      "API Error:",
      error
    );

    return Promise.reject(error);
  }
);

This gives us one place to implement common behavior.

Handling HTTP Status Codes

A typical enterprise application may handle:

200 → Success

400 → Bad Request

401 → Unauthorized

403 → Forbidden

404 → Not Found

409 → Conflict

422 → Validation Error

500 → Server Error

For example:

api.interceptors.response.use(
  (response) => response,

  (error) => {
    switch (error.response?.status) {
      case 401:
        handleUnauthorized();
        break;

      case 403:
        handleForbidden();
        break;

      case 500:
        handleServerError();
        break;
    }

    return Promise.reject(error);
  }
);

401 vs 403

This distinction is important.

401 – Unauthorized

Usually means:

The request doesn't have valid authentication credentials.

Example:

Access Token Expired

The application may attempt a token refresh.

403 – Forbidden

Usually means:

The user is authenticated but doesn't have permission.

Example:

Customer attempts Admin API

The backend rejects the operation.

Token Refresh Architecture

A common enterprise flow looks like:

Request
   │
   ▼
API
   │
   ▼
401
   │
   ▼
Refresh Token
   │
   ▼
New Access Token
   │
   ▼
Retry Original Request

Conceptually:

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    if (
      error.response?.status === 401
    ) {
      // Refresh token
      // Retry original request
    }

    return Promise.reject(error);
  }
);

In production systems, token refresh needs careful handling to avoid multiple simultaneous refresh requests.

The Multiple Request Problem

Imagine five API requests happen simultaneously:

Request A → 401
Request B → 401
Request C → 401
Request D → 401
Request E → 401

If every request independently refreshes the token:

5 Requests
   ↓
5 Refresh Requests

This can create race conditions.

A better architecture coordinates refresh operations so that only one refresh is active while other failed requests wait for the new token.

Request Cancellation

Users may navigate away before an API request completes.

For example:

Search Page

User types:

"react"

↓

API Request

↓

User navigates away

↓

Request no longer needed

Canceling unnecessary requests can reduce resource usage.

Modern fetch uses AbortController.

const controller =
  new AbortController();

fetch("/api/users", {
  signal: controller.signal,
});

controller.abort();

Axios also supports cancellation using AbortSignal.

Search Request Example

Without cancellation:

r
re
rea
reac
react

could trigger multiple requests.

Instead, combine:

Debouncing
Request cancellation
Server-side filtering

Example:

const controller =
  new AbortController();

await api.get("/users", {
  params: {
    search: query,
  },
  signal: controller.signal,
});

Retry Strategy

Not every failed request should be retried.

For example:

GET /accounts

might be safely retryable.

But automatically retrying:

POST /payments

can be dangerous if the operation is not idempotent.

Imagine:

Payment Request
↓
Timeout
↓
Client Retries
↓
Payment Processed Twice

This is a serious financial problem.

Retry strategies must consider the semantics of each operation.

Idempotency

An operation is idempotent when repeating it produces the same intended result.

For example:

GET /accounts

is generally safe to repeat.

But:

POST /payments

may create multiple transactions if the server doesn't provide idempotency protection.

Enterprise payment systems often use an idempotency key.

Example:

Idempotency-Key: 8f2c1d7a

The backend can use this key to prevent accidental duplicate processing.

API Types with TypeScript

Don't leave API responses untyped.

Define interfaces.

export interface User {
  id: number;
  name: string;
  email: string;
}

Then:

const response =
  await api.get<User[]>("/users");

Now TypeScript understands the response.

Request Types

Define request models too.

export interface CreateUserRequest {
  name: string;
  email: string;
  role: string;
}

Service:

export async function createUser(
  payload: CreateUserRequest
) {
  const response =
    await api.post<User>(
      "/users",
      payload
    );

  return response.data;
}

This provides compile-time safety.

Response Transformation

Backend responses aren't always shaped exactly the way the UI needs.

For example:

{
  "first_name": "Siva",
  "last_name": "Samanthapudi"
}

The UI might prefer:

{
  fullName: "Siva Samanthapudi"
}

Transform the data in the service or domain layer rather than scattering transformation logic across components.

Multiple Backend Services

Large applications may communicate with several services:

React Application
       │
       ├── Customer API
       ├── Accounts API
       ├── Payments API
       ├── Cards API
       └── Notifications API

You can create dedicated clients when their configuration differs.

export const customerApi =
  axios.create({
    baseURL:
      import.meta.env.VITE_CUSTOMER_API,
  });

export const paymentApi =
  axios.create({
    baseURL:
      import.meta.env.VITE_PAYMENT_API,
  });

This is particularly useful in enterprise environments.

Suggested API Folder Structure

src
├── api
│   ├── clients
│   │   ├── customerApi.ts
│   │   └── paymentApi.ts
│   │
│   ├── interceptors
│   │   ├── requestInterceptor.ts
│   │   └── responseInterceptor.ts
│   │
│   └── index.ts
│
├── features
│   ├── accounts
│   │   └── services
│   │       └── accountService.ts
│   │
│   └── payments
│       └── services
│           └── paymentService.ts

This keeps infrastructure separate from business features.

API Layer + TanStack Query

If you're using TanStack Query, the architecture becomes:

Component
   │
   ▼
useAccounts()
   │
   ▼
TanStack Query
   │
   ▼
accountService
   │
   ▼
API Client
   │
   ▼
Backend

Each layer has a clear responsibility.

Example

Service:

export async function getAccounts() {
  const response =
    await api.get<Account[]>("/accounts");

  return response.data;
}

Hook:

export function useAccounts() {
  return useQuery({
    queryKey: ["accounts"],
    queryFn: getAccounts,
  });
}

Component:

function AccountList() {
  const {
    data: accounts,
    isPending,
    isError,
  } = useAccounts();

  if (isPending) {
    return <p>Loading...</p>;
  }

  if (isError) {
    return (
      <p>
        Unable to load accounts.
      </p>
    );
  }

  return (
    <ul>
      {accounts.map((account) => (
        <li key={account.id}>
          {account.name}
        </li>
      ))}
    </ul>
  );
}

This is a clean separation of concerns.

Centralized Error Model

Instead of exposing raw Axios errors everywhere, create a standard application error.

export type ApiError = {
  status: number;
  message: string;
  code?: string;
};

Then transform backend errors into a consistent format.

Backend Errors
      ↓
API Client
      ↓
Normalized Error
      ↓
Application
      ↓
User-Friendly Message

This is especially valuable when multiple backend services return different error formats.

Common Mistakes

1. Calling APIs Directly From Every Component

This creates duplication and tight coupling.

Use services or dedicated data-access hooks.

2. Hardcoding URLs

Avoid:

fetch("https://production-api.example.com/users");

Use environment-based configuration.

3. Repeating Authentication Headers

Centralize authentication behavior where appropriate.

4. Retrying Every Failed Request

Be particularly careful with mutations such as payments and order creation.

5. Ignoring Cancellation

Long-running requests can become unnecessary when users navigate away.

6. Exposing Backend Error Messages Directly

Backend messages may contain technical information unsuitable for end users.

Normalize errors and provide user-friendly messages.

Production-Ready API Architecture

A mature React application can follow:

                  React UI
                     │
                     ▼
              Custom Hooks
                     │
                     ▼
            TanStack Query
                     │
                     ▼
              Service Layer
                     │
                     ▼
                API Client
                     │
          ┌──────────┴──────────┐
          │                     │
    Interceptors          Error Handling
          │                     │
          └──────────┬──────────┘
                     │
                     ▼
                Backend APIs

This structure keeps responsibilities clear.

Senior Engineer Checklist

When designing an API layer, ask:

Where should API calls live?
How are authentication headers added?
How are 401 responses handled?
How are 403 responses handled?
How are errors normalized?
Which requests can safely be retried?
How are requests cancelled?
How are API responses typed?
How are multiple backend services handled?
Where should server-state caching happen?

These questions are more important than simply knowing Axios syntax.

Key Takeaways

Today, we learned:

✅ Keep API communication outside presentation components.
✅ Use a service layer to isolate backend communication.
✅ Centralize common HTTP configuration.
✅ Interceptors can handle cross-cutting request and response behavior.
✅ 401 and 403 represent different security scenarios.
✅ Token refresh requires careful concurrency handling.
✅ Don't blindly retry non-idempotent operations.
✅ Use TypeScript models for API contracts.
✅ Request cancellation improves application efficiency.
✅ TanStack Query can sit above the service layer to manage server state.

Coming Next 🚀

In Day 34, we'll take API architecture one step further:

React Forms at Scale – React Hook Form, Validation, Dynamic Forms & Enterprise Form Architecture

We'll explore:

Controlled vs uncontrolled forms
React Hook Form
Form validation
Zod integration
Dynamic fields
Nested forms
Multi-step forms
Conditional fields
Async validation
Server-side validation
Form performance
Enterprise form architecture

Forms look simple at first—but large enterprise forms can become some of the most complex parts of a frontend application.

Happy Coding! 🚀

React Mastery Series – Day 32: State Management Architecture – Redux Toolkit vs Context API vs TanStack Query

Siva Samanthapudi — Sun, 09 Aug 2026 08:17:31 +0000

Welcome back to the React Mastery Series!

In Day 31, we explored Advanced React Architecture and learned how to design large-scale applications using:

Absolutely — let's continue with Day 32, focusing on one of the most important architectural decisions in a production React application.

Feature-based architecture
Clean Architecture principles
Domain boundaries
Separation of concerns
Dependency direction
Modular frontend design

Today, we're going to solve a question that comes up in almost every React architecture discussion:

Where should application state live?

Should we use:

useState?
Context API?
Redux Toolkit?
TanStack Query?
Something else?

The answer is:

It depends on what kind of state you're managing.

Understanding this distinction is much more important than simply knowing how to use a state-management library.

What Is State?

State is information that can change over time and affect what the application displays or does.

Examples:

User logged in
Selected account
Shopping cart
Modal opened
Theme selected
API response
Loading status
Search text

But not all state is the same.

That's the key architectural insight.

Two Major Categories of State

A useful way to think about application state is:

Application State
       │
       ├── Client State
       └── Server State

Let's understand the difference.

Client State

Client state is primarily owned and controlled by the frontend.

Examples:

Modal visibility
Selected tab
Form input
Theme
Sidebar state
Local UI preferences

Example:

const [isOpen, setIsOpen] = useState(false);

The server doesn't care whether your modal is open.

Therefore, this is client state.

Server State

Server state comes from a backend system.

Examples:

User profile
Account balances
Transactions
Products
Orders
Notifications

For example:

React Application
       │
       ▼
GET /accounts
       │
       ▼
Backend
       │
       ▼
Account Data

The backend owns this data.

The frontend is essentially consuming and caching it.

This is server state.

Why This Distinction Matters

A common mistake is putting everything into Redux.

For example:

API Response
      ↓
Redux
      ↓
Component

This can work.

But server state has unique requirements:

Caching
Refetching
Deduplication
Background synchronization
Retry handling
Pagination
Stale data management

Redux itself doesn't automatically solve all of these concerns.

That's where tools such as TanStack Query become useful.

State Management Decision Tree

A practical decision framework:

Do I need state?
      │
      ▼
Only one component?
      │
     Yes
      │
      ▼
   useState

If multiple components need it:

      │
      ▼
Is it simple shared state?
      │
     Yes
      │
      ▼
 Context API

If it's complex global client state:

      │
      ▼
 Redux Toolkit

If the data comes from a server:

      │
      ▼
 TanStack Query

This isn't an absolute rule, but it's a useful starting point.

1. useState

Start with the simplest solution.

Example:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      {count}
    </button>
  );
}

If only one component needs the state, don't introduce a global state library.

2. useReducer

When local state becomes more complex, useReducer can help.

Example:

type State = {
  count: number;
};

type Action =
  | { type: "increment" }
  | { type: "decrement" };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case "increment":
      return {
        count: state.count + 1,
      };

    case "decrement":
      return {
        count: state.count - 1,
      };

    default:
      return state;
  }
}

This is useful when state transitions become more structured.

3. Context API

Context allows values to be shared across a component tree without passing props through every level.

Example:

const ThemeContext = createContext("light");

Provider:

<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

Consumer:

const theme = useContext(ThemeContext);

Good Context API Use Cases

Context works well for relatively stable cross-cutting concerns such as:

Theme
Authentication Context
Localization
Feature Configuration

Example:

<AuthProvider>
  <App />
</AuthProvider>

When Context Can Become a Problem

Consider:

Global Context
      │
      ├── User
      ├── Notifications
      ├── Accounts
      ├── Transactions
      ├── Preferences
      └── Payments

Now many unrelated values live inside the same context.

A change to one value can cause consumers to re-render unnecessarily.

The solution isn't necessarily "never use Context."

Instead:

Keep contexts focused and avoid turning Context into a global dumping ground.

4. Redux Toolkit

Redux Toolkit is a powerful choice for complex client-side state.

Example:

features
├── auth
│   └── authSlice.ts
├── cart
│   └── cartSlice.ts
└── preferences
    └── preferencesSlice.ts

A slice:

import { createSlice, PayloadAction } from "@reduxjs/toolkit";

type CartState = {
  items: string[];
};

const initialState: CartState = {
  items: [],
};

const cartSlice = createSlice({
  name: "cart",
  initialState,
  reducers: {
    addItem(
      state,
      action: PayloadAction<string>
    ) {
      state.items.push(action.payload);
    },

    removeItem(
      state,
      action: PayloadAction<string>
    ) {
      state.items =
        state.items.filter(
          (item) => item !== action.payload
        );
    },
  },
});

export const {
  addItem,
  removeItem,
} = cartSlice.actions;

export default cartSlice.reducer;

Redux Toolkit simplifies traditional Redux significantly.

When Redux Makes Sense

Redux Toolkit can be valuable when you have:

Complex shared state
Multiple state transitions
Cross-feature workflows
Centralized client-side state
Strong debugging requirements
Middleware requirements
Large development teams

For example:

Payment Workflow
↓
Selected Account
↓
Selected Beneficiary
↓
Payment Amount
↓
Validation
↓
Confirmation
↓
Submission Status

If many unrelated components participate in this workflow, centralized state can be useful.

5. TanStack Query

Now we come to an important distinction.

Suppose your application needs:

GET /accounts

The response needs to be:

Cached
Refetched
Shared between components
Invalidated after mutations
Retried when appropriate

This is a server-state problem.

TanStack Query is designed specifically for this kind of workflow.

Example:

import { useQuery } from "@tanstack/react-query";

function Accounts() {
  const { data, isPending, isError } = useQuery({
    queryKey: ["accounts"],
    queryFn: getAccounts,
  });

  if (isPending) {
    return <p>Loading...</p>;
  }

  if (isError) {
    return <p>Unable to load accounts.</p>;
  }

  return (
    <ul>
      {data.map((account) => (
        <li key={account.id}>
          {account.name}
        </li>
      ))}
    </ul>
  );
}

The library manages much of the server-state lifecycle for you.

Server State Lifecycle

A server-state library can manage concepts such as:

Request
   ↓
Loading
   ↓
Success
   ↓
Cache
   ↓
Stale
   ↓
Refetch
   ↓
Updated Cache

This is considerably more than simply storing an API response in Redux.

Mutations

Reading data is only half the story.

Applications also modify server data.

Example:

const mutation = useMutation({ mutationFn: createPayment });

Then:

await mutation.mutateAsync(payment);

After a successful mutation, related queries can be invalidated so the UI gets fresh server data.

Redux vs TanStack Query

A useful mental model:

Requirement	Redux Toolkit	TanStack Query
Client state	✅	❌
Server state	Possible	✅
Caching API data	Manual	Built-in
Refetching	Manual	Built-in
Global workflows	✅	Limited
Complex state transitions	✅	❌
Background synchronization	Manual	✅

The libraries solve different problems.

Can We Use Both?

Absolutely.

A production application can use:

React
 │
 ├── useState
 ├── Context
 ├── Redux Toolkit
 └── TanStack Query

For example:

Authentication
      ↓
Redux Toolkit

Theme
      ↓
Context API

Transaction API Data
      ↓
TanStack Query

Modal State
      ↓
useState

This is often more maintainable than forcing everything into one solution.

Example Banking Application

Imagine a digital banking application.

Local UI State

Selected tab
Modal visibility
Form input

Use:

useState

Authentication

Current user
Authentication status
Session information

Could use:

Context

or a centralized client-state solution depending on the application's requirements.

Account Data

Account balances
Transactions
Statements

Use:

TanStack Query

because this is server-owned data.

Complex Payment Workflow

Account
Beneficiary
Amount
Validation
Confirmation
Submission

Could use:

Redux Toolkit

if the workflow requires complex cross-component client state.

Avoid Duplicate Sources of Truth

One of the biggest architecture problems is storing the same data in multiple places.

For example:

Backend
   ↓
TanStack Query
   ↓
Redux
   ↓
Component State

Now you have multiple copies of the same information.

Which one is correct?

This creates synchronization problems.

Prefer a single source of truth for each category of state.

State Ownership

A powerful question to ask is:

Who owns this state?

For example:

Modal Open?
→ Component

Theme?
→ Context

Account Balance?
→ Server

Payment Draft?
→ Application State

Shopping Cart?
→ Global Client State

Once ownership is clear, choosing the state-management solution becomes much easier.

State Colocation

Another important principle is:

Keep state as close as possible to where it is used.

Bad:

Entire Application
        ↓
Global State
        ↓
Modal Visibility

Better:

function PaymentPage() {
  const [isModalOpen, setIsModalOpen] =
    useState(false);

  // ...
}

Don't make local state global without a reason.

State Normalization

Large applications may have deeply nested data.

Example:

{
  "users": [
    {
      "id": 1,
      "accounts": [
        {
          "id": 101
        }
      ]
    }
  ]
}

Normalized state can reduce duplication.

Conceptually:

users
├── 1
└── 2

accounts
├── 101
└── 102

Normalization becomes especially useful when entities are shared across many parts of the application.

Selectors

With Redux, selectors allow components to read only the state they need.

Example:

const selectCartItems = (
  state: RootState
) => state.cart.items;

Component:

const items = useSelector(selectCartItems);

Selectors can help encapsulate state access and reduce unnecessary coupling to the store structure.

Performance Considerations

State architecture also affects rendering performance.

Imagine:

Global State Changes

↓

100 Components Subscribe

↓

Many Components Re-render

Instead, design state boundaries carefully.

Use:

Focused contexts
Redux selectors
Local state
Memoization when justified
Server-state caching

Performance should be measured rather than optimized blindly.

A Practical Decision Matrix

When deciding where state belongs:

Question	Preferred Option
Only one component needs it?	`useState`
Complex local transitions?	`useReducer`
Shared stable configuration?	Context
Complex global client state?	Redux Toolkit
Backend/server-owned data?	TanStack Query
Temporary UI state?	Local state

This isn't a strict law.

It's a starting point for architectural decisions.

Recommended Enterprise Architecture

A mature React application might look like:

                    React App
                       │
       ┌───────────────┼────────────────┐
       │               │                │
   Local State       Context          Redux
       │               │                │
   useState       Theme/Auth       Client State
       │
       │
       └───────────────┐
                       │
                TanStack Query
                       │
                       ▼
                 Backend APIs

Each tool has a clearly defined responsibility.

Common Mistakes

1. "Everything Goes Into Redux"

This often creates unnecessary complexity.

2. Using Context for Everything

Context is not automatically a replacement for Redux or a server-state library.

3. Putting API Data Into Multiple Stores

Avoid maintaining duplicate copies of server data unless there is a strong architectural reason.

4. Making Local State Global

A state value being shared by two components doesn't automatically mean it belongs in a global store.

5. Choosing a Library Before Understanding the Problem

Don't start with:

"Should we use Redux?"

Start with:

"What kind of state are we managing?"

That's the architectural question.

Senior Frontend Engineer Mindset

A junior developer asks:

"Which state library should I use?"

A senior developer asks:

"What type of state is this?"

An architect asks:

"Who owns this state, who consumes it, how long does it live, and what consistency guarantees do we need?"

That difference in thinking is what makes state architecture scalable.

Key Takeaways

Today, we learned:

✅ useState is ideal for local component state.
✅ useReducer helps manage complex local state transitions.
✅ Context works well for focused cross-cutting concerns.
✅ Redux Toolkit is useful for complex global client state.
✅ TanStack Query is designed for server-state management.
✅ Avoid multiple sources of truth.
✅ Keep state as close as possible to where it is used.
✅ Choose the state-management solution based on the problem—not popularity.

Coming Next 🚀

In Day 33, we'll explore another critical area of frontend architecture:

React API Architecture – Axios, Fetch, Service Layers, Interceptors & Error Handling

We'll build a production-ready API architecture covering:

API client configuration
Axios vs Fetch
Service layers
Request interceptors
Response interceptors
Authentication headers
Token refresh
Centralized error handling
Request cancellation
Retry strategies
API types with TypeScript
Handling multiple backend services

This will bring together many concepts we've already learned and show how they fit into a real enterprise React application.

Happy Coding! 🚀

React Mastery Series – Day 31: Advanced React Architecture – Designing Large-Scale Applications

Siva Samanthapudi — Sun, 09 Aug 2026 08:05:02 +0000

Welcome back to the React Mastery Series!

We've completed the first 30 days of our React journey.

So far, we've covered:

React Fundamentals
Components & Props
Hooks
Context API
Redux Toolkit
API Integration
Forms & Validation
Performance Optimization
Testing
Authentication & Authorization
Design Patterns
Error Handling
Enterprise Project Structure

Now it's time to move from:

"How do I build a React application?"

to:

"How do I architect a React application that can scale?"

This is where the responsibilities of a Senior Frontend Engineer / Frontend Architect begin.

What Does "Large-Scale React Application" Mean?

A small React application might have:

10–50 Components
5–10 Pages
2–3 Developers

A large enterprise application might have:

1000+ Components
100+ Pages
Multiple Business Domains
Multiple Teams
Multiple APIs
Multiple Environments
Millions of Users

At this scale, writing good components isn't enough.

We need a clear architecture.

The Architecture Problem

Imagine a banking application containing:

Accounts
Cards
Payments
Loans
Investments
Transactions
Notifications
Customer Support

If every feature can directly access everything else:

Accounts
   ↕
Payments
   ↕
Cards
   ↕
Loans
   ↕
Investments

The application eventually becomes tightly coupled.

One feature starts depending on another.

Changes become risky.

The Goal of Architecture

A good architecture should provide:

Low Coupling
      +
High Cohesion
      +
Clear Boundaries
      +
Reusable Components
      +
Testability
      +
Scalability

Let's understand each one.

1. High Cohesion

Code that belongs together should stay together.

For example:

features
└── payments
    ├── components
    ├── hooks
    ├── services
    ├── types
    └── utils

Everything related to payments is located inside the payments domain.

This is high cohesion.

2. Low Coupling

Features shouldn't unnecessarily depend on each other's internal implementation.

Bad:

Payments
   ↓
Accounts Internal Component
   ↓
Accounts Internal Service

Better:

Payments
   ↓
Accounts Public API

The payments feature only knows what it needs to know.

Public APIs Between Features

One useful technique is to expose only the functionality that other features need.

Example:

accounts
├── components
├── hooks
├── services
├── types
└── index.ts

The index.ts acts as a public entry point.

export { AccountSummary } from "./components/AccountSummary";
export { useAccounts } from "./hooks/useAccounts";
export type { Account } from "./types";

Other features can import from:

import {
  AccountSummary,
  useAccounts,
} from "@/features/accounts";

Instead of reaching into internal files:

import { AccountSummary } from "@/features/accounts/components/internal/AccountSummary";

This creates a clear boundary.

Feature-Driven Architecture

A large React application can be organized around business domains.

src
├── app
├── features
│   ├── auth
│   ├── accounts
│   ├── cards
│   ├── payments
│   ├── loans
│   └── investments
├── shared
├── layouts
└── routes

This is often easier to scale than organizing everything by technical type.

Layered Architecture Inside a Feature

A feature can also have internal layers.

payments
├── components
├── hooks
├── services
├── store
├── types
├── validation
└── utils

Each layer has a responsibility.

Components

UI and presentation.

Hooks

Reusable React behavior.

Services

Communication with APIs and external systems.

Store

Feature-specific state.

Types

TypeScript models.

Validation

Input and business validation rules.

Utils

Pure helper functions.

Clean Architecture Concepts

Clean Architecture separates business rules from infrastructure.

A simplified React interpretation looks like:

UI Layer
   ↓
Application Layer
   ↓
Domain Layer
   ↓
Infrastructure Layer

Let's understand this.

UI Layer

Responsible for:

Rendering
User interactions
Navigation
Visual states

Example:

function PaymentForm() {
  const { submitPayment, isSubmitting} = usePayment();

  return (
    <form onSubmit={submitPayment}>
      {/* Form UI */}
    </form>
  );
}

The component shouldn't know how the backend works.

Application Layer

This layer coordinates application behavior.

Example:

function usePayment() {
  const submitPayment = async ( payment: PaymentRequest) => {
    return paymentService.createPayment(payment);
  };

  return {submitPayment};
}

The hook coordinates the UI with the underlying services.

Domain Layer

The domain contains business concepts and rules.

For example:

type Payment = {
  amount: number;
  currency: string;
  accountId: string;
};

Business rules might include:

function canMakePayment( balance: number, amount: number) {
  return balance >= amount;
}

This logic shouldn't depend on React.

Infrastructure Layer

This layer communicates with external systems.

Examples:

REST APIs
GraphQL
Browser storage
Analytics
External SDKs

Example:

export async function createPayment(payment: PaymentRequest) {
  const response = await api.post("/payments",payment);
  return response.data;
}

Why Separate These Layers?

Imagine the backend changes from:

REST API

to:

GraphQL

If API implementation is isolated:

UI
 ↓
Application
 ↓
Domain
 ↓
GraphQL Service

We can replace the infrastructure without rewriting the entire UI.

That's the power of separation of concerns.

Dependency Direction

A key architectural principle is:

Dependencies should point toward stable business logic.

Instead of:

Component
   ↓
Axios
   ↓
API
   ↓
Business Rules

Prefer:

UI
 ↓
Application
 ↓
Domain

Infrastructure
 ↓
Implements External Communication

This makes business logic easier to test.

Dependency Injection Concept

React doesn't have traditional dependency injection like Angular.

However, we can implement similar concepts using:

Props
Context
Factory functions
Interfaces
Provider patterns

For example:

type PaymentService = { createPayment: (
    payment: PaymentRequest
  ) => Promise<Payment>;
};

The hook can receive the service:

function createPaymentController(service: PaymentService) {
  return {
    submitPayment: (
      payment: PaymentRequest
    ) => service.createPayment(payment),
  };
}

Now testing becomes easier because we can inject a mock service.

Testing Becomes Easier

Without separation:

Component
   ↓
Axios
   ↓
Backend

Testing requires mocking multiple dependencies.

With separation:

Component
   ↓
Controller
   ↓
Interface
   ↓
Mock Service

We can test business behavior without making real network requests.

State Management Architecture

Not every piece of state belongs in Redux.

A useful rule is:

Local State

Use for:

Modal visibility
Input values
Temporary UI state

Context

Use for:

Theme
Authentication
Localization

Server State

Use tools such as:

TanStack Query

for:

API data
Caching
Refetching
Synchronization

Global Client State

Redux Toolkit can be useful for:

Complex shared application state
Cross-feature workflows
Client-side business state

Don't Put Everything in Redux

A common architectural mistake is:

Everything
   ↓
Redux

This creates unnecessary complexity.

Instead:

UI State
   ↓
useState

Shared Context
   ↓
Context API

Server State
   ↓
TanStack Query

Complex Global State
   ↓
Redux Toolkit

Choose the simplest appropriate tool.

Shared Components

Enterprise applications usually have a design system.

Example:

shared
└── components
    ├── Button
    ├── Input
    ├── Modal
    ├── Table
    ├── DatePicker
    └── Notification

These components should be:

Reusable
Accessible
Consistent
Well tested

Don't Put Business Logic in Shared Components

A shared Button shouldn't know about payments.

Bad:

<Button
  onClick={submitPayment}
  paymentType="INTERNATIONAL"
  accountId={accountId}
/>

The button should only care about being a button.

Business logic belongs in the feature.

Domain Boundaries

Think about each feature as a small business domain.

Payments
     │
     ├── Payment Form
     ├── Payment API
     ├── Payment Validation
     └── Payment State

The payments domain owns its own logic.

This makes teams more independent.

Architecture for Multiple Teams

Imagine four teams:

Team A → Accounts

Team B → Payments

Team C → Cards

Team D → Investments

A feature-based architecture allows each team to work within its domain.

Accounts Team
     ↓
features/accounts

Payments Team
     ↓
features/payments

Cards Team
     ↓
features/cards

This reduces conflicts and improves ownership.

When the Application Becomes Very Large

Eventually, even a well-structured monolithic React application can become difficult to manage.

At that point, organizations may consider:

Modular Monolith
        ↓
Micro Frontends

Micro Frontends allow independently developed frontend modules to be composed into a larger application.

For example:

Shell Application
       │
       ├── Accounts
       ├── Payments
       ├── Cards
       └── Investments

However:

Micro Frontends should solve an organizational or deployment problem—not simply be introduced because the application is large.

Architecture Decision Framework

Before introducing a new technology, ask:

What problem are we solving?
        ↓
How frequently does this problem occur?
        ↓
How many teams are affected?
        ↓
What complexity does the solution introduce?
        ↓
Is the benefit greater than the cost?

This is architectural thinking.

Example Enterprise Architecture

A mature React application might look like:

┌──────────────────────────────┐
│          React UI            │
├──────────────────────────────┤
│ Components / Pages / Routes  │
├──────────────────────────────┤
│     Application Services     │
├──────────────────────────────┤
│       Domain Logic           │
├──────────────────────────────┤
│ Infrastructure / API Layer   │
├──────────────────────────────┤
│ REST / GraphQL / External    │
│ Services                     │
└──────────────────────────────┘

This separation makes the application easier to evolve.

Common Architectural Mistakes

1. Overengineering

Don't introduce:

10 Layers
20 Abstractions
5 State Libraries

for a simple application.

Architecture should match the problem.

2. Creating a Global Utility for Everything

A huge utils.ts file eventually becomes difficult to understand.

Group utilities by domain when appropriate.

3. Excessive Shared Code

Sharing code is useful.

But excessive sharing creates coupling.

Sometimes duplication is cheaper than creating a tightly coupled abstraction.

4. Mixing Infrastructure with Business Logic

Avoid:

Component
   ↓
Axios
   ↓
Business Rules

Keep infrastructure replaceable.

Senior Engineer Mindset

A junior developer often asks:

"How can I implement this feature?"

A senior developer asks:

"Where should this feature belong?"

An architect asks:

"How will this decision affect the system six months from now?"

That shift in thinking is extremely important.

Architecture Checklist

Before adding a new feature, ask:

What business domain does it belong to?
What state does it require?
Is that state local or global?
Does it require server data?
Where should API communication live?
Can the logic be reused?
What should be publicly exposed?
How will it be tested?
What happens when the API fails?
Will this architecture scale to additional teams?

Key Takeaways

Today, we learned:

✅ Large React applications need clear architectural boundaries.
✅ Feature-based architecture improves scalability and ownership.
✅ High cohesion and low coupling are fundamental principles.
✅ Clean Architecture separates UI, application, domain, and infrastructure concerns.
✅ Not every piece of state belongs in Redux.
✅ Dependency injection concepts can improve testability even in React.
✅ Micro Frontends should be introduced only when they solve a real organizational or deployment problem.
✅ Good architecture is about managing complexity, not adding complexity.

Coming Next 🚀

In Day 32, we'll take the next step toward frontend architecture:

State Management Architecture – Redux Toolkit vs Context API vs TanStack Query

We'll answer some of the most common questions senior React developers face:

When should I use Context API?
When should I use Redux Toolkit?
When should I use TanStack Query?
What is client state vs server state?
Where should authentication state live?
How should multiple features share state?
How do we avoid unnecessary re-renders?
How should state management be designed in an enterprise React application?

We'll build a practical decision framework rather than simply comparing libraries.

Happy Coding! 🚀

React Mastery Series – Day 30: React Project Folder Structure & Scalable Architecture

Siva Samanthapudi — Thu, 06 Aug 2026 10:49:02 +0000

Welcome back to the React Mastery Series! 🎉

We've officially reached Day 30 of this journey.

So far, we've covered everything from React fundamentals to advanced topics like:

Hooks
Context API
Redux Toolkit
API Integration
Authentication
Performance Optimization
Testing
Error Handling
Design Patterns

Today, we'll learn how to organize React projects like experienced engineering teams at enterprise companies.

Why Project Structure Matters

As your application grows, so does its complexity.

A project with 10 files is easy to navigate.

A project with 5,000+ files is not.

Without a proper structure, developers often struggle with:

Finding files
Reusing components
Managing dependencies
Scaling new features
Onboarding new team members

A well-organized architecture solves these problems.

Small Project Structure

A simple React project might look like this:

src
├── App.tsx
├── main.tsx
├── components
├── pages
├── hooks
├── utils
└── assets

This works well for:

Learning React
Personal projects
Small business applications

However, it becomes difficult to manage as the application grows.

The Problem with Layer-Based Structure

Many beginners organize code like this:

src
├── components
├── pages
├── services
├── hooks
├── reducers
├── utils
├── types
└── styles

At first glance, this looks clean.

But imagine an enterprise banking application with:

300 components
100 services
150 hooks

Finding files becomes increasingly difficult.

Feature-Based Architecture

Modern React applications organize code by business features, not by file type.

Example:

src
├── features
│   ├── auth
│   ├── accounts
│   ├── payments
│   ├── dashboard
│   ├── notifications
│   └── investments

Everything related to a feature lives together.

This improves maintainability and team collaboration.

Inside a Feature

Let's look at the Accounts feature.

accounts
├── api
├── components
├── hooks
├── pages
├── services
├── store
├── types
├── utils
└── index.ts

Each feature becomes a self-contained module.

Benefits:

Easier navigation
Better encapsulation
Simpler refactoring

Shared Folder

Some code is reused across multiple features.

Store it in a shared directory.

src
├── shared
│   ├── components
│   ├── hooks
│   ├── services
│   ├── constants
│   ├── utils
│   └── types

Examples include:

Buttons
Modal components
Date utilities
API clients
Common TypeScript types

API Layer

Avoid calling APIs directly inside components.

❌ Bad:

function Dashboard() {
  useEffect(() => {
    axios.get("/accounts");
  }, []);

  return <div>Dashboard</div>;
}

✅ Better:

accounts
└── services
    └── accountService.ts

import { api } from "@/shared/services/api";

export async function getAccounts() {
  const response = await api.get("/accounts");

  return response.data;
}

Component:

const accounts = await getAccounts();

Business logic remains outside the UI.

Component Organization

Separate reusable UI from feature-specific components.

shared
└── components
    ├── Button
    ├── Modal
    ├── Loader
    └── Input

Feature-specific components:

```text id="1tfnvo"
accounts
└── components
├── AccountCard
├── BalanceChart
└── TransactionTable




This keeps the shared library small and meaningful.

---

# Custom Hooks

Shared hooks:



```text
shared
└── hooks
    ├── useDebounce.ts
    ├── useLocalStorage.ts
    └── useWindowSize.ts

Feature hooks:

accounts
└── hooks
    ├── useAccounts.ts
    └── useTransactions.ts

Hooks should live as close as possible to the feature they support.

State Management

Using Redux Toolkit?

Organize slices by feature.

features
├── auth
│   └── authSlice.ts
├── accounts
│   └── accountSlice.ts
└── payments
    └── paymentSlice.ts

Root store:

src
└── app
    └── store.ts

Each feature owns its own state.

Routing Structure

Instead of placing all routes in one file:

  App.tsx
     ↓
200 Routes

Split routes by feature.

src
├── routes
│   ├── AppRoutes.tsx
│   ├── AuthRoutes.tsx
│   └── AdminRoutes.tsx

This makes routing easier to maintain.

Assets Organization

Keep assets organized.

src
├── assets
│   ├── images
│   ├── icons
│   ├── fonts
│   └── styles

Avoid scattering images throughout the project.

Environment Configuration

Never hardcode URLs or secrets.

❌ Bad:

const apiUrl = "https://production-api.com";

✅ Better:

.env

```text id="h51qxc"
VITE_API_URL=https://api.example.com




Usage:



```tsx 
const apiUrl = import.meta.env.VITE_API_URL;

This allows different configurations for development, testing, and production.

Barrel Exports

Instead of:

import Button from "./Button";
import Input from "./Input";
import Modal from "./Modal";

Create an index.ts.

export { default as Button } from "./Button";
export { default as Input } from "./Input";
export { default as Modal } from "./Modal";

Now import everything from one place.

import { Button, Input, Modal } from "@/shared/components";

Cleaner imports improve readability.

Example Enterprise Folder Structure

src
├── app
│   ├── store.ts
│   └── providers.tsx
├── assets
├── features
│   ├── auth
│   ├── dashboard
│   ├── accounts
│   ├── payments
│   ├── transactions
│   └── investments
├── routes
├── shared
│   ├── components
│   ├── hooks
│   ├── services
│   ├── utils
│   ├── constants
│   └── types
├── layouts
├── styles
├── App.tsx
└── main.tsx

This structure scales well for teams working on large applications.

Monorepo Architecture

As organizations grow, multiple applications often share code.

Example:

apps
├── customer-portal
├── admin-portal
└── mobile-web

packages
├── ui
├── auth
├── api
└── utils

Tools such as Nx and Turborepo make it easier to manage monorepos.

Real-World Banking Example

Imagine a digital banking platform.

features
├── accounts
├── cards
├── loans
├── payments
├── investments
├── support
└── profile

Each team owns one or more features.

They can build, test, and deploy changes independently while following the same architectural standards.

Common Mistakes

1. Organizing Everything by File Type

Large components or services folders quickly become difficult to navigate.

Group files by feature instead.

2. Creating a Shared Folder Too Early

Not every component belongs in shared.

Only move components there when they're genuinely reused across features.

3. Mixing Business Logic with UI

Keep:

API calls
Validation
Data transformations

outside your presentation components.

4. Ignoring Naming Conventions

Be consistent with:

Folder names
File names
Component names
Hook names

Consistency improves readability across the team.

Best Practices

Organize by feature, not by file type.
Keep features self-contained.
Separate UI, business logic, and API layers.
Create shared modules only when reuse is proven.
Use barrel exports for cleaner imports.
Keep environment-specific configuration outside source code.
Follow consistent naming conventions throughout the project.

Key Takeaways

Today, we learned:

✅ Feature-based architecture scales better than layer-based organization.
✅ Shared components should contain only reusable code.
✅ Business logic belongs in services and hooks, not UI components.
✅ Redux slices should be organized by feature.
✅ Environment variables simplify configuration management.
✅ A well-structured project improves collaboration and long-term maintainability.

🎉 Milestone Reached!

Congratulations on completing 30 articles in the React Mastery Series!

By now, you've built a strong foundation in React and explored many of the patterns and practices used in production applications.

Coming Next 🚀

In Day 31, we'll begin a new advanced chapter:

Advanced React Patterns & Enterprise Architecture – Building Large-Scale Applications

We'll cover:

Feature-Driven Design (FDD)
Domain-Driven Folder Organization
Scalable State Management
Dependency Injection Concepts
Clean Architecture in React
Modular Frontend Design
Enterprise project case study

This marks the transition from becoming a React developer to thinking like a Senior Frontend Engineer or React Architect.

Happy Coding! 🚀

React Mastery Series – Day 29: React Error Handling – Error Boundaries, Logging & Resilient UI Design

Siva Samanthapudi — Thu, 06 Aug 2026 10:43:42 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored React Design Patterns and learned how enterprise applications use:

Composition
Compound Components
Custom Hooks
Higher-Order Components (HOCs)
Provider Pattern
Feature-Based Architecture

Today, we'll learn how to build React applications that can gracefully recover from unexpected failures.

React Error Handling

No application is perfect.

Servers fail.

Networks disconnect.

APIs return unexpected responses.

Developers accidentally introduce bugs.

The goal isn't to eliminate every error—it's to ensure users continue to have a good experience when errors occur.

Why Error Handling Matters

Imagine a customer opening an internet banking application.

           Dashboard
               ↓
        Account Summary
               ↓
          Transactions
               ↓
          Investments
               ↓
      One Component Crashes
               ↓
Entire Application Becomes Blank

This creates a poor user experience.

Instead, we'd rather display:

             Dashboard
                ↓
          Account Summary
                ↓
           Transactions
                ↓
      Investment Widget Crashes
                ↓
     Show Friendly Error Message
                ↓
Rest of Dashboard Continues Working

This approach makes applications more resilient.

Types of Errors in React

React applications commonly encounter four categories of errors.

Error Type	Example
Rendering Errors	Component crashes while rendering
JavaScript Errors	Undefined variables, null references
Network Errors	API request failures
Runtime Errors	Unexpected user interactions or invalid data

Each category requires a different handling strategy.

What Happens When a Component Crashes?

Consider this component:

function UserProfile() {
  const user = null;

  return <h2>{user.name}</h2>;
}

When rendered:

Cannot read properties of null

Without protection, React may unmount the affected part of the application.

Introducing Error Boundaries

An Error Boundary catches rendering errors in its child component tree.

      Application
           │
           ▼
    Error Boundary
           │
           ▼
       Dashboard
           │
           ▼
Profile Component Crashes
           │
           ▼
   Fallback UI Appears

Instead of a blank page, users see a meaningful message.

Creating an Error Boundary

Error Boundaries are currently implemented using class components.

import React from "react";

type ErrorBoundaryState = {
  hasError: boolean;
};

class ErrorBoundary extends React.Component<
  React.PropsWithChildren,
  ErrorBoundaryState
> {
  state: ErrorBoundaryState = {
    hasError: false,
  };

  static getDerivedStateFromError() {
    return {
      hasError: true,
    };
  }

  componentDidCatch(
    error: Error,
    errorInfo: React.ErrorInfo
  ) {
    console.error(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return <h2>Something went wrong.</h2>;
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

Although modern React primarily uses function components, Error Boundaries still rely on class components.

Using an Error Boundary

Wrap components that could fail.

<ErrorBoundary>
  <Dashboard />
</ErrorBoundary>

Or wrap only critical sections.

<Dashboard>
  <ErrorBoundary>
    <InvestmentWidget />
  </ErrorBoundary>

  <TransactionList />
</Dashboard>

If the investment widget crashes, the transaction list continues working.

What Error Boundaries Catch

✅ Rendering errors
✅ Constructor errors
✅ Lifecycle method errors

They help prevent the application from crashing completely.

What Error Boundaries Don't Catch

Error Boundaries do not catch:

Event handler errors
Async errors
API failures
setTimeout() errors
Server-side rendering errors

These require different handling strategies.

Handling API Errors

Always anticipate API failures.

async function fetchUsers() {
  try {
    const response = await api.get("/users");

    return response.data;
  } catch (error) {
    console.error(error);

    throw error;
  }
}

In the UI:

if (error) {
  return (
    <ErrorMessage
      message="Unable to load users."
    />
  );
}

Show users a helpful message instead of exposing technical details.

Handling Async Errors

Async functions should always use try...catch.

async function handleSubmit() {
  try {
    await saveProfile();
  } catch (error) {
    setError(
      "Unable to save your profile."
    );
  }
}

Gracefully handling failures improves the user experience.

Defensive Rendering

Avoid assuming data always exists.

Instead of:

<h2>{user.name}</h2>

Use optional chaining.

<h2>{user?.name}</h2>

Or provide a fallback.

<h2>{user?.name ?? "Guest User"}</h2>

This prevents many runtime errors.

Global Axios Error Handling

Centralize API error handling with interceptors.

api.interceptors.response.use(
  (response) => response,

  (error) => {
    if (error.response?.status === 401) {
      // Redirect to login
    }

    if (error.response?.status === 500) {
      console.error("Server error");
    }

    return Promise.reject(error);
  }
);

This avoids duplicating error handling across the application.

Logging Errors

Errors should be logged for developers.

Typical information includes:

Error message
Stack trace
Browser
User ID (if available)
URL
Timestamp

Example:

      Error
        ↓
    Log Service
        ↓
Developer Dashboard
        ↓
     Fix Bug

Logging helps identify issues that users encounter in production.

Monitoring with Sentry

Many enterprise applications use monitoring platforms such as Sentry to collect production errors.

Example setup:

import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "YOUR_DSN",
});

These tools automatically collect error details and help teams prioritize fixes.

Building a Friendly Fallback UI

Avoid showing messages like:

TypeError:
Cannot read properties of undefined

Instead, display:

Oops!

Something went wrong.

Please refresh the page or try again later.

Users don't need technical stack traces.

They need clear guidance.

Retry Pattern

Network issues are often temporary.

Instead of:

API Failed
   ↓
  Stop

Prefer:

  API Failed
      ↓
Show Retry Button
      ↓
 Retry Request
      ↓
   Success

This improves resilience for intermittent failures.

Real-World Banking Example

Imagine the transaction history service is temporarily unavailable.

Instead of crashing the dashboard:

Dashboard
   ↓
Accounts ✓

Cards ✓

Loans ✓

Transactions ✗
     ↓
Unable to load transactions.

[ Retry ]

Users can still access the rest of the application.

Folder Structure

A scalable error handling structure:

src

├── components
│   ├── ErrorBoundary.tsx
│   ├── ErrorMessage.tsx
│   └── RetryButton.tsx
├── services
│   └── api.ts
├── hooks
    └── useErrorHandler.ts

Keep error handling reusable and centralized.

Common Mistakes

1. Ignoring API Failures

Every API call can fail.

Always handle:

Loading
Success
Error

2. Showing Technical Errors to Users

Avoid exposing stack traces or exception messages.

Display user-friendly messages instead.

3. Wrapping the Entire App with One Error Boundary

A single Error Boundary can cause the entire application to display fallback UI.

Use multiple boundaries around critical sections when appropriate.

4. Not Logging Errors

If errors aren't logged, developers may never know users experienced them.

Always collect enough information to investigate production issues.

Best Practices

Use Error Boundaries around major UI sections.
Handle async operations with try...catch.
Use optional chaining when accessing nested data.
Centralize API error handling.
Display meaningful fallback messages.
Log errors to a monitoring service.
Allow users to retry failed operations whenever possible.

Key Takeaways

Today, we learned:

✅ Error Boundaries prevent rendering errors from crashing the entire application.
✅ Async errors require try...catch.
✅ API failures should display helpful messages and retry options.
✅ Centralized error handling reduces duplicate code.
✅ Logging production errors helps teams identify and fix issues quickly.
✅ Resilient applications continue functioning even when individual components fail.

Coming Next 🚀

In Day 30, we will explore one of the most requested topics by React developers:

React Project Folder Structure & Scalable Architecture

We will learn:

Small vs Large Project Structure
Feature-Based Architecture
Shared Components
Services Layer
Hooks Organization
State Management Structure
Environment Configuration
Enterprise Folder Organization

By the end of the next article, you'll know how to organize React applications the way large engineering teams at companies like banks, fintech firms, and SaaS organizations structure their production codebases.

Happy Coding! 🚀

React Mastery Series – Day 28: React Design Patterns – Compound Components, Render Props, Higher-Order Components & Custom Hooks

Siva Samanthapudi — Wed, 05 Aug 2026 18:08:25 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored Authentication & Authorization and learned how enterprise React applications implement:

JWT Authentication
Protected Routes
Role-Based Access Control (RBAC)
Axios Interceptors
Token Refresh
Enterprise authentication architecture

Today, we'll move beyond React APIs and explore something that separates intermediate developers from senior engineers:

React Design Patterns

As applications grow, writing React code that simply works isn't enough.

We need code that is:

Reusable
Maintainable
Scalable
Easy to test
Easy to extend

This is where design patterns come into play.

What are Design Patterns?

A design pattern is a proven solution to a commonly occurring software design problem.

Instead of reinventing solutions every time, developers use patterns that have already proven effective in large applications.

Think of them as reusable blueprints for structuring your code.

Why Design Patterns Matter

Imagine you're building an e-commerce application.

You'll have:

Product Cards
Shopping Cart
Checkout
User Profile
Orders
Wishlist

Without patterns:

  Large Components
        ↓
  Duplicate Logic
        ↓
Difficult Maintenance
        ↓
   Frequent Bugs

With patterns:

Reusable Components
        ↓
   Shared Logic
        ↓
   Cleaner Code
        ↓
 Easy Maintenance

Pattern 1 – Composition

React encourages Composition over Inheritance.

Instead of creating deeply nested class hierarchies, React allows components to be composed together.

Example:

type CardProps = {
  children: React.ReactNode;
};

function Card({ children }: CardProps) {
  return <div className="card">{children}</div>;
}

Usage:

<Card>
  <h2>Bank Account</h2>

  <p>Balance: $10,000</p>
</Card>

The Card component doesn't know what content it displays.

It simply provides a reusable layout.

Pattern 2 – Compound Components

Compound Components work together as a single unit.

Examples:

Accordion
Tabs
Modal
Select
Menu

Instead of:

<Accordion
  title="React"
  content="React is a library."
/>

We compose smaller pieces.

<Accordion>
  <Accordion.Header>
    React
  </Accordion.Header>

  <Accordion.Body>
    React is a library.
  </Accordion.Body>
</Accordion>

Benefits:

Flexible API
Cleaner JSX
Better readability

Real-World Example

Imagine building a banking dashboard card.

<Card>
  <Card.Header>
    Savings Account
  </Card.Header>

  <Card.Body>
    AED 52,000
  </Card.Body>

  <Card.Footer>
    Updated 2 mins ago
  </Card.Footer>
</Card>

Each section has a clear responsibility.

Pattern 3 – Custom Hooks

Earlier in this series, we learned how to create Custom Hooks.

They are also a powerful design pattern.

Without Custom Hooks:

    Dashboard
        ↓
Authentication Logic
        ↓
    API Logic
        ↓
  Loading Logic

Every page repeats the same code.

With Custom Hooks:

     Dashboard
        ↓
     useAuth()
        ↓
   useAccounts()
        ↓
useNotifications()

Business logic becomes reusable.

Example:

function useUser() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // Fetch user
  }, []);

  return user;
}

Now multiple components can reuse the same logic.

Pattern 4 – Render Props

A Render Prop is a function passed as a prop that returns JSX.

Example:

type DataLoaderProps = {
  render: (data: string[]) => React.ReactNode;
};

function DataLoader({
  render,
}: DataLoaderProps) {
  const users = ["Alice", "Bob"];

  return <>{render(users)}</>;
}

Usage:

<DataLoader
  render={(users) => (
    <ul>
      {users.map((user) => (
        <li key={user}>{user}</li>
      ))}
    </ul>
  )}
/>

The component handles data fetching, while the parent decides how to display it.

Although Custom Hooks have replaced many Render Prop use cases, you'll still encounter this pattern in existing codebases.

Pattern 5 – Higher-Order Components (HOC)

A Higher-Order Component is a function that takes a component and returns a new component with additional behavior.

     Component
        ↓
       HOC
        ↓
Enhanced Component

Example:

function withLoading<T>(Component: React.ComponentType<T>) {
  return function WrappedComponent(props: T & { loading: boolean }) {
    if (props.loading) {
      return <p>Loading...</p>;
    }

    return <Component {...props} />;
  };
}

Usage:

const UserListWithLoading = withLoading(UserList);

Common HOC use cases:

Authentication
Authorization
Logging
Analytics
Error handling

Modern React often prefers Custom Hooks, but HOCs remain important in many enterprise applications.

Pattern 6 – Provider Pattern

The Provider Pattern shares data across the application.

Example:

<AuthProvider>
  <ThemeProvider>
    <App />
  </ThemeProvider>
</AuthProvider>

Instead of passing props through many components:

  App
   ↓
Dashboard
   ↓
 Sidebar
   ↓
 Profile
   ↓
 Avatar

Any component can access shared data through Context.

Pattern 7 – Controlled Component Pattern

Many reusable components support both controlled and uncontrolled modes.

Example:

type ToggleProps = {
  checked: boolean;
  onChange: () => void;
};

function Toggle({checked, onChange,}: ToggleProps) {
  return (
    <button onClick={onChange}>
      {checked ? "ON" : "OFF"}
    </button>
  );
}

The parent controls the component's state.

This pattern is widely used in UI libraries like Material UI and Ant Design.

Pattern 8 – Container & Presentational Components

Separate business logic from presentation.

Container:

function UserContainer() {
  const users = useUsers();

  return <UserList users={users} />;
}

Presentational Component:

type UserListProps = {
  users: string[];
};

function UserList({users}: UserListProps) {
  return (
    <ul>
      {users.map((user) => (
        <li key={user}>{user}</li>
      ))}
    </ul>
  );
}

Responsibilities:

Container	Presentational
API Calls	UI Rendering
Business Logic	Layout
State Management	Display Data

Pattern 9 – Feature-Based Architecture

Enterprise React applications organize code by features.

src

├── features
│   ├── auth
│   ├── dashboard
│   ├── accounts
│   ├── payments
│   └── transactions

Each feature contains:

accounts

├── components
├── hooks
├── pages
├── services
├── types

This keeps related files together and improves team collaboration.

Enterprise Example

Imagine an online banking application.

       Dashboard
          ↓
    Account Summary
          ↓
  Transaction List
          ↓
     Loan Details
          ↓
Investment Portfolio

Each module uses:

Custom Hooks
Shared Components
Context Providers
Feature Modules
API Services

This architecture scales well even as the application grows.

Choosing the Right Pattern

Problem	Recommended Pattern
Shared UI	Composition
Shared Logic	Custom Hooks
Global State	Provider Pattern
Flexible Components	Compound Components
Enhance Components	HOCs
Separate UI & Logic	Container/Presentational
Large Applications	Feature-Based Architecture

Common Mistakes

1. Using Patterns Too Early

Not every component needs an advanced design pattern.

Start simple.

Refactor when duplication or complexity appears.

2. Creating Massive Components

Avoid components with:

API calls
Business logic
Forms
Tables
Charts
Navigation

all inside one file.

Break them into smaller, focused components.

3. Duplicating Business Logic

If the same logic appears in multiple places, consider moving it into:

A Custom Hook
A Service
A Utility Function

4. Choosing Inheritance Over Composition

React is designed around composition.

Prefer combining small components rather than extending large ones.

Best Practices

Prefer composition over inheritance.
Keep components focused on a single responsibility.
Reuse business logic through Custom Hooks.
Organize code by feature for large applications.
Use Compound Components for flexible APIs.
Separate business logic from presentation.
Introduce patterns only when they solve a real problem.

Key Takeaways

Today, we learned:

✅ Design patterns improve scalability and maintainability.
✅ Composition is the foundation of React architecture.
✅ Compound Components create expressive and flexible APIs.
✅ Custom Hooks are the preferred way to share business logic.
✅ Higher-Order Components are still relevant in many enterprise projects.
✅ Provider Pattern simplifies global state sharing.
✅ Feature-based architecture helps large teams organize code effectively.

Coming Next 🚀

In Day 29, we will explore:

React Error Handling – Error Boundaries, Logging & Resilient UI Design

We will learn:

What happens when React crashes
Error Boundaries
Handling rendering errors
Global error logging
Async error handling
Fallback UI
Monitoring with tools like Sentry
Building fault-tolerant React applications

By the end of the next article, you'll know how enterprise applications gracefully recover from unexpected errors instead of showing users a blank screen.

Happy Coding! 🚀

React Mastery Series – Day 27: Authentication & Authorization in React – JWT, Protected Routes & Role-Based Access Control (RBAC)

Siva Samanthapudi — Tue, 04 Aug 2026 16:01:50 +0000

🚀 React Mastery Series – Day 27: Authentication & Authorization in React – JWT, Protected Routes & Role-Based Access Control (RBAC)

Welcome back to the React Mastery Series!

In the previous article, we explored React Testing and learned how to write reliable applications using:

Unit Testing
Integration Testing
End-to-End (E2E) Testing
React Testing Library
Playwright
Mocking APIs
Enterprise testing strategies

Today, we'll cover one of the most critical topics in modern web development:

Authentication & Authorization in React

Almost every enterprise application requires users to log in before accessing sensitive information.

Examples include:

Internet Banking
E-Commerce Platforms
Healthcare Portals
Insurance Applications
HR Management Systems
CRM Platforms

Building authentication correctly is essential for both security and user experience.

Authentication vs Authorization

Many developers use these terms interchangeably, but they have different meanings.

Authentication

Authentication answers the question:

Who are you?

Example:

     Username
       ↓
    Password
       ↓
Identity Verified

Authorization

Authorization answers the question:

What are you allowed to access?

Example:

    User Logged In
         ↓
     Check Role
         ↓
      Admin?
         ↓
Yes → Admin Dashboard
No → User Dashboard

Authentication verifies identity.

Authorization verifies permissions.

Real-World Banking Example

Imagine an online banking system.

Two users log in.

  Customer
     ↓
View Accounts
Transfer Money
Download Statements

Bank Employee
     ↓
Approve Loans
Manage Customers
View Reports

Both users are authenticated.

But they have different permissions.

This is authorization.

Authentication Flow

A typical login flow looks like this:

User Enters Credentials
          │
          ▼
     Backend API
          │
          ▼
   Credentials Valid?
          │
          ▼
     ┌─────────────┐
     │             │
    Yes            No
     │             │
     ▼             ▼
Generate JWT    Show Error
     │
     ▼
Store Token
     │
     ▼
Navigate to Dashboard

What is JWT?

JWT stands for:

JSON Web Token

It is a compact token used to securely identify authenticated users.

A JWT contains three parts:

Header.Payload.Signature

Example:

xxxxx.yyyyy.zzzzz

The frontend doesn't need to understand every part of the token.

It simply stores the token and sends it with future API requests.

Login Request

React sends credentials to the backend.

Example:

POST /login

Request body:

{
  "email": "user@example.com",
  "password": "password123"
}

Successful response:

{
  "token": "jwt-token",
  "user": {
    "id": 101,
    "name": "Siva",
    "role": "ADMIN"
  }
}

Storing Authentication State

After login, applications usually store:

User information
Authentication status
Access token

Example Redux state:

interface AuthState {
  user: User | null;
  token: string | null;
  isAuthenticated: boolean;
}

This state becomes available throughout the application.

Token Storage Options

There are multiple ways to store authentication tokens.

Storage	Suitable?	Notes
localStorage	Sometimes	Persists after browser restart but is accessible to JavaScript.
sessionStorage	Sometimes	Cleared when the browser tab closes.
HTTP-Only Cookies	Recommended	More resistant to JavaScript-based attacks because scripts cannot access them.

Many enterprise applications prefer HTTP-Only Cookies because they offer stronger protection against certain attack vectors.

Attaching Tokens to API Requests

Authenticated requests typically include the token in the Authorization header.

Example:

GET /accounts

Authorization: Bearer jwt-token

Using Axios:

api.interceptors.request.use((config) => {
  const token = localStorage.getItem("token");

  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }

  return config;
});

This automatically attaches the token to every request.

Protected Routes

Some pages should only be accessible to authenticated users.

Examples:

/

Login

About

Public routes.

/dashboard

/accounts

/profile

/settings

Protected routes.

Creating a Protected Route

Example:

import { Navigate } from "react-router-dom";

type ProtectedRouteProps = {
  children: React.ReactNode;
  isAuthenticated: boolean;
};

function ProtectedRoute({
  children,
  isAuthenticated,
}: ProtectedRouteProps) {
  if (!isAuthenticated) {
    return <Navigate to="/login" replace />;
  }

  return <>{children}</>;
}

export default ProtectedRoute;

Usage:

<Rout path="/dashboard" element={
    <ProtectedRouteisAuthenticated={isAuthenticated}>
      <Dashboard />
    </ProtectedRoute>
  }
/>

If the user isn't logged in, they're redirected to the login page.

Role-Based Access Control (RBAC)

Authentication answers:

"Who is the user?"

RBAC answers:

"What can this user do?"

Example:

ADMIN
↓
Dashboard
Users
Reports
Settings

CUSTOMER
   ↓
Dashboard
Accounts
Transactions

Different roles see different features.

Role-Based Rendering

Example:

{
  user.role === "ADMIN" && (<AdminPanel />);
}

The component is rendered only for administrators.

Remember:

Frontend checks improve the user experience, but the backend must always enforce authorization.

Logout Flow

Logging out should:

Clear authentication state
Remove stored tokens
Redirect to the login page

Example:

function logout() {
  localStorage.removeItem("token");
  dispatch(clearUser());
  navigate("/login");
}

After logout:

User Clicks Logout
        │
        ▼
   Remove Token
        │
        ▼
Clear Redux State
        │
        ▼
Navigate to Login

Refresh Tokens

Access tokens usually have a short expiration time.

Instead of forcing users to log in repeatedly:

Access Token Expires
        │
        ▼
 Refresh Token
        │
        ▼
New Access Token
        │
        ▼
 Continue Session

This improves both security and user experience.

Enterprise Authentication Architecture

   React App
       │
       ▼
  Login API
       │
       ▼
  JWT Issued
       │
       ▼
Redux/Auth Context
       │
       ▼
 Axios Interceptor
       │
       ▼
 Protected APIs

Each layer has a specific responsibility.

Folder Structure

A scalable authentication module:

src
├── features
│   └── auth
│       ├── components
│       ├── hooks
│       ├── pages
│       ├── services
│       ├── authSlice.ts
│       └── types.ts
├── routes
│   └── ProtectedRoute.tsx
├── api
    └── axios.ts

This keeps authentication logic organized and maintainable.

Common Mistakes

1. Storing Sensitive Data in the Frontend

Avoid storing confidential information such as passwords or secrets in React applications.

Only store what's necessary for the client.

2. Relying Only on Frontend Authorization

Hiding buttons isn't enough.

The backend must always verify permissions before returning sensitive data or performing privileged actions.

3. Forgetting Token Expiration

Applications should gracefully handle expired tokens by:

Refreshing them (when applicable)
Redirecting users to log in again if refresh fails

4. Not Clearing Authentication State on Logout

Always remove tokens and reset application state when users sign out.

Best Practices

Use HTTPS for all authenticated communication.
Protect sensitive routes.
Handle expired tokens gracefully.
Keep authentication logic centralized.
Separate authentication from authorization.
Validate permissions on the backend.
Store only the minimum required user information in the frontend.

Key Takeaways

Today, we learned:

✅ Authentication verifies user identity.
✅ Authorization determines what users are allowed to access.
✅ JWT is commonly used for stateless authentication.
✅ Protected routes prevent unauthorized access to pages.
✅ RBAC enables role-specific experiences.
✅ Refresh tokens improve both security and usability.
✅ Backend authorization is mandatory, even if the frontend hides restricted features.

Coming Next 🚀

In Day 28, we will explore:

React Design Patterns – Compound Components, Render Props, Higher-Order Components & Custom Hooks

We will learn:

Why design patterns matter
Compound Components
Render Props
Higher-Order Components (HOCs)
Provider Pattern
Custom Hook Pattern
Composition over inheritance
Enterprise React design principles

These patterns will help you build reusable, maintainable, and scalable React applications like those used in large engineering teams.

Happy Coding! 🚀

React #ReactJS #Authentication #Authorization #JWT #RBAC #FrontendDevelopment #TypeScript #WebDevelopment #SoftwareArchitecture

React Mastery Series – Day 26: React Testing – Unit Testing, Integration Testing & End-to-End Testing

Siva Samanthapudi — Tue, 04 Aug 2026 15:53:10 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored React Performance Optimization and learned techniques like:

Lazy Loading
Code Splitting
React.memo()
useMemo()
useCallback()
Virtualization
Performance monitoring

Today, we'll cover one of the most valuable skills for enterprise React developers:

React Testing

Many developers think testing is optional.

In reality, every production application needs automated tests to ensure that new features don't accidentally break existing functionality.

Testing helps teams:

Ship changes confidently
Catch bugs early
Improve code quality
Reduce regression issues
Enable safe refactoring

Why Testing Matters

Imagine an internet banking application.

A developer changes the login page.

Everything appears to work.

After deployment, users discover they can no longer transfer money because a shared component was unintentionally broken.

Without automated tests:

Developer Changes Code
          │
          ▼
Deploy to Production
          │
          ▼
Users Find Bugs

With automated tests:

Developer Changes Code
          │
          ▼
Run Test Suite
          │
          ▼
Tests Fail
          │
          ▼
Fix Before Deployment

Testing becomes a safety net.

Types of Testing

React applications typically use three levels of testing.

          E2E Tests
              ▲
              │
     Integration Tests
              ▲
              │
        Unit Tests

Each level serves a different purpose.

Unit Testing

Unit tests verify one small piece of functionality.

Examples:

A Button component
A utility function
A custom hook
A reducer

Example:

function sum(a: number, b: number) {
  return a + b;
}

Test:

test("adds two numbers", () => {
  expect(sum(2, 3)).toBe(5);
});

Only one function is being tested.

Integration Testing

Integration tests verify multiple components working together.

Example:

Login Form
     │
     ▼
Validation
     │
     ▼
API Call
     │
     ▼
Dashboard

Instead of testing each component separately, we verify the complete flow.

End-to-End (E2E) Testing

E2E testing simulates a real user.

Example:

Open Website
      │
      ▼
Enter Username
      │
      ▼
Enter Password
      │
      ▼
Click Login
      │
      ▼
Dashboard Appears

These tests verify that the application works from the user's perspective.

Testing Tools

Modern React projects commonly use:

Purpose	Tool
Test Runner	Jest or Vitest
Component Testing	React Testing Library
Browser Automation	Playwright or Cypress

If you're using Vite, many teams prefer Vitest because it's optimized for the Vite ecosystem.

Testing Philosophy

React Testing Library encourages this mindset:

Test your application the way users use it.

Instead of checking implementation details:

❌ Internal state

✅ Visible UI

❌ Private methods

✅ User interactions

This results in more reliable tests.

Installing Testing Libraries

For Jest:

npm install --save-dev jest

For React Testing Library:

npm install --save-dev @testing-library/react
npm install --save-dev @testing-library/jest-dom
npm install --save-dev @testing-library/user-event

Your First Component

type ButtonProps = {
  text: string;
};

function Button({ text }: ButtonProps) {
  return <button>{text}</button>;
}

export default Button;

Testing a Component

import { render, screen } from "@testing-library/react";

import Button from "./Button";

test("renders button text", () => {
  render(<Button text="Save" />);

  expect(
    screen.getByText("Save")
  ).toBeInTheDocument();
});

Flow:

Render Component
        │
        ▼
Find Element
        │
        ▼
Verify Output

Understanding `render()`

render() mounts a React component into a virtual DOM for testing.

render(<Login />);

Now the test can interact with the component just like a browser would.

Finding Elements

React Testing Library provides multiple queries.

screen.getByText("Login");

screen.getByRole("button");

screen.getByPlaceholderText("Email");

Prefer queries based on accessibility, such as getByRole(), because they closely match how assistive technologies interact with your application.

Testing User Interaction

Example component:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <>
      <h2>{count}</h2>

      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </>
  );
}

export default Counter;

Test:

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

test("increments counter", async () => {
  render(<Counter />);

  await userEvent.click(
    screen.getByRole("button", {
      name: /increment/i,
    })
  );

  expect(screen.getByText("1")).toBeInTheDocument();
});

The test behaves like a real user clicking the button.

Testing Forms

Example:

render(<LoginForm />);

await userEvent.type(
  screen.getByLabelText(/email/i),
  "user@example.com"
);

await userEvent.type(
  screen.getByLabelText(/password/i),
  "password123"
);

await userEvent.click(
  screen.getByRole("button", {
    name: /login/i,
  })
);

This closely mirrors how users interact with forms.

Mocking API Calls

Components often depend on backend APIs.

Instead of making real network requests during tests, mock them.

Example:

jest.mock("../services/userService", () => ({
  getUsers: jest.fn(),
}));

Now you control the API response without depending on a server.

Benefits:

Faster tests
Reliable execution
No internet dependency

Testing Loading States

Example component:

if (loading) {
  return <Spinner />;
}

Test:

expect(
  screen.getByRole("status")
).toBeInTheDocument();

Verify that users see a loading indicator while data is being fetched.

Testing Error States

Example:

render(<ErrorMessage message="Something went wrong" />);

expect(
  screen.getByText("Something went wrong")
).toBeInTheDocument();

Always test both success and failure scenarios.

Testing Redux Components

When testing components connected to Redux, wrap them with a Provider.

import { Provider } from "react-redux";

render(
  <Provider store={store}>
    <Dashboard />
  </Provider>
);

This provides access to the Redux Store during testing.

Testing React Router

Components using React Router should be wrapped in a router.

import { MemoryRouter } from "react-router-dom";

render(
  <MemoryRouter>
    <Profile />
  </MemoryRouter>
);

MemoryRouter is designed specifically for testing navigation.

End-to-End Testing with Playwright

Example:

import { test, expect } from "@playwright/test";

test("user can log in", async ({ page }) => {
  await page.goto("http://localhost:5173");

  await page.fill("#email", "user@example.com");
  await page.fill("#password", "password123");

  await page.click("button[type='submit']");

  await expect(page).toHaveURL("/dashboard");
});

This launches a real browser and verifies the entire login flow.

Enterprise Testing Strategy

A typical enterprise testing pyramid looks like this:

              Few

        End-to-End Tests

               ▲

      Integration Tests

               ▲

      Many Unit Tests

Why?

Unit tests are fast.
Integration tests verify workflows.
E2E tests validate critical user journeys.

Keeping this balance provides broad coverage without slowing development.

Folder Structure

A scalable project structure:

src
├── components
│   ├── Button.tsx
│   └── Button.test.tsx
├── hooks
│   ├── useAuth.ts
│   └── useAuth.test.ts
├── services
│   ├── userService.ts
│   └── userService.test.ts

Keep tests close to the code they validate.

Common Mistakes

1. Testing Implementation Details

Avoid checking internal state or private functions.

Instead, verify what users can see and do.

2. Ignoring Edge Cases

Test:

Empty data
Loading states
Error responses
Invalid input
Unauthorized users

3. Overusing End-to-End Tests

E2E tests are valuable but slower than unit and integration tests.

Reserve them for critical user journeys.

4. Skipping Accessibility Queries

Prefer:

screen.getByRole("button", { name: /save/i,});

Instead of relying on CSS classes or IDs whenever possible.

Best Practices

Write tests alongside new features.
Test behavior instead of implementation.
Mock external services.
Cover success and failure scenarios.
Keep tests independent.
Use meaningful test names.
Run tests in your CI/CD pipeline before deployment.

Key Takeaways

Today, we learned:

✅ Unit tests verify individual components and functions.
✅ Integration tests validate multiple components working together.
✅ End-to-End tests simulate real user behavior.
✅ React Testing Library focuses on user interactions.
✅ Mocking makes tests faster and more reliable.
✅ A balanced testing strategy improves confidence in production releases.

Coming Next 🚀

In Day 27, we will explore:

Authentication & Authorization in React – JWT, Protected Routes & Role-Based Access Control

We will learn:

Authentication vs Authorization
JWT (JSON Web Tokens)
Login and Logout flows
Token storage strategies
Refresh tokens
Protected routes
Role-Based Access Control (RBAC)
Enterprise authentication architecture

Authentication is one of the most important building blocks of secure React applications, and every frontend developer should understand how it works in production.

Happy Coding! 🚀

React Mastery Series – Day 25: React Performance Optimization – Lazy Loading, Code Splitting & Suspense

Siva Samanthapudi — Tue, 04 Aug 2026 15:50:09 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored React Forms and learned how to build scalable forms using:

Controlled Components
Uncontrolled Components
React Hook Form
Validation
Zod
Enterprise form architecture

Today, we'll explore one of the most important topics for production applications:

React Performance Optimization

As applications grow, they also become larger.

A small React application might load:

250 KB

An enterprise application can easily exceed:

5 MB+

If we don't optimize our application, users experience:

Slow page loads
Laggy interactions
Higher bandwidth usage
Poor user experience
Lower SEO scores

Let's learn how professional React developers solve these challenges.

Why Performance Matters

Imagine a banking application with:

Dashboard
Transactions
Loans
Investments
Credit Cards
Reports
Settings
Admin Panel

Should all of these be downloaded when the user first opens the login page?

Absolutely not.

Most users haven't even logged in yet.

Loading unnecessary code wastes time and bandwidth.

What is a Bundle?

When React applications are built for production, the source code is bundled into JavaScript files.

  Source Code
      |
      ↓
    Build
      |
      ↓
JavaScript Bundle
      |
      ↓
   Browser

Without optimization:

App.js

5 MB

The browser downloads everything at once.

What is Code Splitting?

Code Splitting divides a large bundle into smaller chunks.

Instead of:

App Bundle
    ↓
   5 MB

We get:

 Home
   ↓
200 KB

Dashboard
   ↓
400 KB

Settings
   ↓
180 KB

Reports
   ↓
500 KB

Only the required chunk is downloaded.

Benefits:

Faster initial load
Better caching
Improved performance

Lazy Loading

Lazy Loading means loading a component only when it's needed.

Instead of loading:

Dashboard
Profile
Reports
Settings
Admin

during startup,

React loads:

          Login
            ↓
   User Clicks Dashboard
            ↓
Download Dashboard Component

This significantly reduces startup time.

React.lazy()

React provides built-in lazy loading.

Example:

import { lazy } from "react";

const Dashboard = lazy(() => import("./Dashboard"));

Notice:

The component is imported only when React needs it.

What is Suspense?

Since lazy-loaded components take time to download, users need feedback.

React provides:

<Suspense>

Example:

import { Suspense, lazy } from "react";

const Dashboard = lazy(() => import("./Dashboard"));

<Suspense fallback={<Loading />}>
  <Dashboard />
</Suspense>

Flow:

   Navigate
       ↓
Download Component
       ↓
 Loading Spinner
       ↓
 Component Ready
       ↓
  Display UI

Route-Based Lazy Loading

This is one of the most common optimization techniques.

Instead of:

import Dashboard from "./Dashboard";

import Profile from "./Profile";

import Reports from "./Reports";

Use:

const Dashboard = lazy(() => import("./Dashboard"));

const Profile = lazy(() => import("./Profile"));

const Reports = lazy(() => import("./Reports"));

Each page loads only when visited.

Lazy Loading with React Router

Example:

<Routes>
  <Route path="/dashboard" element={
    <Suspense fallback={<Loading />}>
        <Dashboard />
    </Suspense>
  }/>
</Routes>

Users downloading only the pages they visit improves overall application performance.

Dynamic Imports

JavaScript supports importing modules on demand.

Example:

const module = await import("./calculator");

This is useful when loading:

Charts
Rich text editors
PDF viewers
Analytics libraries

Only when users need them.

Memoization

Sometimes components re-render unnecessarily.

Example:

Parent
   ↓
Child A
   ↓
Child B
   ↓
Child C

If Parent updates, every child re-renders.

Even if Child C's data never changed.

React.memo()

React.memo() prevents unnecessary re-renders.

Example:

const UserCard = React.memo( 
   function UserCard(){
      return <h2>User</h2>;
  });

Now UserCard re-renders only when its props change.

useMemo()

Expensive calculations should not execute on every render.

Example:

const sortedUsers = useMemo( ()=>{
  return users.sort(...);
},[users]);

Without useMemo(),

sorting happens on every render.

With it,

sorting happens only when users changes.

useCallback()

Functions are recreated during every render.

Example:

const handleClick = useCallback(()=>{
 console.log("Clicked");
},[]);

This is especially useful when passing callbacks to child components.

Debouncing

Imagine a search box.

User types:

R
Re
Rea
Reac
React

Without optimization:

5 API Calls

Better:

User Stops Typing
       ↓
Single API Call

This technique is called Debouncing.

It reduces unnecessary requests and improves responsiveness.

Virtualization

Imagine displaying:

100,000 Rows

Rendering every row is expensive.

Instead:

      Render
        ↓
Only Visible Rows

Libraries such as react-window and react-virtualized help render only the visible portion of large lists.

Image Optimization

Large images slow applications.

Best practices:

Compress images
Use modern formats (WebP, AVIF)
Lazy-load images
Serve responsive image sizes

Example:

<img loading="lazy" src="profile.webp"/>

The browser loads the image only when it approaches the viewport.

Bundle Analysis

Large dependencies increase bundle size.

Tools like bundle analyzers help identify:

Charts Library 1.5 MB
        ↓
    Replace
       ↓
300 KB Alternative

Always review large third-party packages before adding them.

Enterprise Example

Consider an internet banking application.

Without optimization:

  Login
   ↓
Download

Dashboard
Loans
Cards
Reports
Settings
Admin
Investments

Total:

6 MB

Optimized version:

         Login
           ↓
        500 KB
           ↓
    User Opens Reports
           ↓
  Download Reports Module
           ↓
  User Opens Investments
           ↓
Download Investments Module

The initial experience becomes much faster.

Measuring Performance

React applications can be measured using:

Browser DevTools
React DevTools Profiler
Lighthouse
Core Web Vitals

Key metrics include:

First Contentful Paint (FCP)
Largest Contentful Paint (LCP)
Interaction to Next Paint (INP)
Cumulative Layout Shift (CLS)

Monitoring these metrics helps identify performance bottlenecks.

Common Mistakes

1. Optimizing Everything

Not every component needs memoization.

Overusing:

React.memo()
useMemo()
useCallback()

can increase code complexity without measurable benefits.

Optimize only after identifying bottlenecks.

2. Importing Large Libraries Globally

Avoid importing heavy libraries if only one page uses them.

Use lazy loading or dynamic imports instead.

3. Rendering Huge Lists

Always consider virtualization when displaying thousands of items.

4. Ignoring Network Conditions

Users may access your application on slow mobile networks.

Optimize bundle size to improve performance for everyone.

Performance Optimization Checklist

Before releasing your application:

✅ Enable code splitting.
✅ Lazy-load routes and heavy components.
✅ Optimize images.
✅ Use memoization only when necessary.
✅ Debounce search requests.
✅ Virtualize large lists.
✅ Analyze bundle size regularly.
✅ Monitor Core Web Vitals.

Key Takeaways

Today, we learned:

✅ Code splitting reduces initial bundle size.
✅ React.lazy() loads components on demand.
✅ Suspense provides loading feedback for lazy-loaded components.
✅ React.memo(), useMemo(), and useCallback() help avoid unnecessary work.
✅ Debouncing and virtualization improve performance for large applications.
✅ Measuring performance is just as important as optimizing it.

Coming Next 🚀

In Day 26, we will explore:

React Testing – Unit Testing, Integration Testing & End-to-End Testing

We will learn:

Why testing matters
Jest fundamentals
React Testing Library
Testing components
Mocking API calls
User interaction testing
End-to-End testing with Cypress and Playwright
Enterprise testing strategies

Testing is a critical skill for building reliable, maintainable, and production-ready React applications.

Happy Coding! 🚀

React Mastery Series – Day 24: React Forms – Controlled Components, Validation & React Hook Form

Siva Samanthapudi — Mon, 03 Aug 2026 06:36:56 +0000

Welcome back to the React Mastery Series!

In the previous article, we learned how React applications communicate with backend services using Fetch API and Axios, along with best practices like service layers, interceptors, and error handling.

Today, we'll explore one of the most common features you'll build as a React developer:

Forms in React

Whether it's:

User Login
Registration
Profile Update
Payment Details
Contact Forms
Search Filters

Forms are everywhere.

Learning how to build performant, scalable, and validated forms is an essential skill for every React developer.

Understanding Forms in React

A form is a collection of input elements used to collect user data.

Example:

Login Form

Email,Password and Login Button

React provides multiple ways to manage form data.

The two most common approaches are:

Controlled Components
Uncontrolled Components

Controlled Components

In a controlled component, React controls the input value through state.

Example:

import { useState } from "react";

function Login() {
  const [email, setEmail] = useState("");
  return (
    <input
      type="email"
      value={email}
      onChange={(e) => setEmail(e.target.value)}
    />
  );
}

Flow:

User Types
     ↓
onChange
     ↓
React State
     ↓
Input Updates

The input value always comes from React state.

Why Controlled Components?

Benefits:

Easy validation
Easy formatting
Predictable state
Better debugging

Example:

if (email.length < 5) {
  // Show validation message
}

Since the value is stored in state, validation becomes straightforward.

Uncontrolled Components

In uncontrolled components, the DOM manages the input value.

React accesses it using a ref.

Example:

import { useRef } from "react";

function Login() {

  const emailRef = useRef<HTMLInputElement>(null);
  function handleSubmit() {
    console.log(emailRef.current?.value);
  }
  return (
    <>
      <input ref={emailRef} />

      <button onClick={handleSubmit}>
        Login
      </button>
    </>
  );
}

Use uncontrolled components when you don't need React to track every keystroke.

Controlled vs Uncontrolled

Controlled	Uncontrolled
React manages state	DOM manages state
Easy validation	Simpler implementation
More re-renders	Better for simple forms
Preferred in React	Useful for quick prototypes

Most enterprise applications use controlled components or libraries like React Hook Form.

Handling Multiple Inputs

Instead of creating separate state variables for every field:

const [name, setName] = useState("");
const [email, setEmail] = useState("");
const [phone, setPhone] = useState("");

Store them in one object.

const [formData, setFormData] = useState({name: "",email: "",phone: ""});

Update dynamically:

function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
  setFormData({
    ...formData,
    [event.target.name]: event.target.value
  });
}

This approach scales much better.

Basic Validation

Example:

if (!email.includes("@")) {
  alert("Invalid email");
}

Other common validations:

Required fields
Minimum length
Maximum length
Password strength
Phone number format

Form Submission

Example:

function handleSubmit(event: React.FormEvent) {
  event.preventDefault();
  console.log(formData);
}

Always call:

event.preventDefault();

to prevent the browser from refreshing the page.

Why React Hook Form?

Managing large forms using useState() quickly becomes difficult.

Imagine:

Registration Form
      ↓
20 Input Fields
      ↓
20 State Variables
      ↓
20 onChange Handlers

React Hook Form solves this problem.

Benefits:

Better performance
Less code
Built-in validation
Minimal re-renders
Excellent TypeScript support

Installation:

npm install react-hook-form

Creating Your First React Hook Form

import { useForm } from "react-hook-form";

function Login() {
  const {register,handleSubmit} = useForm();

  return (
    <form onSubmit={handleSubmit(console.log)}>
      <input {...register("email")}/>
      <button> Login </button>
    </form>
  );
}

No useState() required for every field.

Registering Inputs

Every input is connected using:

register()

Example:

<input {...register("username")} />

React Hook Form automatically tracks the value.

Validation with React Hook Form

Example:

<input  {...register("email", 
        { required: true, pattern: /\S+@\S+\.\S+/})}
/>

Now the field validates automatically.

Displaying Validation Errors

const {register, formState: { errors}} = useForm();

Example:

{
errors.email && (<p> Invalid Email</p>)
}

Users receive immediate feedback.

Schema Validation with Zod

Many enterprise applications use schema validation.

Install:

npm install zod

Example:

const schema = z.object({
  email: z.string().email(),
  password: z.string().min(8)
});

Benefits:

Centralized validation rules
Type safety
Reusable schemas

Dynamic Forms

Imagine adding multiple addresses.

Example:

Address 1 + Add Address
        ↓
    Address 2
        ↓
    Address 3

React Hook Form provides:

useFieldArray()

to handle dynamic form fields efficiently.

Enterprise Example: Customer Registration

     Customer Registration
             ↓
Name, Email, Phone, Address, Password
             ↓
        Validation
             ↓
       API Request
             ↓
     Success Message

Flow:

User Input
↓
Validation
↓
Submit
↓
Backend API
↓
Response
↓
UI Update

Folder Structure

A scalable structure:

src
├── forms
│   ├── LoginForm.tsx
│   ├── RegistrationForm.tsx
│   └── ProfileForm.tsx
├── validation
│   ├── authSchema.ts
│   └── profileSchema.ts

Keep validation separate from UI components.

Common Mistakes

1. Validating Only on the Backend

Backend validation is essential.

But frontend validation improves user experience by providing instant feedback.

Always validate on both sides.

2. Forgetting `preventDefault()`

Without it:

     Submit
       ↓
Browser Refresh

Your React state will be lost.

3. Creating Too Many State Variables

Avoid:

const [firstName] = useState("");
const [lastName] = useState("");
const [email] = useState("");
const [phone] = useState("");

Prefer:

A single object
React Hook Form

4. Not Showing Validation Messages

Always tell users:

What went wrong
Which field failed
How to fix it

Clear feedback leads to a better user experience.

Best Practices

Prefer controlled components for small forms.
Use React Hook Form for medium and large forms.
Validate on both frontend and backend.
Keep validation logic reusable.
Display loading and submission states.
Disable the submit button while submitting.
Keep form components focused and reusable.

Key Takeaways

Today, we learned:

✅ React supports controlled and uncontrolled components.
✅ Controlled components keep form values in React state.
✅ React Hook Form simplifies form management and improves performance.
✅ Validation is essential for reliable user input.
✅ Schema validation libraries like Zod make forms more maintainable.
✅ Well-structured forms improve both developer experience and user experience.

Coming Next 🚀

In Day 25, we will explore:

React Performance Optimization – Lazy Loading, Code Splitting & Suspense

We will learn:

Why application performance matters
Lazy loading components
Code splitting
React Suspense
Dynamic imports
Route-based lazy loading
Bundle optimization
Real-world enterprise performance strategies

By the end of the next article, you'll understand how large React applications load quickly and remain responsive even as they grow.

Happy Coding! 🚀

React Mastery Series – Day 23: API Integration in React – Fetch, Axios, Error Handling & Best Practices

Siva Samanthapudi — Mon, 03 Aug 2026 06:22:12 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored Redux Toolkit and learned how enterprise applications use centralized state management to build scalable and predictable React applications.

Today, we'll cover another critical skill every React developer must master:

API Integration in React

Most React applications don't work in isolation. They communicate with backend services to:

Authenticate users
Fetch customer data
Display products
Process payments
Upload files
Update user profiles

Understanding how to interact with APIs efficiently is essential for building production-ready applications.

What is an API?

An API (Application Programming Interface) acts as a bridge between the frontend and backend.

 React Application
       |
       ↓
   REST API
       |
       ↓
    Database

Instead of directly accessing the database, the React application sends requests to the backend API.

HTTP Request Methods

The most common HTTP methods are:

Method	Purpose
GET	Retrieve data
POST	Create new data
PUT	Update existing data
PATCH	Partially update data
DELETE	Remove data

Example:

GET    /users
POST   /users
PUT    /users/101
DELETE /users/101

Fetch API

The Fetch API is built into modern browsers.

Example:

async function fetchUsers() {
  const response = await fetch("/api/users");
  const users = await response.json();
  console.log(users);
}

Flow:

  React
     |
  fetch()
     |
  Backend
     |
JSON Response
     |
 React UI

Handling Errors with Fetch

A common mistake is assuming every response is successful.

async function fetchUsers() {

  try {
    const response = await fetch("/api/users");
    if (!response.ok) {
      throw new Error("Failed to fetch users");
    }
    const users = await response.json();
    console.log(users);
  } catch (error) {
    console.error(error);
  }
}

Always check response.ok.

Why Many Teams Prefer Axios

Although Fetch is powerful, enterprise projects often use Axios because it provides:

Automatic JSON transformation
Request interceptors
Response interceptors
Request cancellation
Timeout configuration
Better error handling

Installation:

npm install axios

Making a GET Request with Axios

import axios from "axios";

async function fetchUsers() {
  const response = await axios.get("/api/users");
  console.log(response.data);
}

Notice:

    Fetch
      ↓
response.json()

vs.

    Axios
      ↓
response.data

Axios automatically parses JSON.

Sending a POST Request

Example:

await axios.post("/api/users", {
  name: "Siva",
  role: "Frontend Developer"
});

Flow:

   Form
    |
  Submit
    |
POST Request
    |
 Backend
    |
Database

PUT and DELETE Requests

Update:

await axios.put( "/api/users/101",
  {
    name: "Updated Name"
  }
);

Delete:

await axios.delete("/api/users/101");

Creating a Reusable Axios Instance

Instead of repeating configuration:

axios.get(...)
axios.post(...)
axios.put(...)

Create one API client.

import axios from "axios";
export const api = axios.create({
  baseURL: "https://api.example.com",
  timeout: 10000
});

Now:

api.get("/users");
api.post("/users");

Configuration is centralized.

Request Interceptors

Most enterprise applications require an authentication token.

Instead of adding it manually:

headers: {
 Authorization:"Bearer token"
}

Use an interceptor.

api.interceptors.request.use(config => {
  const token = localStorage.getItem("token");
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

Every request automatically includes the token.

Response Interceptors

Suppose the backend returns:

401 Unauthorized

Instead of handling it everywhere:

if(error.response.status===401){
// Logout
}

Create a response interceptor.

api.interceptors.response.use(
  response => response,
  error => {
   if(error.response?.status===401){
     // Redirect to Login
   }
  return Promise.reject(error);
});

One place handles authentication failures.

Loading States

Always show feedback while data loads.

const [loading, setLoading] = useState(true);

Example:

if (loading) {
  return <Spinner />;
}

Never leave users wondering if the application is working.

Error States

Display meaningful messages.

if (error) {
  return (<ErrorMessage message={error.message} />);
}

Avoid showing raw server errors to users.

Empty States

An API can return an empty list.

if(users.length===0){
  return <NoUsersFound />;
}

A good UI handles:

Loading
Success
Error
Empty data

API Service Layer

Avoid calling APIs directly inside components.

❌ Bad:

function Dashboard(){
 useEffect(()=>{
  axios.get("/users");
 },[]);
}

✅ Better:

services
└── userService.ts

export function getUsers(){
  return api.get("/users");
}

Component:

const users = await getUsers();

Business logic stays separate from UI.

Custom Hooks for API Calls

Combine services with Custom Hooks.

function useUsers(){
  // Fetch users
  // Handle loading
  // Handle errors
}

Component:

const { users, loading,error }=useUsers();

The component focuses only on rendering.

API Folder Structure

A scalable structure:

src
├── api
│   ├── axios.ts
│   ├── interceptors.ts
│
├── services
│   ├── authService.ts
│   ├── userService.ts
│   ├── accountService.ts
│   └── transactionService.ts

Each service manages one business domain.

Real-World Banking Example

Customer opens the dashboard.

Dashboard
   |
useAccounts()
   |
accountService
   |
Axios Client
   |
REST API
   |
Customer Accounts

The UI doesn't know how the request is made.

It simply displays the returned data.

Retry Strategy

Network failures happen.

Example:

  Request
    ↓
Network Error
    ↓
  Retry
    ↓
 Success

Libraries like Axios can be combined with retry mechanisms to improve reliability.

Security Best Practices

Never:

Store sensitive information in source code.
Expose API keys in frontend applications.
Trust client-side validation alone.

Always:

Use HTTPS.
Store tokens securely.
Validate input on both frontend and backend.

Common Mistakes

1. Calling APIs Inside Every Component

Duplicate requests waste bandwidth.

Move API logic into services and reusable hooks.

2. Ignoring Errors

Always handle:

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error

Provide user-friendly feedback.

3. Mixing UI and Business Logic

Keep components focused on rendering.

Move networking code into services.

4. Forgetting Cleanup

When a component unmounts during an API request, avoid updating state afterward.

Use request cancellation or cleanup mechanisms when appropriate.

Best Practices

Centralize Axios configuration.
Use request and response interceptors.
Separate services from UI.
Display loading, error, and empty states.
Reuse API logic through Custom Hooks.
Handle authentication globally.
Keep API endpoints configurable through environment variables.

Key Takeaways

Today, we learned:

✅ React applications communicate with backend services using APIs.
✅ Fetch and Axios are the two most common approaches.
✅ Axios provides powerful features like interceptors and automatic JSON parsing.
✅ API logic should live in a service layer, not inside components.
✅ Every application should handle loading, error, and empty states gracefully.
✅ Combining services with Custom Hooks leads to clean and maintainable code.

Coming Next 🚀

In Day 24, we will explore:

React Forms – Controlled Components, Validation & React Hook Form

We will learn:

Controlled vs Uncontrolled Components
Handling form state
Input validation
Form submission
React Hook Form
Schema validation with Zod/Yup
Dynamic forms
Enterprise form best practices

Forms are one of the most common features in any React application, and mastering them is essential for building production-ready user interfaces.

Happy Coding! 🚀