DEV Community: Abdul Halim

Exploring 4-Layer Frontend Architecture: A Practical Guide

Abdul Halim — Sun, 01 Mar 2026 07:40:09 +0000

Hey there, fellow developers! If you've been knee-deep in frontend code for a while, you know how quickly things evolve. What felt cutting-edge a couple of years ago can start to creak under the weight of scaling apps, team collaborations, and performance demands. Enter the 4-layer frontend architecture, a structured approach that's gaining traction in 2026 for building maintainable, scalable web apps. It's not some rigid dogma; think of it as a flexible blueprint inspired by clean architecture principles, adapted to modern tools like React Server Components, TanStack Query, and edge computing.

In this post, I'll break it down step by step, based on the latest trends from frameworks like Next.js and Remix. We'll cover what the layers are, a recommended folder structure, some real-world code examples, and why this setup might just save your sanity on your next project. Let's dive in. I've even included visuals to make it easier to grasp.

What Is 4-Layer Frontend Architecture?

At its core, this architecture separates concerns into four distinct layers, promoting loose coupling and easier testing. It's particularly useful in 2026's landscape, where frontends often blur lines with backends via server-side rendering (SSR), API orchestration at the edge, and AI-assisted code generation. The layers flow from the user-facing side inward:

Presentation Layer: Handles the UI components, views, and user interactions. This is where your React or Vue components live, focused on rendering and basic event handling.
Application Layer: Manages application-specific logic, like state orchestration, routing, and workflows. Tools like TanStack Query or Redux shine here for data fetching and mutations.
Domain Layer: Contains the core business rules, entities, and use cases. This is framework-agnostic stuff-models for your data and pure functions for logic that doesn't depend on UI or external services.
Infrastructure Layer: Deals with external dependencies, like API calls, local storage, or third-party integrations. In 2026, this often leverages edge functions or WebAssembly for performance.

The beauty? Changes in one layer ripple less to others. For instance, swapping out an API provider only touches the infrastructure layer.

This diagram illustrates a typical 4-layer setup in a modern web app, showing how data flows from the frontend through logic layers to the backend.

Recommended Folder Structure

Organizing your codebase is half the battle. In 2026, with meta-frameworks like Next.js dominating, a layer-based structure combined with feature-slicing keeps things tidy. Here's a sample for a React/Next.js app:

src/
├── app/                # Entry points, routing (Next.js app router)
├── presentation/       # UI components and pages
│   ├── components/     # Reusable UI like Button, Card
│   ├── pages/          # Page-level components (if not using app router)
│   └── hooks/          # UI-specific hooks
├── application/        # State management, services
│   ├── stores/         # TanStack Query clients, Zustand stores
│   ├── useCases/       # Application workflows
│   └── utils/          # App-wide utilities
├── domain/             # Business entities and logic
│   ├── entities/       # Models like User, Product
│   ├── repositories/   # Interfaces for data access
│   └── services/       # Pure business logic functions
├── infrastructure/     # External integrations
│   ├── api/            # API clients (e.g., Axios instances)
│   ├── storage/        # LocalStorage, IndexedDB wrappers
│   └── config/         # Environment configs
├── shared/             # Cross-layer utilities (e.g., types, constants)
└── tests/              # Unit/integration tests organized by layer

This structure scales well for teams, new features slot into layers without polluting the whole app. For larger projects, you could slice by domain (e.g., domain/user/) using Feature-Sliced Design principles, which are huge in 2026 for avoiding spaghetti code.

As seen in this visual, layering with slices and segments ensures high cohesion and low coupling, making refactors a breeze.

Code Examples: Bringing It to Life

Let's make this concrete with a simple e-commerce example in Next.js (the go-to in 2026 for its server components and React Compiler integration). Assume we're building a product listing feature.

1. Presentation Layer (UI Focus)
In src/presentation/components/ProductList.tsx:

'use client'; // Client-side for interactivity

import { useProducts } from '@/application/useCases/useProducts';

export function ProductList() {
  const { products, isLoading, error } = useProducts();

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <ul className="grid grid-cols-3 gap-4">
      {products.map((product) => (
        <li key={product.id} className="border p-4">
          <h2>{product.name}</h2>
          <p>${product.price}</p>
        </li>
      ))}
    </ul>
  );
}

This component is dumb, it just renders data and hooks into application logic.

2. Application Layer (Orchestration)
In src/application/useCases/useProducts.ts:

import { getProducts } from '@/domain/services/productService';
import { productRepository } from '@/infrastructure/api/productApi';

export function useProducts() {
  return useQuery({
    queryKey: ['products'],
    queryFn: () => getProducts(productRepository),
  });
}

Here, we're using TanStack Query to fetch and cache, bridging domain logic with the UI.

3. Domain Layer (Business Core)
In src/domain/entities/Product.ts:

export interface Product {
  id: string;
  name: string;
  price: number;
  // Validation logic could go here
  isValid(): boolean {
    return this.price > 0 && this.name.length > 0;
  }
}

And src/domain/services/productService.ts:

import { Product } from '@/domain/entities/Product';
import { ProductRepository } from '@/domain/repositories/ProductRepository';

export async function getProducts(repo: ProductRepository): Promise<Product[]> {
  const data = await repo.fetchAll();
  return data.filter((p) => p.isValid()); // Business rule application
}

Pure functions and interfaces, testable without mocks for APIs or UI.

4. Infrastructure Layer (Externals)
In src/infrastructure/api/productApi.ts:

import axios from 'axios';
import { Product } from '@/domain/entities/Product';

export const productRepository = {
  fetchAll: async (): Promise<Product[]> => {
    const response = await axios.get('/api/products');
    return response.data.map((item: any) => ({
      id: item.id,
      name: item.name,
      price: item.price,
    }));
  },
};

This handles the nitty-gritty of HTTP requests, easy to swap for GraphQL or edge APIs.

Why Adopt This in 2026?

Look, no architecture is perfect, but this one aligns with current trends. With the React Compiler handling memoization automatically, you focus less on perf hacks and more on structure. Micro-frontends? Each layer can be modularized across teams. Edge computing? Push infrastructure logic to CDNs like Vercel Edge for sub-50ms loads. Plus, it's testable: unit test domain logic in isolation, integrate application flows, and e2e the presentation.
Teams report 30-50% faster onboarding and fewer bugs, per recent surveys on scalable frontends. It's not overkill for small apps, but shines as they grow.

Wrapping Up

There you have it a down-to-earth take on 4-layer frontend architecture for 2026. It's all about building apps that last, without the headache. If you're starting a new project, give this structure a spin; tweak it to fit your stack.

Thanks for reading! Stay curious, keep coding.

Understanding Server Functions: TanStack Start vs Next.js

Abdul Halim — Thu, 08 Jan 2026 17:29:15 +0000

As a senior frontend engineer, I've extensively worked on Next.js and recently started studying TanStack Start. Today, I want to share insights about server functions and how these two frameworks approach them differently.

What Are Server Functions?

Server functions are functions that run exclusively on the server but can be called from client-side code. They bridge the gap between your frontend and backend, allowing you to write server-side logic alongside your React components without setting up separate API endpoints.

TanStack Start's Approach

TanStack Start takes a unique approach to server functions that emphasizes type safety and simplicity.

Creating a Server Function

In TanStack Start, you create a server function using the createServerFn function:

import { createServerFn } from '@tanstack/start'

export const getUser = createServerFn('GET', async (userId: string) => {
  // This code runs only on the server
  const user = await db.users.findOne({ id: userId })
  return user
})

The first argument specifies the HTTP method, and the second is your server-side logic. Simple and straightforward.

Key Features

Type Safety First: TanStack Start provides end-to-end type safety. The types from your server function automatically flow to the client, giving you autocomplete and type checking without extra configuration.

Explicit HTTP Methods: You explicitly define which HTTP method your function uses. This makes the intent clear and helps with caching and optimization.

// GET request - typically for data fetching
const getData = createServerFn('GET', async () => {...})

// POST request - for mutations
const createData = createServerFn('POST', async (data) => {...})

Direct Integration with TanStack Router: Server functions work seamlessly with TanStack Router's data loading system:

export const Route = createFileRoute('/users/$userId')({
  loader: async ({ params }) => {
    const user = await getUser(params.userId)
    return user
  },
})

Next.js Approach

Next.js uses Server Actions, which have a different philosophy.

Creating a Server Action

In Next.js, you use the 'use server' directive:

'use server'

export async function getUser(userId: string) {
  const user = await db.users.findOne({ id: userId })
  return user
}

You can also define inline server actions within components:

export default function MyComponent() {
  async function handleSubmit(formData: FormData) {
    'use server'
    // Server-side logic here
  }

  return <form action={handleSubmit}>...</form>
}

Key Characteristics

Form-Centric: Server Actions are designed primarily around form submissions and progressive enhancement.

Implicit POST Methods: By default, Server Actions use POST requests. This is great for mutations but can be less intuitive for data fetching.

Built into React: Server Actions are a React feature that Next.js leverages, meaning they're deeply integrated with React's concurrent features.

Key Differences

1. Explicitness vs Convention

TanStack Start is explicit about HTTP methods and function creation. You use createServerFn and specify the method upfront.

Next.js relies more on conventions. The 'use server' directive turns any function into a server action, which is convenient but less explicit.

2. Type Safety

TanStack Start provides stronger type safety out of the box. The connection between client and server code is more tightly coupled, giving you better TypeScript support.

Next.js relies on you to maintain type consistency between client and server, which can lead to more runtime errors if you are not careful.

3. HTTP Method Control

TanStack Start gives you fine-grained control over HTTP methods (GET, POST, PUT, DELETE, etc.).

Next.js Server Actions primarily use POST, though you can work around this with additional setup.

4. Integration with Data Loading

TanStack Start's server functions are designed to work seamlessly with its router's loader pattern, making data fetching predictable and type-safe.

Next.js Server Actions are more focused on mutations and form handling, with data fetching typically done through other mechanisms like Server Components.

5. Error Handling

Both frameworks handle errors differently:

// TanStack Start
const myFunction = createServerFn('POST', async (data) => {
  try {
    return await processData(data)
  } catch (error) {
    throw new Error('Processing failed')
  }
})

// Next.js
'use server'
async function myAction(data: FormData) {
  try {
    return await processData(data)
  } catch (error) {
    return { error: 'Processing failed' }
  }
}

When to Use Which?

Choose TanStack Start if you:

Want explicit, type-safe server functions
Need fine control over HTTP methods
Prefer a more traditional API-like approach
Value strong TypeScript integration

Choose Next.js if you:

Are heavily focused on form handling and mutations
Want progressive enhancement out of the box
Prefer React-centric solutions
Need the broader Next.js ecosystem

Conclusion

Both TanStack Start and Next.js offer powerful server function capabilities, but with different philosophies. TanStack Start provides more explicit control and stronger type safety, making it excellent for developers who want clarity and predictability. Next.js offers convenience and deep React integration, perfect for form-heavy applications.

Understanding these differences helps you choose the right tool for your project and use it effectively. Neither approach is inherently better; they solve similar problems with different trade-offs.

As frontend engineers, our job is to understand these nuances and make informed decisions based on our project's specific needs.

Here is my latest article to cover how to manage console logs in production.

Abdul Halim — Wed, 07 Jan 2026 15:29:10 +0000

Stop Shipping Your Dev Logs

Abdul Halim ・ Jan 7

#javascript #frontend #react #nextjs

Stop Shipping Your Dev Logs

Abdul Halim — Wed, 07 Jan 2026 15:20:07 +0000

As a senior frontend engineer, I've seen my fair share of "console log graveyards". You know the ones production websites where you open the DevTools and see a messy trail of Object { data: "test" } and HERE 1111 leaking everywhere.

It's messy, it can leak metadata, and it looks amateur. But we still need logs to build things quickly! In 2026, we don't just "turn off" logs; we manage them like pros. Here is the exact stack I use to keep my console clean and my sanity intact.

1. The Architectural Solution: The "Proxy" Logger

Instead of calling console.log directly, we create a small wrapper. Think of it as a "smart filter." By using a JavaScript proxy, we can mimic the entire console API without writing every method manually.

The TypeScript Implementation

Using typeof console ensures that your editor gives you full IntelliSense/autocomplete for every method (.log, .table, .group, etc.).

// utils/logger.ts
const isDev = process.env.NODE_ENV === 'development';

/**
 * The 'debug' proxy mirrors the console API perfectly.
 * In development: works normally.
 * In production: returns an empty function (no-op).
 */
export const debug = new Proxy(console, {
  get(target, prop: keyof typeof console) {
    if (isDev) {
      const value = target[prop];
      if (typeof value === 'function') {
        // Bind 'this' to target (console) so it doesn't lose context
        return value.bind(target);
      }
      return value;
    }

    // In production, return an empty function that does nothing
    return () => {};
  }
}) as typeof console;

2. Keeping ESLint and Biome Happy

Now that we have our debug tool, we need to ensure the team uses it instead of raw console.log.

For ESLint: Set your global rule to error on raw console calls.

// eslint.config.js
export default [{ rules: { "no-console": "error" } }];

For Biome: Use an override in biome.json so the linter ignores the noConsole rule only inside your logger utility.

{
  "linter": { "rules": { "suspicious": { "noConsole": "error" } } },
  "overrides": [
    {
      "include": ["src/utils/logger.ts"],
      "linter": { "rules": { "suspicious": { "noConsole": "off" } } }
    }
  ]
}

3. Real-World Usage: Seeing it in Action

Once set up, your daily workflow remains unchanged. You get all the power of the console without the risk of shipping it to users.

// components/UserDashboard.tsx
import { debug } from '../utils/logger';

export const UserDashboard = () => {
  const loadData = async () => {
    debug.group('Fetching Dashboard'); // Grouping keeps your dev console tidy

    try {
      const data = await fetch('/api/users').then(res => res.json());
      debug.log('Users received:', data.length);
      debug.table(data); // Beautiful table view in development!
    } catch (err) {
      debug.error('Failed to load:', err);
    } finally {
      debug.groupEnd();
    }
  };

  return <button onClick={loadData}>Load Data</button>;
};

4. The "Senior" Finishing Touch: Build-Time Stripping

Even though our proxy is silent in production, the code for those logs is still in your bundle. To be a true professional, you should physically remove them during the build.

For Next.js Projects

Use the built-in compiler in next.config.mjs:

const nextConfig = {
  compiler: {
    // Shreds all console.* calls during the production build
    removeConsole: process.env.NODE_ENV === 'production',
  },
};
export default nextConfig;

For Vite Projects

Tell Vite to "drop" these specific calls during the minification phase:

// vite.config.ts
export default defineConfig({
  esbuild: {
    drop: process.env.NODE_ENV === 'production' ? ['console', 'debugger'] : [],
  },
});

Why This Wins

By combining a proxy logger, strict linting, and compiler stripping, you've achieved the "golden path" of logging:

Zero Visual Noise: No more // eslint-disable comments.
Full Power: You still get .table(), .group(), and .warn() with full autocomplete.
Maximum Security: No sensitive strings leak into your production source code.
Optimal Performance: Your production bundle is smaller because the logs are physically deleted.

It's a small architectural change that makes a massive difference in the long-term health of a project. Happy coding!

Next.js Caching Evolution: From v14 to v15 and the Cache Components Era

Abdul Halim — Wed, 24 Dec 2025 14:18:36 +0000

Next.js has undergone significant caching philosophy changes. Version 14 aggressively cached by default, v15 made everything dynamic by default, and now with Cache Components (introduced in v15 canary and expanded in v16), we have explicit opt-in caching with the use cache directive. Understanding this evolution is crucial for modern Next.js development.

The Three Eras of Next.js Caching

v14 Era: Aggressive caching by default

v15 Era: Dynamic by default, opt into caching

Cache Components Era: Explicit caching with use cache directive

Part 1: The v14 → v15 Shift

v14: Cache by Default

In Next.js 14, fetch requests were automatically cached with force-cache as the default behavior, meaning data was cached indefinitely unless explicitly opted out.

// Next.js 14 - Cached by default
export default async function Page() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();
  // This was CACHED indefinitely
  return <ProductList products={products} />;
}

// v14: Opting out of cache
const res = await fetch('https://api.example.com/products', {
  cache: 'no-store' // Explicitly disable caching
});

v15: Dynamic by Default

Next.js 15 changed the default behavior so fetch requests are not cached by default. You must explicitly opt into caching.

// Next.js 15 - NOT cached by default
export default async function Page() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();
  // Fresh data on every request
  return <ProductList products={products} />;
}

// v15: Opting into cache
const res = await fetch('https://api.example.com/products', {
  cache: 'force-cache' // Explicitly enable caching
});

Part 2: Understanding the Four Caching Layers

Next.js operates with four distinct caching mechanisms that work together. Understanding their interaction is essential.

Layer 1: Request Memoization

Request memoization happens automatically within a single render pass, deduplicating identical fetch requests during rendering.

// Multiple components making the same request
async function Header() {
  const user = await fetch('/api/user'); // Request 1
  return <div>{user.name}</div>;
}

async function Sidebar() {
  const user = await fetch('/api/user'); // Deduplicated automatically
  return <nav>{user.email}</nav>;
}

export default function Page() {
  return (
    <>
      <Header />
      <Sidebar />
    </> // Only ONE actual network request
  );
}

Scope: Single request/render cycle

Duration: Until response is sent

Control: Automatic (React optimization)

Version changes: No change between v14, v15, or v16

Layer 2: Data Cache (The Major Change)

The Data Cache persists fetch results across incoming server requests and deployments. This is where v14 and v15 differ fundamentally.

v14 behavior:

// Cached indefinitely by default
const res = await fetch('/api/products');
// To make it dynamic, add:
const res = await fetch('/api/products', { cache: 'no-store' });

v15 behavior:

// Dynamic by default
const res = await fetch('/api/products');

// To cache it, add:
const res = await fetch('/api/products', { 
  cache: 'force-cache' 
});

// Or with time-based revalidation:
const res = await fetch('/api/products', {
  next: { revalidate: 3600 } // Revalidate every hour
});

Layer 3: Full Route Cache

The Full Route Cache stores rendered HTML and RSC payload for static routes. Routes are statically rendered at build time or dynamically at request time.

// v15: Routes are dynamic by default
export default async function Page() {
  const data = await getData();
  return <div>{data}</div>;
  // Rendered on every request
}

// Opt into static generation
export const dynamic = 'force-static';

export default async function Page() {
  const data = await getData();
  return <div>{data}</div>;
  // Rendered once at build time
}

Configuration options:

dynamic = 'auto' - Automatic (default in v15)
dynamic = 'force-static' - Force static generation
dynamic = 'force-dynamic' - Force dynamic rendering
dynamic = 'error' - Error if dynamic functions used

Layer 4: Router Cache (Client-Side)

The Router Cache stores RSC payload in the browser during navigation, and as of Next.js 15, page segments are opted out by default.

v14: Cached for 30 seconds (dynamic), 5 minutes (static)

v15: 0 seconds by default (effectively disabled for dynamic routes)

// next.config.js - Configure client cache in v15
module.exports = {
  experimental: {
    staleTimes: {
      dynamic: 30,  // 30 seconds for dynamic routes
      static: 180,  // 3 minutes for static routes
    },
  },
};

Part 3: Cache Components with `use cache`

Cache Components center around the new use cache directive, making caching entirely opt-in and more explicit than previous versions.

Enabling Cache Components

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Basic Usage

The use cache directive can be applied at the page, component, or function level:

// Page-level caching
export default async function Page() {
  'use cache';

  const random = Math.random();
  const now = Date.now();

  return (
    <div>
      <p>{random}</p>
      <p>{now}</p>
    </div>
  );
  // All requests will see the same values until revalidated
}

// Component-level caching
export async function ProductList() {
  'use cache';

  const products = await fetch('/api/products').then(r => r.json());
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

// Function-level caching
export async function getProducts() {
  'use cache';

  const res = await fetch('/api/products');
  return res.json();
}

Using cacheLife Profiles

By default, use cache uses the default profile with 5 minutes client-side stale time, 15 minutes server-side revalidate, and never expires.

import { cacheLife } from 'next/cache';

export async function getData() {
  'use cache';
  cacheLife('hours'); // Use built-in 'hours' profile

  return fetch('/api/data').then(r => r.json());
}

// Define custom profiles in next.config.ts
const nextConfig: NextConfig = {
  cacheComponents: true,
  cacheLife: {
    biweekly: {
      stale: 60 * 60 * 24 * 14,    // 14 days
      revalidate: 60 * 60 * 24,    // 1 day  
      expire: 60 * 60 * 24 * 14,   // 14 days
    },
  },
};

Cache Invalidation

Use cacheTag to tag cached data and revalidateTag to invalidate it on-demand:

import { cacheTag, updateTag, revalidateTag } from 'next/cache';

// Tag the cache
export async function getProducts() {
  'use cache';
  cacheTag('products');

  return db.query('SELECT * FROM products');
}

// Invalidate immediately (Server Actions)
export async function updateProduct(id: string) {
  'use server';

  await db.products.update({ id });
  updateTag('products'); // Immediate cache expiration
}

// Invalidate with stale-while-revalidate
export async function refreshProducts() {
  await someUpdate();
  revalidateTag('products', 'max'); // Recommended approach
}

Migration Guide

From v14 to v15

Step 1: Identify and remove unnecessary cache configurations

// v14 - Remove these in v15 (now default):
{ cache: 'no-store' }
{ next: { revalidate: 0 } }
export const revalidate = 0;

// v15 - Keep/add these:
{ cache: 'force-cache' }
{ next: { revalidate: 60 } }
export const dynamic = 'force-static';

Step 2: Add caching where beneficial

// Static data - aggressive caching
const config = await fetch('/api/config', {
  cache: 'force-cache'
});

// Semi-dynamic - time-based revalidation
const products = await fetch('/api/products', {
  next: { revalidate: 300 } // 5 minutes
});

// User-specific - keep dynamic (no config needed)
const userData = await fetch('/api/user');

Migrating to Cache Components

// Before: v15 with fetch caching
export default async function Page() {
  const data = await fetch('https://api.example.com/data', {
    next: { revalidate: 3600 }
  }).then(r => r.json());

  return <div>{data}</div>;
}

// After: Cache Components approach
import { cacheLife } from 'next/cache';

export default async function Page() {
  'use cache';
  cacheLife('hours');

  const data = await fetch('https://api.example.com/data')
    .then(r => r.json());

  return <div>{data}</div>;
}

Real-World Patterns

Pattern 1: Hybrid E-commerce Page

export default async function ProductPage({ params }) {
  // Categories rarely change - cache aggressively
  const categories = await fetch('/api/categories', {
    next: { revalidate: 86400 } // 24 hours
  }).then(r => r.json());

  // Product data changes moderately
  const product = await fetch(`/api/products/${params.id}`, {
    next: { revalidate: 300 } // 5 minutes
  }).then(r => r.json());

  // Stock levels change frequently - keep dynamic
  const stock = await fetch(`/api/stock/${params.id}`)
    .then(r => r.json());

  return <ProductView product={product} stock={stock} categories={categories} />;
}

Pattern 2: Static Marketing with Dynamic Pricing

export default async function LandingPage() {
  'use cache';
  cacheLife('weeks');

  // Static content cached for weeks
  return (
    <>
      <Hero />
      <Features />
      <Suspense fallback={<div>Loading pricing...</div>}>
        <DynamicPricing />
      </Suspense>
    </>
  );
}

// Dynamic pricing without suspense wrapper
async function DynamicPricing() {
  const prices = await fetch('/api/pricing').then(r => r.json());
  return <PricingTable prices={prices} />;
}

Decision Matrix

Data Type	v15 Strategy	Cache Components
Config/Settings	`cache: 'force-cache'`	`'use cache'` + `cacheLife('max')`
Marketing Content	`dynamic = 'force-static'`	`'use cache'` at page level
Product Catalog	`revalidate: 300`	`'use cache'` + `cacheLife('minutes')`
User Dashboards	Default (dynamic)	Wrap in `<Suspense>`
Real-time Data	Default (dynamic)	No caching

Performance Considerations

Although fetch requests are not cached by default in v15, Next.js will pre-render routes and cache the HTML for improved performance.

When to use each approach:

Use v15 fetch caching for simple, straightforward caching needs
Use Cache Components when you need:
- Caching beyond fetch (database queries, file operations)
- Fine-grained cache invalidation with tags
- Partial prerendering with dynamic sections
- Complex cache lifetime management

Key Takeaways

v14 → v15: Default changed from cached to dynamic for fetch requests
Four layers: Request Memoization, Data Cache, Full Route Cache, Router Cache
Cache Components: New explicit opt-in model with use cache directive
Migration path: Remove cache: 'no-store', add cache: 'force-cache' where needed
Modern approach: Cache strategically, not by default

The evolution from v14's aggressive caching to v15's dynamic defaults and now Cache Components represents Next.js maturing toward explicit, predictable caching behavior that developers can reason about clearly.

Mastering Code Splitting in Next.js App Router

Abdul Halim — Thu, 11 Sep 2025 17:27:28 +0000

Hey fellow developers! After leading multiple Next.js projects and watching junior developers struggle with bundle sizes that could rival a small city's phone book, I thought it was time to share some battle-tested strategies for code splitting in the App Router.

The Reality Check: Why Your Users Are Bouncing

Picture this: You've built an amazing e-commerce platform with every bell and whistle imaginable. Charts, maps, rich text editors, PDF generators - the whole nine yards. But your users are hitting the back button faster than you can say "dynamic import."

The culprit? That 2MB initial bundle that includes your entire kitchen sink, even though 80% of users never touch the admin dashboard or generate a single PDF.

App Router: The Game Changer (But Not Magic)

With Next.js 13+ App Router, React Server Components are automatically code-split by default. That's fantastic news, but here's the catch - client components still need our attention. And trust me, that's where the real optimization magic happens.

Real-World Scenario: Building a SaaS Dashboard

Let me walk you through a real project, a SaaS analytics dashboard. There are several heavy features:

A complex data visualization dashboard (Chart.js + D3)
A rich text editor for reports (Monaco Editor)
PDF export functionality (jsPDF)
Real-time chat support widget

The Smart Way: Strategic Component Splitting

Here's how we tackled the dashboard with dynamic imports:

'use client'
import { useState } from 'react'
import dynamic from 'next/dynamic'

*// Lazy load heavy components*
const AnalyticsDashboard = dynamic(() => import('./AnalyticsDashboard'), {
  loading: () => <DashboardSkeleton />,
  ssr: false
})

const ReportEditor = dynamic(() => import('./ReportEditor'), {
  loading: () => <EditorSkeleton />
})

const ChatWidget = dynamic(() => import('./ChatWidget'), {
  ssr: false *// Browser-only widget with window/localStorage dependencies*
})

export default function DashboardPage() {
  const [activeTab, setActiveTab] = useState('overview')
  const [showChat, setShowChat] = useState(false)

  return (
    <div className="dashboard">
      <nav>
        <button onClick={() => setActiveTab('overview')}>Overview</button>
        <button onClick={() => setActiveTab('analytics')}>Analytics</button>
        <button onClick={() => setActiveTab('reports')}>Reports</button>
      </nav>

      {activeTab === 'analytics' && <AnalyticsDashboard />}
      {activeTab === 'reports' && <ReportEditor />}
      {showChat && <ChatWidget onClose={() => setShowChat(false)} />}
    </div>
  )
}

Result: Initial bundle size dropped from 1.8MB to 350KB. Users on the overview tab got a lightning-fast experience.

Pro Tip: Smart External Library Loading

Here's a pattern I use for heavy external dependencies. Instead of importing jsPDF at the top level, we load it on demand:

'use client'
import { useState, useRef } from 'react'

export default function InvoiceGenerator() {
  const [isGenerating, setIsGenerating] = useState(false)
  const jsPdfRef = useRef(null)

  const generatePDF = async (invoiceData) => {
    setIsGenerating(true)

    *// Load jsPDF only when actually needed*
    if (!jsPdfRef.current) {
      const jsPdfModule = await import('jspdf')
      jsPdfRef.current = jsPdfModule.default
    }

    const pdf = new jsPdfRef.current()
    *// ... PDF generation logic*

    setIsGenerating(false)
  }

  const preloadPDF = async () => {
    *// Preload when user hovers over the button*
    if (!jsPdfRef.current) {
      const jsPdfModule = await import('jspdf')
      jsPdfRef.current = jsPdfModule.default
    }
  }

  return (
    <button 
      onMouseEnter={preloadPDF}
      onClick={() => generatePDF(invoiceData)}
      disabled={isGenerating}
    >
      {isGenerating ? 'Generating...' : 'Download PDF'}
    </button>
  )
}

This pattern gives us the best of both worlds: tiny initial bundles and responsive UX through preloading.

The Server Component Twist

Here's something that confused any developer initially - you can dynamically import server components too:

import dynamic from 'next/dynamic'

const HeavyServerComponent = dynamic(() => import('./HeavyServerComponent'))

export default function ServerPage() {
  return (
    <div>
      <h1>My Page</h1>
      <HeavyServerComponent />
    </div>
  )
}

But here's the kicker: this doesn't optimize server-side loading. What it does is enable lazy loading of any nested client components within that server component. It's a subtle but important distinction.

When NOT to Use Dynamic Imports

Learning from mistakes (yes, I've made them too):

Don't dynamically import:

Above-the-fold content (LCP killer)
Small utility components (<5KB)
Critical navigation elements
Components needed for SEO

Do dynamically import:

Modal dialogs and overlays
Feature-specific heavy components
Third-party widgets
Admin panels and rarely-used features
Device-specific components

Advanced Pattern: Conditional Feature Loading

For our SaaS, we implemented feature-flag-based loading:

'use client'
import { useFeatureFlag } from '@/hooks/useFeatureFlag'
import dynamic from 'next/dynamic'

const AdvancedAnalytics = dynamic(() => import('./AdvancedAnalytics'))
const BasicAnalytics = dynamic(() => import('./BasicAnalytics'))

export default function AnalyticsWrapper() {
  const hasAdvancedFeatures = useFeatureFlag('advanced-analytics')

  return hasAdvancedFeatures ? <AdvancedAnalytics /> : <BasicAnalytics />
}

This lets us ship different bundle sizes based on user subscription tiers. Premium users got the heavy charting libraries; basic users got a lightweight version.

Measuring Success: The Numbers That Matter

After implementing these patterns across our dashboard:

Initial bundle size: 1.8MB → 350KB (-81%)
Time to Interactive: 4.2s → 1.8s (-57%)
First Contentful Paint: 2.1s → 0.9s (-57%)
Bounce rate: 23% → 8% (-65%)

The Developer Experience Bonus

One unexpected benefit: our development builds became significantly faster. Hot reloads went from 3-4 seconds to under 1 second because we weren't recompiling massive chunks unnecessarily.

Wrapping Up

Code splitting in App Router isn't just about performance - it's about building sustainable, scalable applications. Start with the heavy hitters (charts, editors, PDFs), implement smart preloading, and always measure the impact.

Remember: your users don't care about your fancy features if they can't even load your app. Make the initial experience snappy, then progressively enhance with dynamic imports.

Before You Code: A Senior Frontend Dev’s Thought Process

Abdul Halim — Thu, 15 May 2025 14:38:11 +0000

Good code is not just about making things work—it's about making things work well, together.

When starting a new feature, junior devs often jump into coding. Senior devs pause to think first.

In this post, I’ll walk you through a mental checklist I use before writing a single line of code—something I’ve honed over years of building frontend features in React, Next.js, and beyond.

1. Understand the Feature

Before writing JSX...

What does this component need to do?
Are there dynamic behaviors like modals, dropdowns, and toggles?
Will it fetch data? From where? How often?
Can I reuse existing hooks, utilities, or services?

Think: What problem am I solving, and has someone already solved parts of it?

2. Map the Data Flow

Clarity here avoids spaghetti later.

What are the inputs? (props, query params, context)
What outputs or events does it trigger? (onClick, onChange)
How will data flow across components?
Do I need a wrapper or a layout component?

Think: Can a future teammate trace this flow in 30 seconds?

3. Choose the Right State Strategy

Every piece of state needs a home.

Local (useState) or lifted to a parent?
Global (Zustand, Redux, Context) if shared across features?
Should it persist? (e.g., localStorage)
Does it affect multiple components or pages?

Think: Am I overengineering or under-planning the state?

4. Design for Reusability

Avoid copy-pasting tomorrow what you hardcode today.

Can this component or part of it be reused?
Should I make it generic (e.g., Dropdown) or contextual (e.g., UserDropdown)?
Do we already have something similar I can tweak?
Should this logic live in a custom hook or utility?

Think: Will I regret hardcoding this next week?

5. Don’t Ignore Performance

Bad UX often hides behind slow code.

Are we dealing with large datasets, rapid user input, or complex visuals?
Use debounce, memoization, or virtualization where needed.
Can I break this into smaller pieces to reduce re-renders?
Are there animations or blocking tasks that need concurrency?

Think: Will this slow down on low-end devices?

6. Plan for Failure (Because It Will)

A broken UI is a bad experience. Silence is worse.

What happens if the API fails? Or returns no data?
Do we need retries? Fallbacks?
Should we use ErrorBoundary, Suspense, or manual error states?
How do we inform the user and log the issue?

Think: Can this fail gracefully?

Final Thoughts

The goal isn’t to overthink—it’s to pre-think.

Spending 10–15 minutes planning a feature can save hours of refactoring, debugging, and technical debt.

🛠️ Code is craft. Build thoughtfully.

React, Vue, and Angular: Unpacking the Top JavaScript Frameworks

Abdul Halim — Fri, 02 May 2025 13:50:35 +0000

As a Senior Frontend Engineer, I’ve spent years crafting web applications with React, Vue, and Angular, watching them evolve into the powerhouses they are today. In 2025, these frameworks—React, Vue, and Angular - remain the cornerstones of modern frontend development, each bringing unique strengths to the table. They’re popular for their ability to build fast, scalable, and engaging user interfaces, backed by vibrant communities and robust ecosystems. In this post, I’ll share a clear perspective on why they’re so widely used, how they work behind the scenes, their rendering processes, state management approaches, and what ties them together or sets them apart.

Why These Frameworks Dominate in 2025

React, Vue, and Angular lead the frontend world because they deliver reliable, high-performance solutions for projects of all sizes. Recent developer surveys, like those from 2024, show React holding strong with over 40% adoption, Vue at around 20%, and Angular at 15%. Their staying power comes from their adaptability and strong backing:

React, maintained by Meta, is prized for its flexibility and massive library ecosystem, making it a favorite for dynamic applications.
Vue, led by Evan You, is celebrated for its simplicity and progressive adoption, perfect for both small and large projects.
Angular, supported by Google, is the go-to for structured, enterprise-grade applications with built-in tools for scalability.

Let’s explore what makes each framework tick in 2025, from their inner workings to how they render UIs and manage state.

Inside the Frameworks: How They Work

Each framework has a distinct approach to building web applications, but they all aim to create responsive, user-friendly interfaces. Here’s a peek under the hood.

React: The Flexible Component Library

React 19 isn’t a full framework but a library focused on building reusable UI components. Its core innovation is the Virtual DOM, a lightweight representation of the browser’s DOM that enables efficient updates. React’s philosophy is all about simplicity: you create components, pass data through a one-way flow (from parent to child via props), and React handles the rendering. Its JSX syntax blends HTML-like code with JavaScript, making it intuitive to write. React 19 introduces improved compiler optimizations and server components, enhancing performance for both client and server-side rendering. Its flexibility lets you pair it with any tool, though it requires you to make more architectural choices.

Vue: The Progressive Powerhouse

Vue strikes a perfect balance between ease of use and advanced capabilities, earning its “progressive” label. You can drop it into a simple webpage or scale it for complex single-page applications (SPAs). Vue’s reactivity system, powered by JavaScript Proxies, automatically tracks data changes and updates the UI with minimal overhead. Its template syntax is clean and declarative, using directives like v-bind to simplify logic. Vue 3.5 enhances performance with faster rendering and smaller bundle sizes, while its single-file components (combining HTML, CSS, and JavaScript) streamline development. It’s a joy for developers who value clarity and speed.

Angular: The Enterprise Framework

Angular is a comprehensive, opinionated framework designed for large-scale applications. Unlike React and Vue, it comes with a full toolkit—routing, forms, testing, and more built in. Angular organizes code into modules and uses dependency injection to manage services, ensuring consistency across teams. Its template syntax supports two-way data binding, making complex interactions straightforward. Angular 19 introduces signals, a new reactive primitive that simplifies state management and improves standalone components for lighter, more modular apps. While its learning curve is steeper, it’s ideal for enterprises needing structure and scalability.

Rendering: Turning Code into Visuals

Rendering is how frameworks transform your code into the interfaces users see. Each framework optimizes this process differently to ensure speed and efficiency.

React Rendering

React 19 relies on its Virtual DOM to keep rendering fast. When data changes, React generates a new Virtual DOM, compares it to the previous one (a process called reconciliation), and updates only the necessary parts of the real DOM. React 19’s React Compiler (formerly React Forget) automates memoization, reducing unnecessary re-renders and boosting performance. Its asynchronous rendering, powered by React Fiber, prioritizes critical updates (like user interactions) for a smoother experience. Server Components, a highlight of React 19, allow parts of the UI to render on the server, reducing client-side JavaScript and improving load times.

Vue Rendering

Vue combines a Virtual DOM with its reactivity system for precise, efficient updates. When a reactive data property changes, Vue identifies the affected components and updates only those DOM nodes, avoiding full re-renders. Vue 3.5’s compiler optimizes render functions by hoisting static content and caching dynamic parts, resulting in faster execution and smaller bundles. This makes Vue particularly performant for applications with frequent UI updates, like dashboards or real-time forms, while keeping the developer experience straightforward.

Angular Rendering

Angular uses a real DOM with a sophisticated change detection system powered by zone.js. When an event (like a click or API response) occurs, Angular checks components for data changes and updates the DOM accordingly. Angular 19’s Ivy renderer and new signals feature optimize this process by enabling fine-grained reactivity, reducing unnecessary checks. Developers can further tune performance with change detection strategies like OnPush, which limits updates to specific components. This makes Angular robust for complex, data-heavy applications.

State Management: Keeping Data in Sync

State management is how frameworks handle dynamic data, from simple counters to global app states. Each framework offers built-in and external solutions tailored to different needs.

React State Management

React provides hooks like useState and useReducer for managing local component state, while useContext shares data across components. For complex applications, developers often turn to libraries like Redux, Zustand, or Jotai. Redux remains popular for its predictable single-store model, though Zustand and Jotai are gaining traction for their simplicity and hook-based APIs. React 19’s improved hooks and server components make state management more seamless, especially for server-rendered apps, but choosing the right library depends on your project’s scale.

Vue State Management

Vue reactivity system (via ref and reactive) is built-in and intuitive, handling local state effortlessly. The Composition API allows reusable state logic through composables, keeping code modular. For global state, Pinia is Vue’s official state management library, offering a lightweight, type-safe store that integrates tightly with Vue’s reactivity. Pinia has largely replaced Vuex in 2025 due to its simplicity and better TypeScript support. Vue’s state management feels natural and cohesive, making it ideal for rapid development.

Angular State Management

Angular leans on RxJS observables and services for reactive state management. Components subscribe to observables to receive updates, making it powerful for handling asynchronous data like API responses. The new signals feature in Angular 19 offers a simpler, hook-like way to manage reactive state, reducing reliance on RxJS for smaller apps. For large-scale projects, NgRx provides a Redux-inspired store with actions and effects. While RxJS and NgRx can be complex, Angular’s structured approach ensures consistency in enterprise environments.

What They Share: Common Ground

Despite their differences, React, Vue, and Angular have much in common:

Component-Based Architecture: All three use reusable components to build modular UIs.
Reactivity: Each has a system (Virtual DOM, reactivity, or change detection) to keep UIs in sync with data.
TypeScript Integration: Strong TypeScript support ensures type-safe development.
Ecosystems: Vast communities, rich libraries, and tools like CLI scaffolds streamline workflows.
SPA Focus: Built-in routing (React Router, Vue Router, Angular Router) powers single-page applications.

How They Differ: Key Distinctions

Choosing the Right Framework in 2025

Picking a framework depends on your project and team:

React: Choose for flexibility and a vast ecosystem. It’s perfect for dynamic, UI-focused apps like social platforms or e-commerce sites.
Vue: Opt for rapid development and simplicity. It’s great for startups or projects needing progressive adoption.
Angular: Go with Angular for enterprise applications, like internal tools or banking systems, where structure and scalability are critical.

Final Thoughts

React, Vue, and Angular are remarkable tools, each shaped by years of innovation and community feedback. React offers freedom, Vue delivers simplicity, and Angular provides structure—there’s no one-size-fits-all. As a Senior Engineer, I encourage you to try them out, weigh your project’s needs, and consider your team’s expertise. For me, the joy of frontend development lies in picking the right tool for the job and watching it bring ideas to life.

Next.js 15: Unleashing the Future of Web Development

Abdul Halim — Thu, 06 Feb 2025 18:58:38 +0000

Next.js has consistently pushed the boundaries of React development, and version 15 is no exception. It's packed with features that promise to enhance performance, streamline development, and unlock new possibilities. Let's dive into some of the most exciting additions and see how they can be applied in real-world situations.

1. Improved Turbopack Performance:

Turbopack, Next.js's new Rust-based bundler, receives significant performance enhancements in v15. Think of faster startup times, hot reloads, and a snappier development experience.

Real-world scenario: Imagine you're working on a complex e-commerce site with hundreds of components and images. Previously, build times might have been a bottleneck. With Turbopack's optimizations, you'll see a dramatic reduction in build and rebuild times, allowing you to iterate faster and deliver features more quickly. This translates to increased developer productivity and faster time-to-market for your application.

2. Stable Server Components:

Server Components, introduced in earlier versions, are now stable and ready for prime time. These components execute on the server, enabling you to fetch data directly, access databases, and interact with APIs without the overhead of client-side JavaScript.

Real-world scenario: Consider building a dynamic blog. With Server Components, you can fetch blog post data directly from your database on the server, render the content, and send only the HTML to the client. This drastically improves initial page load and SEO. No more client-side data-fetching spinners!

3. Enhanced Metadata Handling:

Next.js 15 improves metadata management, making it easier to control how your pages appear in search engine results and social media previews.

Real-world scenario: Building a portfolio website? You can dynamically generate meta descriptions, title tags, and Open Graph tags for each project page. This ensures that when someone shares your project on social media, a rich preview with the project's image and description is displayed, driving more traffic to your site.

4. Optimized Image Optimization:

Image optimization is crucial for web performance. Next.js 15 likely includes refinements to its image component (next/image), potentially with improvements to automatic image sizing, format selection, and lazy loading.

Real-world scenario: Suppose you're developing a photography website. Next.js's optimized image component will automatically serve images in the most efficient format (WebP, AVIF, etc.) and resize them appropriately for different devices. This results in faster loading times and a better user experience, especially on mobile devices.

5. Improved Developer Experience:

Next.js 15 likely includes various improvements to the developer experience, such as better error messages, more intuitive APIs, and enhanced tooling. These might seem like small changes, but they can significantly impact your day-to-day workflow.

Real-world scenario: Clearer and more informative error messages make debugging easier and faster. Improved tooling simplifies common tasks, such as creating new pages or components. These enhancements free up developers to focus on building features rather than wrestling with tooling issues.

6. (And other potential features):

Keep an eye out for other features like improved routing, enhanced support for React 19 features, and potentially new experimental features that could revolutionize how we build web applications. The Next.js team is constantly innovating, so there's always something exciting on the horizon.

Conclusion:

Next.js 15 is a significant release that empowers developers to build faster, more performant, and more engaging web applications. The combination of Turbopack's speed, stable Server Components, and other enhancements makes it an exciting time to be a Next.js developer. As you explore these features, you'll discover new ways to optimize your workflows and create exceptional user experiences.

Mastering TypeScript Utility and Advanced Types

Abdul Halim — Thu, 30 Jan 2025 16:11:43 +0000

TypeScript provides a variety of utility types and advanced types that help with common type transformations. These utility types are built into TypeScript and can be used to manipulate and transform types in various ways. Below is a comprehensive list of all the utility types and advanced types in TypeScript.

1. `Partial<T>`

Constructs a type with all properties of T set to optional.

interface User {
  id: number;
  name: string;
  age: number;
}

type PartialUser = Partial<User>;
// Equivalent to:
// {
//   id?: number;
//   name?: string;
//   age?: number;
// }

2. `Required<T>`

Constructs a type with all properties of T set to required.

interface User {
  id?: number;
  name?: string;
  age?: number;
}

type RequiredUser = Required<User>;
// Equivalent to:
// {
//   id: number;
//   name: string;
//   age: number;
// }

3. `Readonly<T>`

Constructs a type with all properties of T set to read-only.

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

type ReadonlyUser = Readonly<User>;
// Equivalent to:
// {
//   readonly id: number;
//   readonly name: string;
// }

4. `Record<K, T>`

Constructs an object type whose keys are K and values are T.

type UserRoles = Record<string, boolean>;
// Equivalent to:
// {
//   [key: string]: boolean;
// }

const roles: UserRoles = {
  admin: true,
  user: false,
};

5. `Pick<T, K>`

Constructs a type by picking a set of properties K from T.

interface User {
  id: number;
  name: string;
  age: number;
}

type UserNameAndAge = Pick<User, 'name' | 'age'>;
// Equivalent to:
// {
//   name: string;
//   age: number;
// }

6. `Omit<T, K>`

Constructs a type by omitting a set of properties K from T.

interface User {
  id: number;
  name: string;
  age: number;
}

type UserWithoutAge = Omit<User, 'age'>;
// Equivalent to:
// {
//   id: number;
//   name: string;
// }

7. `Exclude<T, U>`

Excludes from T all types that are assignable to U.

type T = string | number | boolean;
type U = string | boolean;

type Result = Exclude<T, U>; // Result is `number`

8. `Extract<T, U>`

Extracts from T all types that are assignable to U.

type T = string | number | boolean;
type U = string | boolean;

type Result = Extract<T, U>; // Result is `string | boolean`

9. `NonNullable<T>`

Excludes null and undefined from T.

type T = string | number | null | undefined;
type Result = NonNullable<T>; // Result is `string | number`

10. `ReturnType<T>`

Constructs a type consisting of the return type of function T.

function getUser() {
  return { id: 1, name: 'John' };
}

type UserReturnType = ReturnType<typeof getUser>;
// Equivalent to:
// {
//   id: number;
//   name: string;
// }

11. `InstanceType<T>`

Constructs a type consisting of the instance type of a constructor function T.

class User {
  id: number;
  name: string;

  constructor(id: number, name: string) {
    this.id = id;
    this.name = name;
  }
}

type UserInstance = InstanceType<typeof User>; // Equivalent to `User`

12. `ThisParameterType<T>`

Extracts the type of this parameter of a function type

function getUser(this: { id: number }) {
  return this.id;
}

type ThisType = ThisParameterType<typeof getUser>; // { id: number }

13. `OmitThisParameter<T>`

Removes this parameter from a function type T.

function getUser(this: { id: number }) {
  return this.id;
}

type FunctionWithoutThis = OmitThisParameter<typeof getUser>; // () => number

14. `Parameters<T>`

Constructs a tuple type from the parameter types of a function type T.

function getUser(id: number, name: string) {
  return { id, name };
}

type UserParams = Parameters<typeof getUser>; // [number, string]

15. `ConstructorParameters<T>`

Constructs a tuple type from the parameter types of a constructor function type T.

class User {
  constructor(public id: number, public name: string) {}
}

type UserConstructorParams = ConstructorParameters<typeof User>; // [number, string]

Advanced Types

1. Conditional Types

Conditional types allow you to define types based on conditions.

type IsString<T> = T extends string ? true : false;

type A = IsString<'hello'>; // true
type B = IsString<123>; // false

2. Mapped Types

Mapped types allow you to create new types by transforming properties of existing types.

type Optional<T> = {
  [K in keyof T]?: T[K];
};

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

type OptionalUser = Optional<User>;
// Equivalent to:
// {
//   id?: number;
//   name?: string;
// }

3. Template Literal Types

Template literal types allow you to create new string literal types by combining existing ones.

type EventName = 'click' | 'scroll';
type EventHandler = `on${Capitalize<EventName>}`; // 'onClick' | 'onScroll'

4. Recursive Types

Recursive types allow you to define types that reference themselves.

type Json =
  | string
  | number
  | boolean
  | null
  | { [key: string]: Json }
  | Json[];

const data: Json = {
  name: 'John',
  age: 30,
  hobbies: ['reading', 'coding'],
};

5. Index Access Types

Index access types allow you to access the type of a property of another type.

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

type UserId = User['id']; // number
type UserName = User['name']; // string

6. Keyof Operator

The keyof operator creates a union type of all the keys in an object type.

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

type UserKeys = keyof User; // 'id' | 'name'

7. Type Assertions

Type assertions allow you to specify the type of a value explicitly.

let value: any = 'hello';
let length = (value as string).length; // Type assertion

8. Type Guards

Type guards allow you to narrow down the type of a variable within a conditional block.

function isString(value: any): value is string {
  return typeof value === 'string';
}

let value: string | number = 'hello';
if (isString(value)) {
  console.log(value.toUpperCase()); // Type narrowed to `string`
}

Typescript's utility and advanced types are a game-changer for developers looking to write robust and maintainable code. From simplifying type transformations with Partial, Pick, and Omit to creating complex conditional and recursive types, these tools empower you to handle a wide range of scenarios with ease. By mastering these types, you can significantly improve your productivity and reduce the likelihood of runtime errors in your applications.

DEV Community: Abdul Halim

Exploring 4-Layer Frontend Architecture: A Practical Guide

What Is 4-Layer Frontend Architecture?

Recommended Folder Structure

Code Examples: Bringing It to Life

Why Adopt This in 2026?

Wrapping Up

Understanding Server Functions: TanStack Start vs Next.js

What Are Server Functions?

TanStack Start's Approach

Creating a Server Function

Key Features

Next.js Approach

Creating a Server Action

Key Characteristics

Key Differences

1. Explicitness vs Convention

2. Type Safety

3. HTTP Method Control

4. Integration with Data Loading

5. Error Handling

When to Use Which?

Conclusion

Here is my latest article to cover how to manage console logs in production.

Stop Shipping Your Dev Logs

Abdul Halim ・ Jan 7

Stop Shipping Your Dev Logs

1. The Architectural Solution: The "Proxy" Logger

The TypeScript Implementation

2. Keeping ESLint and Biome Happy

3. Real-World Usage: Seeing it in Action

4. The "Senior" Finishing Touch: Build-Time Stripping

For Next.js Projects

For Vite Projects

Why This Wins

Next.js Caching Evolution: From v14 to v15 and the Cache Components Era

The Three Eras of Next.js Caching

Part 1: The v14 → v15 Shift

v14: Cache by Default

v15: Dynamic by Default

Part 2: Understanding the Four Caching Layers

Layer 1: Request Memoization

Layer 2: Data Cache (The Major Change)

Layer 3: Full Route Cache

Layer 4: Router Cache (Client-Side)

Part 3: Cache Components with use cache

Enabling Cache Components

Basic Usage

Using cacheLife Profiles

Cache Invalidation

Migration Guide

From v14 to v15

Migrating to Cache Components

Real-World Patterns

Pattern 1: Hybrid E-commerce Page

Pattern 2: Static Marketing with Dynamic Pricing

Decision Matrix

Performance Considerations

Key Takeaways

Mastering Code Splitting in Next.js App Router

The Reality Check: Why Your Users Are Bouncing

App Router: The Game Changer (But Not Magic)

Real-World Scenario: Building a SaaS Dashboard

The Smart Way: Strategic Component Splitting

Pro Tip: Smart External Library Loading

The Server Component Twist

When NOT to Use Dynamic Imports

Advanced Pattern: Conditional Feature Loading

Measuring Success: The Numbers That Matter

The Developer Experience Bonus

Wrapping Up

Before You Code: A Senior Frontend Dev’s Thought Process

1. Understand the Feature

2. Map the Data Flow

3. Choose the Right State Strategy

4. Design for Reusability

5. Don’t Ignore Performance

6. Plan for Failure (Because It Will)

Final Thoughts

React, Vue, and Angular: Unpacking the Top JavaScript Frameworks

Part 3: Cache Components with `use cache`

1. `Partial<T>`

2. `Required<T>`

3. `Readonly<T>`

4. `Record<K, T>`

5. `Pick<T, K>`

6. `Omit<T, K>`

7. `Exclude<T, U>`

8. `Extract<T, U>`

9. `NonNullable<T>`

10. `ReturnType<T>`

11. `InstanceType<T>`

12. `ThisParameterType<T>`

13. `OmitThisParameter<T>`

14. `Parameters<T>`

15. `ConstructorParameters<T>`