Forem: TJ Coding

6 Common Anti-Patterns You should avoid

TJ Coding — Sun, 23 Nov 2025 08:57:16 +0000

We often talk about "Clean Code," but we rarely talk about the specific habits that make code "Dirty."

Dirty code isn't necessarily messy formatting—Prettier fixes that. True "dirty code" is an architectural liability. It works on your machine. It passes the unit tests. But it leaks memory, it lies to your monitoring tools, or it creates state-management nightmares that will haunt the next developer (who is likely you, three months from now).

Here are 6 common anti-patterns I see in code reviews, and exactly how to sanitize them.

1. The "Fire-and-Forget" Loop

Context: Node.js / Async Logic

The Smell 🤢

Using forEach with an async callback to process a list.

// ❌ The Dirty Way
async function emailActiveUsers(users: User[]) {
  users.forEach(async (user) => {
    await sendEmail(user.id);
  });

  console.log('All emails sent!'); // Lie. This prints immediately.
}

Why it stinks

Array.prototype.forEach is not promise-aware. It fires the callback for every item and immediately moves on.

Timing Ambiguity: The function finishes before the work does. The console.log runs while emails are still sending.
Uncontrolled Concurrency: If users has 10,000 items, you just opened 10,000 network requests simultaneously. You will crash your mail server or hit rate limits instantly.

The Sanitized Fix 🧼

Use for...of for sequential execution, or Promise.all (with a concurrency limiter like p-map if the list is huge) for parallel execution.

// ✅ The Sanitized Way (Sequential)
async function emailActiveUsers(users: User[]) {
  for (const user of users) {
    await sendEmail(user.id);
  }
  console.log('All emails actually sent.');
}

// ✅ The Sanitized Way (Parallel)
async function emailActiveUsers(users: User[]) {
  await Promise.all(users.map(user => sendEmail(user.id)));
  console.log('All emails actually sent.');
}

2. The "Software-Side" Filter

Context: Backend / Database

The Smell 🤢

Fetching all records from the database and filtering them in JavaScript.

// ❌ The Dirty Way
const products = await db.product.findMany(); // Fetches 50,000 rows
const available = products.filter(p => p.stock > 0 && p.isActive);

Why it stinks

This is the silent killer of API performance.

Memory Hog: You load 50,000 objects into Node.js RAM just to discard 40,000 of them.
Network Latency: You transferred megabytes of data over the wire unnecessarily.
No Indexing: JavaScript filtering is $O(n)$. Database filtering (with indexes) is $O(log n)$.

The Sanitized Fix 🧼

Push the logic down to the database. It is optimized for this; your Node process is not.

// ✅ The Sanitized Way
const available = await db.product.findMany({
  where: {
    stock: { gt: 0 },
    isActive: true
  }
});

3. The "State Mirror"

Context: React / Frontend

The Smell 🤢

Creating useEffect chains to sync two pieces of state.

// ❌ The Dirty Way
const [firstName, setFirstName] = useState('John');
const [lastName, setLastName] = useState('Doe');
const [fullName, setFullName] = useState('');

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

Why it stinks

Double Render: React renders once for the name change, then runs the effect, updates fullName, and renders again.

The Sanitized Fix 🧼

Derive state during render. If a value can be calculated from existing props or state, it should not be in useState.

// ✅ The Sanitized Way
const [firstName, setFirstName] = useState('John');
const [lastName, setLastName] = useState('Doe');

// Calculated on the fly. No extra render. No desync.
const fullName = `${firstName} ${lastName}`;

4. The "Lying" 200 OK

Context: REST API Design

The Smell 🤢

Sending an HTTP 200 status code, but including an error in the body.

// ❌ The Dirty Way
res.status(200).json({
  success: false,
  error: "Unauthorized access"
});

Why it stinks

Breaks Monitoring: Your Datadog/NewRelic dashboard sees 100% success rate (all green), while your users are actually facing errors.
Confuses Clients: Frontend libraries (Axios, TanStack Query) treat 200 as success. You force the frontend dev to write manual checks (if (!data.success) throw ...) instead of using the library's built-in error handling.

The Sanitized Fix 🧼

Use the HTTP protocol as intended.

// ✅ The Sanitized Way
res.status(401).json({
  message: "Unauthorized access"
});

5. The "Redundant Envelope"

Context: API Response Structure

The Smell 🤢

Wrapping every response in a generic object that restates what the HTTP protocol already told us.

// ❌ The Dirty Way
// GET /api/users/1
{
  "success": true, // We already know, it was a 200 OK
  "code": 200,     // We already know, it's in the header
  "data": {        // The nested nightmare
    "id": 1,
    "name": "Alice"
  }
}

Why it stinks

Ambiguity: Can I have success: true but code: 500? Can I have success: false but data is populated? This structure allows for impossible states.
The data.data Nightmare: Frontend developers have to write response.data.data to access the actual content.
Type Guard Pain: In TypeScript, your response type becomes a messy union where data might be generic or null depending on the boolean flag.

The Sanitized Fix 🧼

Return the resource, and only the resource.
If I ask for a User, give me a User. Use the Headers for meta-data (like pagination links or auth tokens) and Status Codes for success/failure.

// ✅ The Sanitized Way
// GET /api/users/1 -> Status 200 OK
{
  "id": 1,
  "name": "Alice"
}

// GET /api/users/1 -> Status 404 Not Found
{
  "message": "User not found"
}

6. The "Trust Me" Type Cast

Context: TypeScript

The Smell 🤢

Using as to silence the compiler when handling external data (API inputs, fetch results).

// ❌ The Dirty Way
interface User { id: number; name: string; }

// We assume the API returns exactly this. 
// If it returns { "id": "oops" }, our app crashes later.
const user = await fetch('/api/user').then(r => r.json()) as User;

Why it stinks

as User shuts off TypeScript validation. It is you telling the compiler: "I guarantee this is a User, don't check it."
But you cannot guarantee external data. If the API changes, your app explodes at runtime with undefined is not a function, and TypeScript won't save you.

The Sanitized Fix 🧼

Validate data at the runtime boundary using a schema validator like Zod.

import { z } from "zod";

// ✅ The Sanitized Way
const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
});

const response = await fetch('/api/user').then(r => r.json());

// Throws a clear error instantly if data is wrong.
// 'user' is automatically inferred as typed { id: number, name: string }
const user = UserSchema.parse(response);

The Meta-Lesson: Ambiguity is the Enemy

If you look closely at all the smells above—from the "Envelope" pattern to the "State Mirror"—they all share one fatal flaw: Ambiguity.

Ambiguous State: "Is fullName the truth, or are firstName + lastName the truth?"
Ambiguous Status: "The header says 200 OK, but the body says success: false."
Ambiguous Timing: "The function returned, but the loop is still running."

Great code is Unambiguous. It has one source of truth, one way to signal errors, and one timeline of execution. Remove the ambiguity, and you remove the bugs.

The "Zombie Request" Problem: Why Your Backend Keeps Working After the User Quits

TJ Coding — Sun, 23 Nov 2025 08:08:30 +0000

There is a dangerous assumption that 90% of Node.js developers make.

They assume that if a user closes their tab, refreshes the page, or cancels an API request, the backend automatically stops processing that request.

It does not.

In Node.js, the HTTP layer is decoupled from your logic. If a user requests a heavy report and immediately closes the window, your server will dutifully spend the next 30 seconds crunching numbers, heating up the CPU, and running database queries, only to realize at the very last millisecond: "Oh, the socket is dead. I have nowhere to send this."

This is a Zombie Request. In high-throughput systems, these zombies can consume up to 40% of your resources.

Here is how to identify, track, and kill them using AbortController.

The Proof: A Simple Experiment

You don't have to take my word for it. Create a simple Express route that simulates work using a timeout.

app.get('/heavy-work', async (req, res) => {
  console.log('1. Starting Work...');

  // Simulate a 5-second database aggregation
  await new Promise(resolve => setTimeout(resolve, 5000));

  console.log('2. Work Finished!');
  console.log('3. Sending Response...');

  res.send('Done');
});

The Test:

Open /heavy-work in your browser.
Wait 1 second.
Close the tab.

The Result:
Your terminal will print Work Finished! and Sending Response... four seconds after you closed the tab. You just paid AWS for computation that provided zero value.

The Architecture of a Fix

To solve this, we need to propagate a cancellation signal from the Network Layer (Express) down to the Application Layer (Services) and finally to the Infrastructure Layer (Database/External APIs).

We will use the standard AbortController API to standardize this flow.

Step 1: The Abort Middleware

Don't handle this in every single controller. Create a middleware that attaches an AbortSignal to every request.

// middleware/attachSignal.ts
import { Request, Response, NextFunction } from 'express';

export const attachSignal = (req: Request, res: Response, next: NextFunction) => {
  const controller = new AbortController();

  // Attach the signal to the request object so controllers can use it
  req.signal = controller.signal;

  // Listen for the socket closing
  req.on('close', () => {
    if (!res.writableFinished) {
      console.log(`[${req.method} ${req.url}] Request aborted by client.`);
      controller.abort();
    }
  });

  next();
};

// Add type definition
declare module 'express-serve-static-core' {
  interface Request {
    signal: AbortSignal;
  }
}

Step 2: The Controller

Now, your controllers don't need to know how the cancellation happened. They just pass the signal along.

app.get('/report', attachSignal, async (req, res) => {
  try {
    // Pass req.signal to your service layer
    const data = await ReportService.generate(req.query.id, { 
      signal: req.signal 
    });
    res.json(data);
  } catch (err) {
    if (req.signal.aborted) return; // Clean exit
    res.status(500).send('Error');
  }
});

Step 3: The "Kill Switch" (Service Layer)

This is where the magic happens. You must modify your expensive operations to respect the signal.

Scenario A: External API Calls (Axios/Fetch)
If your backend calls OpenAI or another microservice, pass the signal.

async function callExternalAPI(signal: AbortSignal) {
  // If the user cancels, this fetch aborts instantly
  // preventing your server from waiting on a 3rd party
  const response = await fetch('https://api.openai.com/...', { signal });
  return response.json();
}

Scenario B: Database Queries (Postgres)
Stopping a JavaScript loop is easy. Stopping a running SQL query is hard.
If you use pg directly, you can implement a "Cancellation Token" pattern.

import { Pool } from 'pg';

async function heavyQuery(signal: AbortSignal) {
  const client = await pool.connect();

  try {
    // 1. Get the PID of this connection
    const { rows } = await client.query('SELECT pg_backend_pid()');
    const pid = rows[0].pg_backend_pid;

    // 2. Setup the kill switch
    const abortHandler = () => {
      // Open a NEW connection to kill the OLD one
      pool.query('SELECT pg_cancel_backend($1)', [pid]).catch(console.error);
    };
    signal.addEventListener('abort', abortHandler);

    // 3. Run the heavy query
    const result = await client.query('SELECT ... FROM huge_table');

    // 4. Cleanup listener if query finishes successfully
    signal.removeEventListener('abort', abortHandler);
    return result;
  } finally {
    client.release();
  }
}

The "Critical Side Effect" Warning

Zombie requests aren't just about performance; they are about correctness.

Imagine an endpoint that:

Generates an invoice (3 seconds).
Charges the Credit Card.
Emails the user.

If the user clicks "Buy," notices a typo, and hits "Stop" (or closes the tab) after 1 second, they expect the transaction to be cancelled.

Without AbortController handling, your server will still charge their card 2 seconds later.

By checking if (signal.aborted) before critical stages, you prevent inconsistent states:

async function processOrder(signal: AbortSignal) {
  await generateInvoice();

  if (signal.aborted) throw new Error('Aborted'); // STOP HERE

  await stripe.charges.create(...); // Never reached if user left
}

Summary

Node.js is asynchronous, but it is not telepathic. It does not know the user has left unless you check.

Implementing "Full-Stack Cancellation" requires three changes:

Detect the close event (req.on('close')).
Propagate the signal (AbortSignal).
Terminate the resource (Fetch/SQL).

It is a small architectural change that saves cloud costs and prevents "ghost" data modifications.

A Guide to Production-Ready Security, Logging and Architecture in the express app

TJ Coding — Sat, 22 Nov 2025 18:15:03 +0000

It is easy to write an Express app. It is hard to write an Express app that survives production.

A "Hello World" tutorial won't tell you how to trace a specific bug through 10,000 requests per second, or how to prevent your server from leaking stack traces to hackers.

Here is a blueprint for hardening your Node.js/Express architecture using modern patterns like AsyncLocalStorage, structured logging, and strict validation.

1. Traceability: The `AsyncLocalStorage` Pattern

In a complex app, passing a requestId or logger instance down through every controller, service, and database repository is messy (backend "prop drilling").

Node.js offers a native solution: AsyncLocalStorage (ALS). It allows you to store data that is unique to the current asynchronous execution context (i.e., the current request) without passing arguments.

The Setup

First, create a storage file.

// src/lib/store.ts
import { AsyncLocalStorage } from 'node:async_hooks';

export interface RequestContext {
  requestId: string;
  userId?: string;
}

export const storage = new AsyncLocalStorage<RequestContext>();

export const getRequestId = () => {
  const store = storage.getStore();
  return store?.requestId || 'system';
};

The Middleware

Next, create a middleware that generates a unique ID (UUID) for every incoming request and wraps the rest of the request lifecycle in the store.

// src/middleware/context.ts
import { Request, Response, NextFunction } from 'express';
import { v4 as uuidv4 } from 'uuid';
import { storage } from '../lib/store';

export const contextMiddleware = (req: Request, res: Response, next: NextFunction) => {
  const requestId = (req.headers['x-request-id'] as string) || uuidv4();

  // Attach to response header so the client knows the ID too
  res.setHeader('x-request-id', requestId);

  // Run the rest of the app within the context
  storage.run({ requestId }, () => {
    next();
  });
};

Now, anywhere in your code (even deep inside a database helper), you can call getRequestId() to know exactly which request triggered the code.

2. Structured Logging with Context

console.log is insufficient for production. You need structured logging (JSON) so tools like Datadog, CloudWatch, or ELK can parse it.

Using libraries like Pino combined with our ALS setup allows us to automatically inject the requestId into every single log line without manually adding it.

// src/lib/logger.ts
import pino from 'pino';
import { getRequestId } from './store';

export const logger = pino({
  mixin() {
    // Automatically adds requestId to every log object
    return { requestId: getRequestId() };
  },
  transport: {
    target: process.env.NODE_ENV === 'development' ? 'pino-pretty' : undefined,
  },
});

Usage:

logger.info("User logged in"); 
// Output: { "level": 30, "time": 123456, "msg": "User logged in", "requestId": "abc-123" }

3. Security: The "Low Hanging Fruit" Headers

Do not deploy without Helmet. It sets various HTTP headers to secure your app against common attack vectors like XSS (Cross-Site Scripting) and Clickjacking.

import helmet from 'helmet';

// Enable standard security headers
app.use(helmet());

// Specifically configure Content Security Policy (CSP) if you serve UI
app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "trusted-cdn.com"],
    },
  })
);

Rate Limiting

Prevent brute-force attacks and DoS. While this is often better handled at the Load Balancer (AWS ALB) or Nginx level, having an application-level safety net is best practice.

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // Limit each IP to 100 requests per windowMs
  standardHeaders: true, 
  legacyHeaders: false,
});

app.use(limiter);

4. Input Validation: Trust Nothing

TypeScript types are erased at runtime. You cannot rely on TS interfaces to validate incoming JSON bodies. Use a runtime schema validator like Zod.

Create a generic middleware to enforce schema compliance:

// src/middleware/validate.ts
import { Request, Response, NextFunction } from 'express';
import { AnyZodObject, ZodError } from 'zod';

export const validate = (schema: AnyZodObject) => 
  (req: Request, res: Response, next: NextFunction) => {
    try {
      schema.parse({
        body: req.body,
        query: req.query,
        params: req.params,
      });
      next();
    } catch (error) {
      if (error instanceof ZodError) {
        return res.status(400).json({ errors: error.errors });
      }
      next(error);
    }
  };

5. Centralized Error Handling

Never send a raw 500 stack trace to the client. It exposes your internal file structure and potential vulnerabilities.

Create a custom AppError class to distinguish between Operational Errors (bad input, not found) and Programmer Errors (bugs).
Use a global error handling middleware at the end of your app.

// src/middleware/errorHandler.ts
export const errorHandler = (err: Error, req: Request, res: Response, next: NextFunction) => {
  const requestId = getRequestId();

  // Log the error with the trace ID for debugging
  logger.error({ err, requestId }, "Unhandled Error");

  // Send a sanitized response to the user
  res.status(500).json({
    status: 'error',
    message: 'Internal Server Error',
    requestId, // Handy for the user to give to customer support
  });
};

6. Graceful Shutdown

When you deploy a new version to AWS/Heroku/Kubernetes, the orchestrator sends a SIGTERM signal. If you don't handle this, Express kills active connections immediately, resulting in dropped requests for users.

const server = app.listen(3000);

const gracefulShutdown = () => {
  logger.info("SIGTERM received. Shutting down gracefully...");

  server.close(() => {
    logger.info("HTTP server closed.");

    // Close Database connections here
    // await db.disconnect();

    process.exit(0);
  });

  // Force close after 10s if connections hang
  setTimeout(() => process.exit(1), 10000);
};

process.on('SIGTERM', gracefulShutdown);
process.on('SIGINT', gracefulShutdown);

Summary Checklist

Traceability: Implemented AsyncLocalStorage with UUIDs.
Logging: Structured JSON logs (Pino) auto-tagged with Request IDs.
Security: Helmet headers and Rate Limiting active.
Validation: Zod schemas for all inputs.
Failures: Global error handler sanitizes output.
Lifecycle: Graceful shutdown handles deployments smoothly.

7 TypeScript Tricks That Feel Illegal to Use

TJ Coding — Sat, 22 Nov 2025 17:54:51 +0000

If you’re reading this, you likely know your way around interface, type, and generics. You probably have strict mode enabled. But TypeScript is capable of much more than just catching typos or ensuring a prop exists.

When used at a "pro" level, TypeScript stops being a linter and starts being a documentation engine and an architectural guardrail. Sometimes, you even have to abuse the type system to get the safety you really want.

Here are 7 patterns—ranging from modern best practices to "dark arts" hacks—to elevate your TypeScript mastery.

1. The `satisfies` Operator

Introduced in TypeScript 4.9, satisfies is a game-changer. It allows you to validate that an expression matches a type without changing the resulting type of that expression.

When you use a standard type annotation (e.g., const config: Config = ...), you lose specific inference. satisfies keeps the inference while enforcing the contract.

type Colors = "red" | "green" | "blue";
type RGB = [number, number, number];

const palette = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255]
} satisfies Record<Colors, string | RGB>;

// ✅ TS knows 'green' is a string, so this works:
palette.green.toUpperCase();

// ✅ TS knows 'red' is a tuple, so this works:
palette.red.map(n => n * 2);

// ❌ If we had used 'const palette: Record<...>', both lines above would error
// because TS would treat every property as 'string | RGB' loosely.

2. Zero-Cost Exhaustiveness Checking

When using switch statements on a union type, how do you ensure you haven't missed a case? You leverage the never type.

In the past, we used to assign the variable to a dummy never variable. But a cleaner, more modern approach is using satisfies never in the default block. It performs the check without creating unused variables that Linters hate.

type Status = "loading" | "success" | "error";

function getStatusMessage(status: Status) {
  switch (status) {
    case "loading": return "Please wait...";
    case "success": return "Done!";
    case "error": return "Something went wrong.";
    default:
      // If you add "idle" to Status, this line will turn red.
      status satisfies never; 
  }
}

3. Namespace-Style Template Literals

You can generate complex string types based on other types. This is incredibly powerful for Redux action types, event handlers, or strict string formatting that mimics file paths or namespaces.

type Domain = "User" | "Post" | "Comment";
type Action = "create" | "delete" | "update";

// Automatically generates: "User/create" | "User/delete" | "Post/create" ...
type AppEvent = `${Domain}/${Action}`;

function dispatch(event: AppEvent) {
  console.log(event);
}

dispatch("User/create"); // ✅
dispatch("Post/create"); // ✅
dispatch("User_create"); // ❌ Error (Wrong delimiter)
dispatch("Auth/login");  // ❌ Error (Invalid Domain)

4. The `Prettify` Helper (The "Tooltip Hack")

When you intersect multiple types (e.g., User & { role: string }), TypeScript's hover tooltip often shows the ugly, raw intersection Type A & Type B instead of the resulting object shape.

You can force TypeScript to "resolve" the UI for your tooltip using this simple helper. It doesn't change the runtime behavior, but it drastically improves DX.

// The Helper
type Prettify<T> = {
  [K in keyof T]: T[K];
} & {};

type User = { id: string; name: string };
type Admin = User & { permissions: string[] };

// Hovering over 'PrettyAdmin' shows the full object structure:
// { id: string; name: string; permissions: string[] }
type PrettyAdmin = Prettify<Admin>;

5. Branded Primitives (Nominal Typing)

TypeScript is structurally typed (if it looks like a duck, it's a duck). But sometimes, a UserId string should not be assignable to a PostId string, even if both are just strings.

We can "brand" primitive types to simulate Nominal Typing. This prevents accidental ID swapping.

declare const __brand: unique symbol;
type Brand<T, B> = T & { [__brand]: B };

type UserId = Brand<string, "UserId">;
type PostId = Brand<string, "PostId">;

const myUser = "user_123" as UserId;
const myPost = "post_456" as PostId;

function findUser(id: UserId) { /* ... */ }

findUser(myUser); // ✅ OK
findUser(myPost); // ❌ Error: Type 'PostId' is not assignable to 'UserId'

6. Key Remapping via `as`

You can rename keys while mapping over a type. This is excellent for creating derived types that follow specific naming conventions, like automatically generating setter methods for a state object.

type Person = {
  name: string;
  age: number;
  location: string;
};

// Create a type for specific 'set' functions
type Setters<T> = {
    [K in keyof T as `set${Capitalize<string & K>}`]: (value: T[K]) => void;
};

// Resulting Type:
// {
//   setName: (value: string) => void;
//   setAge: (value: number) => void;
//   setLocation: (value: string) => void;
// }

7. Block Inference with `NoInfer` (TS 5.4+)

Sometimes TypeScript is too smart and widens types when you don't want it to.

If you have a function where one argument should define the generic T, and the second argument must strictly match it, TypeScript will often try to find a common union type between them. NoInfer tells TypeScript: "Do not use this specific argument to infer T."

function createConfig<T extends string>(
  validOptions: T[], 
  defaultOption: NoInfer<T> // <--- Magic happens here
) {
  return { validOptions, defaultOption };
}

// ✅ Valid
createConfig(['dark', 'light'], 'dark');

// ❌ Error
// Without NoInfer, TS would infer T as "dark" | "light" | "blue" and allow this.
// With NoInfer, T is locked to the array, so "blue" is rightly caught as an error.
createConfig(['dark', 'light'], 'blue');

Final Thoughts

The goal of advanced TypeScript isn't to write the most complex generics possible—it's to write code that explains itself. By using tools like satisfies, Prettify, and NoInfer, you shift the burden of context and memory from your brain to the compiler.

Which of these patterns do you use most often? Let me know in the comments!

Full-Stack Security Architecture

TJ Coding — Mon, 17 Nov 2025 16:41:51 +0000

Security is not a plugin you add at the end; it is an architectural requirement. In a modern Next.js application, security responsibilities are split between the Edge (Middleware), the Configuration (next.config.js), and the Server Runtime (Server Actions).

This guide details a cohesive security strategy using Next.js, Zod (validation), and Bcrypt (cryptography).

I. The Security Checklist

Before implementing code, ensure your infrastructure meets these baselines:

[ ] SSL/TLS: Enforce HTTPS strictly (HSTS).
[ ] Content Security Policy (CSP): Restrict data sources to trusted domains.
[ ] Database Security: Never concatenate SQL; use ORMs (Prisma/Drizzle) or parameterized queries.
[ ] Input Sanitization: Validate data types and length on the server.
[ ] Secure Dependencies: regularly run npm audit.

II. The First Line of Defense: Headers & Config

In Next.js, security headers are injected at the build time configuration. This ensures that every response—static or dynamic—carries the necessary protection instructions for the browser.

File: next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  async headers() {
    return [
      {
        // Apply these headers to all routes in your application
        source: '/:path*',
        headers: [
          {
            key: 'X-DNS-Prefetch-Control',
            value: 'on',
          },
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=63072000; includeSubDomains; preload',
          },
          {
            key: 'X-Frame-Options',
            value: 'SAMEORIGIN', // Prevents clickjacking
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff', // Prevents MIME-sniffing
          },
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
        ],
      },
    ];
  },
};

module.exports = nextConfig;

III. Authentication & Cryptography

Handling passwords requires strict adherence to one rule: never store them in plain text. In the Node.js/Next.js runtime, we use bcrypt (or bcryptjs) to handle one-way hashing.

Installation: npm install bcryptjs

1. The Hashing Utility

Create a dedicated utility file for crypto operations. This ensures you can rotate algorithms easily in the future.

File: lib/auth-utils.ts

import bcrypt from 'bcryptjs';

const SALT_ROUNDS = 12; 

/**
 * Hashes a plain text password.
 * Usage: Before saving a new user to the DB.
 */
export async function hashPassword(password: string): Promise<string> {
  return await bcrypt.hash(password, SALT_ROUNDS);
}

/**
 * Verifies a plain text password against a stored hash.
 * Usage: During the login process.
 */
export async function verifyPassword(
  plainText: string, 
  hashed: string
): Promise<boolean> {
  return await bcrypt.compare(plainText, hashed);
}

IV. Secure Input Handling (Server Actions)

In the Next.js App Router, Server Actions are publicly accessible HTTP endpoints. You must validate data structure and types before processing logic. In We use Zod for schema validation.

Installation: npm install zod

File: app/actions/auth-actions.ts

'use server'

import { z } from 'zod';
import { hashPassword } from '@/lib/auth-utils';
import { db } from '@/lib/db'; // Hypothetical DB connection
import { redirect } from 'next/navigation';

// 1. Define the Strict Schema
const SignUpSchema = z.object({
  email: z.string().email({ message: "Invalid email format" }),
  password: z.string()
    .min(8, { message: "Password must be at least 8 characters" })
    .regex(/[A-Z]/, { message: "Must contain one uppercase letter" })
    .regex(/[0-9]/, { message: "Must contain one number" }),
  role: z.enum(['user', 'admin']).default('user'), // Enforce allowed values
});

export async function registerUser(prevState: any, formData: FormData) {

  // 2. Parse and Validate Input
  const result = SignUpSchema.safeParse({
    email: formData.get('email'),
    password: formData.get('password'),
    role: 'user', // Force role to user prevents Mass Assignment vulnerabilities
  });

  if (!result.success) {
    return { error: result.error.flatten().fieldErrors };
  }

  const { email, password } = result.data;

  // 3. Securely Hash Password
  const hashedPassword = await hashPassword(password);

  // 4. Database Interaction (Example with Prisma/Drizzle)
  try {
    await db.user.create({
      data: {
        email,
        password: hashedPassword,
      },
    });
  } catch (e) {
    return { error: "User already exists" };
  }

  redirect('/login');
}

V. Session Management & Cookies

When managing sessions manually or via libraries, configuring the cookie attributes is vital to prevent Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

File: lib/session.ts

import { cookies } from 'next/headers';

export async function createSession(userId: string) {
  // Set the expiration time (e.g., 7 days)
  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000);
  const sessionToken = "generated_jwt_or_session_id"; // Replace with actual token logic

  const cookieStore = await cookies();

  cookieStore.set('session', sessionToken, {
    httpOnly: true,    // CRITICAL: Prevents JavaScript access (stops XSS theft)
    secure: process.env.NODE_ENV === 'production', // Only send over HTTPS
    sameSite: 'lax',   // Protects against CSRF while allowing normal navigation
    expires: expiresAt,
    path: '/',
  });
}

VI. Output Sanitization (XSS Prevention)

Next.js automatically sanitizes data passed to JSX components. However, if you must render HTML stored in a database (e.g., a blog post body), you bypass this protection.

You must use a sanitizer library like isomorphic-dompurify before rendering raw HTML.

Installation: npm install isomorphic-dompurify

File: components/SafeHTML.tsx

import DOMPurify from 'isomorphic-dompurify';

interface Props {
  htmlContent: string;
}

export default function SafeHTML({ htmlContent }: Props) {
  // Cleanses the HTML of scripts, iframes, and event handlers (e.g., onclick)
  const sanitizedHTML = DOMPurify.sanitize(htmlContent);

  // Now safe to render
  return (
    <div 
      className="prose" 
      dangerouslySetInnerHTML={{ __html: sanitizedHTML }} 
    />
  );
}

How to Decide When to Use "use client"

TJ Coding — Fri, 14 Nov 2025 19:59:09 +0000

By default, every component in the App Router is a Server Component (RSC). This is the new "RSC-first" approach. You should only opt into "use client" when you absolutely have to.

Think of "use client" as a boundary. It tells React, "Everything in this file and everything it imports will be a Client Component, with its JavaScript sent to the browser."

Here is the simple litmus test. Ask yourself if your component needs:

Interactivity: Does it use event handlers like onClick, onChange, or onSubmit?
State: Does it need React hooks like useState, useReducer, or useTransition?
Effects: Does it need lifecycle hooks like useEffect or useLayoutEffect?
Browser-Only APIs: Does it need to access window, localStorage, or other browser APIs?
Context: Does it need to use (consume) Context with useContext? (Note: Providing context also requires "use client").

If you answer "yes" to any of these, it must be a Client Component.

The Golden Rule: Push "use client" to the Leaves

The most important best practice is to push your Client Components as far down the component tree as possible.

Don't put "use client" at the top of your main page. Instead, keep your page as a Server Component and import smaller, interactive "island" components into it.

❌ Bad Example (Making the whole page a Client Component)

// app/page.tsx
"use client"; // <-- Unnecessary! Now the whole page is client-side.

import { useState } from "react";
import { MyData } from "./get-data";

export default function Page() {
  const [count, setCount] = useState(0);

  // This data fetching is now running on the client!
  const data = MyData.get(); 

  return (
    <div>
      <h1>My Page</h1>
      <p>Data: {data.info}</p>
      {/* This is the only part that actually needed state */}
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>
    </div>
  );
}

✅ Good Example (Isolating the Client Component)

Step 1: Your page remains a Server Component (the default). It can do fast, server-side data fetching.

// app/page.tsx
// NO "use client" directive

import { MyData } from "./get-data";
import { Clicker } from "./ui/clicker"; // Import the client part

// This function runs ON THE SERVER
async function getData() {
  const data = await MyData.get();
  return data;
}

export default async function Page() {
  // Data is fetched on the server before the page is sent
  const data = await getData();

  return (
    <div>
      <h1>My Page (from the server)</h1>
      <p>Data: {data.info} (from the server)</p>

      {/* We import just the one interactive piece */}
      <Clicker />
    </div>
  );
}

Step 2: You create a tiny "island" component that handles only the interactivity.

// app/ui/clicker.tsx
"use client"; // <-- The boundary is as small as possible

import { useState } from "react";

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count} (from the client)
    </button>
  );
}

💡 How to Manage State with Minimal Boilerplate (RSC-First)

Your instinct is correct: the old way of wrapping your entire app in global state providers (<ReduxProvider>, <AppContext.Provider>) is now an anti-pattern. Doing so would force your entire application to be a Client Component.

Here is the new "RSC-first" state management hierarchy, from most-preferred to least-preferred.

1. For Global State (Filters, Modals, Tabs): Use the URL

This is the number one, minimal-boilerplate way to manage global state. The URL is the state manager.

How: Use React's built-in useSearchParams() hook (in a Client Component) to update the URL. Your Server Components (like page.tsx) can read these searchParams from their props and re-fetch or re-render with the new state.
Best for: Search queries, filters, pagination, "is this modal open" (?modal=login), active tabs.
Why it's great: It's shareable, refresh-proof, and requires zero external libraries.

2. For UI State (Toggles, Dropdowns): Keep it Local

How: Just like the <Clicker /> example above. Create a tiny Client Component with its own useState.
Best for: "Is this dropdown open?", "What's the value of this input field?"
Why it's great: It's simple, encapsulated, and has zero impact on the rest of your app.

3. For Data Mutations (Changing Data): Use Server Actions

This is the new way to handle form submissions or any action that changes data, and it dramatically reduces boilerplate.

How: You define an async function with "use server". A Client Component can then import and call this function directly from an onClick or onSubmit.
Minimal Boilerplate: You use the useTransition hook to get a isPending state. No more useState for loading, error, and data. React handles the pending state for you.
Best for: Form submissions, "Add to Cart" buttons, "Delete Post" buttons.

4. For Passing Data Down: Fetch in RSC, Pass as Props

How: Your top-level Server Component (like page.tsx) does the await fetch(...). It then passes the resulting data as props down to any Client Components that need to display it.
Why it's great: This completely eliminates all client-side data-fetching state (isLoading, error, data). The data is just there when the component renders.

5. For True Global Client State (e.g., Theme, Cart): Use Zustand/Jotai

Sometimes you just need a global, client-side-only state that isn't in the URL (like a theme toggle or a shopping cart).

How: Use a minimal library like Zustand. It doesn't require a <Provider> at the root of your app. You can just create a store and call the useStore() hook in any Client Component that needs it.
Why it's great: It's minimal, avoids the "wrap the whole app" anti-pattern, and works perfectly alongside Server Components.

Summary: State Management Cheat Sheet

State Type	✅ Recommended Solution (Minimal Boilerplate)
Global State (Filters, search, tabs)	Use the URL (`useSearchParams` or nuqs)
Local UI State (Toggles, inputs)	Local `useState` (in a small Client Component)
Data Mutations (Form submits)	Server Actions (with `useTransition`)
Server Data (Displaying data)	Fetch in RSC (and pass down as props)
Global UI State (Theme, cart)	Zustand (or Jotai)

Would you like a specific code example for one of these patterns, like using Server Actions or managing URL state?

The Composable Factory Pattern: Your Next.js Boilerplate Killer

TJ Coding — Fri, 14 Nov 2025 18:14:37 +0000

We all love the power of Next.js, especially the new App Router. But if you've been building with it, you've probably felt that friction—that sense of "Wait, am I really writing this again?"

I'm talking about the endless try...catch blocks. The repetitive Zod validation in every Server Action. The manual error formatting for NextResponse. This boilerplate code clutters our business logic, makes refactoring a nightmare, and is a prime source of bugs.

What if we could write that code once and then forget about it?

Today, we're going to build a composable factory toolkit. This is a set of "life-saving hacks" that will abstract all that boilerplate away, leaving you with clean, readable, and robust Server Actions and API Routes.

We will build three main pieces:

handlePromise: A Go-lang-inspired utility to force error handling.
ServerAction Factory: A class that builds fully-validated, error-handled Server Actions.
createApiHandler Factory: A function that does the same for your App Router API Routes.

Let's get started.

1. The Foundation: `handlePromise`

First, let's kill the try...catch block. The problem with try...catch is that it's opt-in. You can forget to write it. We're going to replace it with a pattern that's opt-out.

This simple helper wraps any promise and returns a tuple: [error, data]. If the promise rejects, you get an Error in the first slot. If it resolves, you get your data in the second.

🧰 The Code (`lib/utils.ts`)

/**
 * Wraps a Promise to return a Go-lang style [error, data] tuple.
 * This forces error handling at the call site.
 *
 * @param promise - The Promise to execute.
 * @returns A tuple: [Error, undefined] if the promise rejects, or [undefined, T] if it resolves.
 */
export async function handlePromise<T>(
  promise: Promise<T>
): Promise<[Error, undefined] | [undefined, T]> {
  try {
    const data = await promise;
    return [undefined, data];
  } catch (error) {
    if (error instanceof Error) {
      return [error, undefined];
    }
    // Handle non-Error throws, just in case
    return [new Error(String(error)), undefined];
  }
}

💡 How It's Used

This utility will be the core of our other factories.

Before:

try {
  const user = await db.user.findFirst(...);
  if (!user) { /* handle no user */ }
  return user;
} catch (e) {
  console.error(e);
  return { error: "Failed to get user" };
}

After:

const [error, user] = await handlePromise(db.user.findFirst(...));

if (error) {
  console.error(error.message);
  return { error: "Failed to get user" };
}

if (!user) { /* handle no user */ }
return user;

This is already cleaner, and your linter will yell at you if you have an unused error variable. It forces you to acknowledge failure, which is the first step to robust code.

2. The Workhorse: The `ServerAction` Factory

Server Actions are fantastic, but a "production-ready" action needs:

Input Validation: (e.g., Zod)
Logic: The actual work.
Error Handling: Catching errors from your logic.
Output Validation: (Optional) Ensuring you return the right shape.
Response Formatting: Returning a consistent { data, error } object for client-side hooks like useActionState.

We're going to build a ServerAction class that handles 1, 3, 4, and 5, so you only have to write #2.

🧰 The Code (`lib/server-action.ts`)

We'll use Zod for validation. Make sure you've installed it (npm install zod).

'use server';

import { z, ZodError } from 'zod';
import { handlePromise } from './utils';

// --- 1. Define our types ---

// The props our factory will accept
type ServerActionProps<TInput, TOutput> = {
  inputSchema?: z.Schema<TInput>;
  outputSchema?: z.Schema<TOutput>;
  inputType?: 'form' | 'json';
  onError?: (error: Error, input: any) => void;
  metadata?: Record<string, any>;
};

// A standard response format for client hooks
export type ActionResponse<TOutput> = {
  data?: TOutput;
  error?: string;
  validationErrors?: ZodError['issues'];
};

// --- 2. The ServerAction Class ---

export class ServerAction<TInput, TOutput> {
  protected props: ServerActionProps<TInput, TOutput>;

  constructor(props: ServerActionProps<TInput, TOutput>) {
    this.props = {
      inputType: 'form', // Default to FormData
      ...props,
    };
  }

  /**
   * Creates a new ServerAction instance by extending the current configuration.
   * New props will override existing ones.
   */
  public extend<TNewInput = TInput, TNewOutput = TOutput>(
    newProps: Partial<ServerActionProps<TNewInput, TNewOutput>>
  ): ServerAction<TNewInput, TNewOutput> {

    const mergedProps: ServerActionProps<TNewInput, TNewOutput> = {
      ...this.props,
      ...newProps,
      metadata: {
        ...this.props.metadata,
        ...newProps.metadata,
      },
    };
    return new ServerAction<TNewInput, TNewOutput>(mergedProps);
  }

  /**
   * The factory method. It takes your business logic
   * and returns a complete, safe Server Action.
   */
  public action(
    callback: (input: TInput) => Promise<TOutput>
  ): (input: any) => Promise<ActionResponse<TOutput>> {

    return async (input: any): Promise<ActionResponse<TOutput>> => {
      let validatedInput: TInput;

      try {
        // --- 1. Validate Input ---
        if (this.props.inputSchema) {
          const parseTarget = this.props.inputType === 'form' 
            ? Object.fromEntries(input as FormData) 
            : input;
          validatedInput = this.props.inputSchema.parse(parseTarget);
        } else {
          validatedInput = input as TInput;
        }
      } catch (error) {
        if (error instanceof ZodError) {
          return { error: 'Validation failed.', validationErrors: error.issues };
        }
        return { error: 'Invalid input.' };
      }

      // --- 2. Run Business Logic (using our handlePromise!) ---
      const [error, result] = await handlePromise(callback(validatedInput));

      // --- 3. Handle Errors ---
      if (error) {
        this.props.onError?.(error, input); // Run custom error hook
        return { error: error.message || 'An unknown error occurred.' };
      }

      // --- 4. Validate Output (Optional) ---
      if (this.props.outputSchema) {
        const [parseError, validatedResult] = await handlePromise(
          this.props.outputSchema.parseAsync(result)
        );

        if (parseError) {
          this.props.onError?.(parseError, input);
          return { error: 'Invalid server output.' };
        }
        return { data: validatedResult };
      }

      // --- 5. Return Success ---
      return { data: result };
    };
  }
}

// --- 3. A simple helper function ---
export function createServerAction<TInput, TOutput>(
  props: ServerActionProps<TInput, TOutput>
) {
  return new ServerAction<TInput, TOutput>(props);
}

💡 How It's Used: Composable Actions

This is where the extend method becomes magical. We can create a base action and specialize it.

// app/auth/actions.ts
'use server';

import { z } from 'zod';
import { createServerAction } from '@/lib/server-action';
import { lucia, db } from '@/lib/auth';

// 1. Create a BASE action for all auth-related tasks.
// It shares a common error handler and metadata.
const authAction = createServerAction({
  inputType: 'form',
  metadata: { tags: ['auth'] },
  onError: (error) => {
    // Shared logging for all auth actions
    console.error('AUTH_ERROR', error.message);
  },
});

// 2. Define schemas
const loginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(1),
});

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

// 3. Create a SPECIALIZED action for logging in
export const login = authAction
  .extend<z.infer<typeof loginSchema>, { userId: string }>({
    inputSchema: loginSchema,
    metadata: { tags: ['auth', 'login'] },
  })
  .action(async (input) => {
    // 'input' is 100% type-safe and validated.
    // No try/catch needed.
    // The 'onError' from authAction is already active.

    // Just write your logic:
    const userId = await lucia.login(input.email, input.password);
    return { userId };
  });

// 4. Create another SPECIALIZED action for registering
export const register = authAction
  .extend<z.infer<typeof registerSchema>, { userId: string }>({
    inputSchema: registerSchema,
  })
  .action(async (input) => {
    // 'input' is { username, email, password }
    const user = await db.user.create(...);
    return { userId: user.id };
  });

Look at that! Your action file contains only schemas and business logic. All the boilerplate is gone.

3. The API Sibling: `createApiHandler`

We can apply the exact same pattern to App Router API Routes (route.ts). The only difference is that we need to validate params, searchParams, and the body.

🧰 The Code (`lib/api-handler.ts`)

import { NextRequest, NextResponse } from 'next/server';
import { z, ZodError } from 'zod';
import { handlePromise } from './utils';

// --- 1. Define Types ---
type ApiHandlerProps<TParams, TSearch, TBody> = {
  schemas?: {
    params?: z.Schema<TParams>;
    searchParams?: z.Schema<TSearch>;
    body?: z.Schema<TBody>;
  };
  // The business logic, receives all validated data
  handler: (data: {
    params: TParams;
    searchParams: TSearch;
    body: TBody;
  }) => Promise<any>; // Handler returns raw data
};

type ApiErrorResponse = {
  error: { message: string; issues?: ZodError['issues'] };
};

// --- 2. The Factory Function ---
export function createApiHandler<TParams, TSearch, TBody>({
  schemas,
  handler,
}: ApiHandlerProps<TParams, TSearch, TBody>) {

  return async (
    req: NextRequest,
    context: { params: Record<string, string | string[]> }
  ): Promise<NextResponse<any | ApiErrorResponse>> => {

    let params: TParams, searchParams: TSearch, body: TBody;

    try {
      // --- 1. Validate all inputs ---
      params = schemas?.params
        ? schemas.params.parse(context.params)
        : (context.params as TParams);

      const search = Object.fromEntries(req.nextUrl.searchParams);
      searchParams = schemas?.searchParams
        ? schemas.searchParams.parse(search)
        : (search as TSearch);

      if (req.method !== 'GET' && req.method !== 'DELETE') {
        const json = await req.json();
        body = schemas?.body ? schemas.body.parse(json) : (json as TBody);
      } else {
        body = null as TBody;
      }

    } catch (error) {
      if (error instanceof ZodError) {
        return NextResponse.json<ApiErrorResponse>({
          error: { message: 'Validation failed', issues: error.issues },
        }, { status: 400 });
      }
      return NextResponse.json<ApiErrorResponse>({
        error: { message: 'Invalid request' },
      }, { status: 400 });
    }

    // --- 2. Run Business Logic ---
    const [error, result] = await handlePromise(
      handler({ params, searchParams, body })
    );

    if (error) {
      return NextResponse.json<ApiErrorResponse>({
        error: { message: error.message || 'Server error' },
      }, { status: 500 });
    }

    // --- 3. Return Success ---
    return NextResponse.json(result);
  };
}

💡 How It's Used

Your API route files now become simple configuration objects.

// app/api/posts/[id]/route.ts
import { createApiHandler } from '@/lib/api-handler';
import { z } from 'zod';
import { db } from '@/lib/db';

// 1. Define schemas
const paramsSchema = z.object({ id: z.string().uuid("Invalid post ID") });
const bodySchema = z.object({
  content: z.string().min(10, "Content is too short"),
});

// 2. Create the handler
export const PATCH = createApiHandler({
  schemas: {
    params: paramsSchema,
    body: bodySchema,
  },
  handler: async ({ params, body }) => {
    // 'params' and 'body' are validated and typed!
    // No try/catch needed.

    const updatedPost = await db.post.update({
      where: { id: params.id },
      data: { content: body.content },
    });

    return updatedPost;
  },
});

Again, all boilerplate is gone. Your handler is just the logic.

Conclusion: Take Your Code Back

This pattern is more than just a "hack"—it's a way to enforce consistency and robustness across your entire application. By building a small toolkit of factories, you've:

Made your code DRY: Error handling and validation logic live in one place.
Made it Robust: Validation isn't optional; it's part of the flow.
Made it Readable: Your action and handler files are now pure, clean business logic.

Now, go look at your project. Find those duplicated try...catch blocks and validation snippets. You know what to do.

The Core of Reactivity: 4 Native JavaScript State Management Patterns

TJ Coding — Fri, 14 Nov 2025 15:13:09 +0000

The Core of Reactivity: 4 Native JavaScript State Management Patterns

In modern web development, the core challenge is keeping the UI in sync with the application's data. We call this "state management." When your data (the "state") changes, you want the DOM (the "view") to update automatically.

While many frameworks exist to solve this, the underlying patterns are built on powerful, native JavaScript features. Understanding these patterns not only makes you a better engineer but allows you to build highly efficient, lightweight, and dependency-free solutions for any project.

Let's explore four foundational patterns for native state management.

1. The Classic: Getters & Setters (`Object.defineProperty`)

This is the original, time-tested method for intercepting property access. You create an object where you define custom "getter" and "setter" functions for a specific property. The set function is where you trigger your reaction.

How it works: You use Object.defineProperty() to define a property on an object. When you try to assign a new value to that property, it triggers your custom setter function, which can then run any code you want—like updating the DOM.

Code Example:

// Our state object
const state = {
  _price: 10, // A "private" internal value
};

// The function that updates our UI
function updatePriceDisplay(newValue) {
  // A generic updater, e.g., finds an element and sets textContent
  console.log(`Updating DOM with new price: ${newValue}`);
  document.getElementById('price-display').textContent = newValue;
}

// 1. Define the 'price' property on our state object
Object.defineProperty(state, 'price', {
  enumerable: true, // Lets it be seen in for...in loops

  // 2. The GETTER: simply returns the internal value
  get() {
    return state._price;
  },

  // 3. The SETTER: triggers our UI update "reaction"
  set(newValue) {
    if (newValue !== state._price) {
      state._price = newValue;
      // This is the "reaction"
      updatePriceDisplay(newValue);
    }
  }
});

// Now, when you run this...
state.price = 20; // ...the setter automatically fires!

Pros & Cons:

Pro: Extremely robust browser support (IE9+).
Pro: Simple to understand for single-property observation.
Con: Verbose. You must define this for every single property you want to watch.
Con: It doesn't scale well. It doesn't work for new properties added to the object later or for properties that are deleted.

2. The Modern Powerhouse: `Proxy`

This is the modern, far more powerful approach. A Proxy is an object that wraps another object and allows you to intercept fundamental operations (like getting, setting, or deleting properties) using a handler.

How it works: You create one Proxy around your entire state object. The handler (its configuration) has a set trap that intercepts all property assignments, no matter the property name. This is the engine behind modern frameworks like Vue 3.

Code Example:

// A generic UI update function
function updateDisplay(property, newValue) {
  const el = document.getElementById(`${property}-display`);
  if (el) {
    el.textContent = newValue;
  }
}

// 1. The original, plain JavaScript object
const state = {
  price: 10,
  itemName: 'Basic T-Shirt'
};

// 2. The handler with the 'set' trap
const stateHandler = {
  set(target, property, value) {
    // target = the original 'state' object
    // property = the key being set (e.g., 'price')
    // value = the new value (e.g., 25)

    // Update the original object
    target[property] = value;

    // This is the "reaction" - it's generic for ANY property!
    updateDisplay(property, value);

    // A setter trap must return true
    return true;
  }
};

// 3. Create the reactive proxy
const stateProxy = new Proxy(state, stateHandler);

// You now ONLY interact with the proxy:
stateProxy.price = 25;        // Triggers the trap!
stateProxy.itemName = 'Cool Hat'; // This also triggers the same trap!

Pros & Cons:

Pro: Extremely powerful and clean. It automatically handles all properties, including new ones you add later (stateProxy.newProp = 'hi') or array methods.
Pro: Your original state object remains a clean, plain object.
Pro: You can intercept many other operations (e.g., get, deleteProperty).
Con: Modern browser support (no IE). This is generally a non-issue in 2025.

3. The Scalable Architect: The Pub/Sub (Observer) Pattern

This is a foundational computer science pattern, also known as Publish/Subscribe or Observer. It's less about "magic" and more about creating an explicit, scalable system.

How it works:

You create a central "Store" object.
Other parts of your code ("subscribers" or "observers") register themselves with the store, providing a callback function.
When you want to change the state, you must call a specific method on the store (e.g., store.setState()).
The store updates its internal state and then "publishes" the change by looping through all its subscribers and executing their callback functions with the new state.

Code Example:

// 1. Create the store
const stateStore = {
  state: {
    price: 10
  },
  subscribers: [], // A list of callback functions

  // 2. A method for other parts of the app to "subscribe"
  subscribe(callback) {
    this.subscribers.push(callback);
  },

  // 4. The internal "publish" method
  publish() {
    // Tell all subscribers about the change
    this.subscribers.forEach(callback => callback(this.state));
  },

  // 3. A dedicated method to update the state
  setState(newState) {
    this.state = { ...this.state, ...newState };
    // 4. Publish the change!
    this.publish();
  }
};

// --- In another part of your app (e.g., your UI) ---

// Have your UI "subscribe" to changes
stateStore.subscribe((newState) => {
  document.getElementById('price-display').textContent = newState.price;
});

// Now, to make a change, you MUST use the method:
stateStore.setState({ price: 30 }); // This will trigger the subscriber!

Pros & Cons:

Pro: Extremely scalable and organized. It forces a clear data flow, which is excellent for large applications. This is the foundation of libraries like Redux.
Pro: Fully decoupled. The state store doesn't know or care what the subscribers are (they could be UI, loggers, or API calls).
Con: More boilerplate. You have to write all the store logic yourself.
Con: It's not "magic." You can't just set a property (store.state.price = 40); you must use the setState method to trigger the update.

4. The 'Powered-Up' State Factory (Signal + Proxy)

This is the most robust pattern. It uses a clean "Signal" factory (similar to Pub/Sub) but enhances it with a Proxy to solve the nested object problem.

How it works:

The createState function holds a private value and a Set of subscribers.
The Enhancement: If the initialValue is an object, it is immediately wrapped in a Proxy.
This Proxy's set handler is configured to call the notify function after any property is changed.
This means you get the clean API of value and value for simple values, but you also get automatic reactivity when you mutate an object's properties directly.

The Complete Code:

function createState(initialValue) {
  const subscribers = new Set();

  function notify(newValue, oldValue) {
    for (const callback of subscribers) {
      callback(newValue, oldValue);
    }
  }

  // --- PROXY ENHANCEMENT ---
  // This handler will be used if the value is an object.
  // It calls 'notify' on any property change.
  const proxyHandler = {
    set(target, property, newValue) {
      const oldValue = { ...target }; // Shallow copy for comparison
      const result = Reflect.set(target, property, newValue);
      // Notify with the entire object
      notify(target, oldValue);
      return result;
    }
  };

  // Store the internal value. If it's an object, make it a proxy.
  let value = (typeof initialValue === 'object' && initialValue !== null)
    ? new Proxy(initialValue, proxyHandler)
    : initialValue;

  return {
    get value() {
      return value;
    },

    set value(newValue) {
      const oldValue = value;

      // If the new value is an object, it also needs to be proxied
      // so it can be mutated directly later.
      if (typeof newValue === 'object' && newValue !== null) {
        value = new Proxy(newValue, proxyHandler);
      } else {
        value = newValue;
      }

      if (oldValue !== value) {
        notify(value, oldValue);
      }
    },

    subscribe(callback) {
      subscribers.add(callback);
      // Return an 'unsubscribe' function for easy cleanup
      return () => subscribers.delete(callback);
    }
  };
}

// --- USAGE EXAMPLE ---

// 1. Example with a primitive (same as before)
const count = createState(0);
count.subscribe((newVal) => console.log(`Count: ${newVal}`));
count = 5; // Logs: "Count: 5"

// 2. Example with an object (now works as intended)
const user = createState({ firstName: "John", age: 18 });

user.subscribe((newUser) => {
  console.log('User changed:', newUser);
});

// This mutation now triggers the proxy's 'set' trap:
user.value.age = 19; 
// Logs: "User changed: { firstName: 'John', age: 19 }"

// You can still set the whole object, too:
user.value = { firstName: "Jane", age: 20 };
// Logs: "User changed: { firstName: 'Jane', age: 20 }"

Pros & Cons:

Pro: The most powerful and clean solution.
Pro: Handles both simple values and deep object mutations automatically.
Pro: Extremely reusable, scalable, and testable.
Con: Relies on modern Proxy and Reflect APIs (no IE support).

Conclusion: Which One Should You Use?

Choosing the right native pattern depends on your project's scale:

Getters/Setters: Use this for simple, isolated cases where you need to observe one or two properties and require wide browser compatibility.
Proxy: This is the best modern choice for building self-contained reactive components (e.g., a "widget") with clean code.
Pub/Sub (Observer): Use this when you are building a larger application and need a single, explicit, reliable "source of truth" that many components must share.
State Factory (Signal + Proxy): This is the most robust modern approach. It's clean, reusable, and handles any state management need, making it a perfect foundation for a lightweight custom library.

Forem: TJ Coding

6 Common Anti-Patterns You should avoid

1. The "Fire-and-Forget" Loop

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

2. The "Software-Side" Filter

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

3. The "State Mirror"

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

4. The "Lying" 200 OK

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

5. The "Redundant Envelope"

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

6. The "Trust Me" Type Cast

The Smell 🤢

Why it stinks

The Sanitized Fix 🧼

The Meta-Lesson: Ambiguity is the Enemy

The "Zombie Request" Problem: Why Your Backend Keeps Working After the User Quits

The Proof: A Simple Experiment

The Architecture of a Fix

Step 1: The Abort Middleware

Step 2: The Controller

Step 3: The "Kill Switch" (Service Layer)

The "Critical Side Effect" Warning

Summary

A Guide to Production-Ready Security, Logging and Architecture in the express app

1. Traceability: The AsyncLocalStorage Pattern

The Setup

The Middleware

2. Structured Logging with Context

3. Security: The "Low Hanging Fruit" Headers

Rate Limiting

4. Input Validation: Trust Nothing

5. Centralized Error Handling

6. Graceful Shutdown

Summary Checklist

7 TypeScript Tricks That Feel Illegal to Use

1. The satisfies Operator

2. Zero-Cost Exhaustiveness Checking

3. Namespace-Style Template Literals

4. The Prettify Helper (The "Tooltip Hack")

5. Branded Primitives (Nominal Typing)

6. Key Remapping via as

7. Block Inference with NoInfer (TS 5.4+)

Final Thoughts

Full-Stack Security Architecture

I. The Security Checklist

II. The First Line of Defense: Headers & Config

III. Authentication & Cryptography

1. The Hashing Utility

IV. Secure Input Handling (Server Actions)

V. Session Management & Cookies

VI. Output Sanitization (XSS Prevention)

How to Decide When to Use "use client"

The Golden Rule: Push "use client" to the Leaves

❌ Bad Example (Making the whole page a Client Component)

✅ Good Example (Isolating the Client Component)

💡 How to Manage State with Minimal Boilerplate (RSC-First)

1. For Global State (Filters, Modals, Tabs): Use the URL

2. For UI State (Toggles, Dropdowns): Keep it Local

3. For Data Mutations (Changing Data): Use Server Actions

4. For Passing Data Down: Fetch in RSC, Pass as Props

5. For True Global Client State (e.g., Theme, Cart): Use Zustand/Jotai

Summary: State Management Cheat Sheet

The Composable Factory Pattern: Your Next.js Boilerplate Killer

1. The Foundation: handlePromise

🧰 The Code (lib/utils.ts)

💡 How It's Used

2. The Workhorse: The ServerAction Factory

🧰 The Code (lib/server-action.ts)

1. Traceability: The `AsyncLocalStorage` Pattern

1. The `satisfies` Operator

4. The `Prettify` Helper (The "Tooltip Hack")

6. Key Remapping via `as`

7. Block Inference with `NoInfer` (TS 5.4+)

1. The Foundation: `handlePromise`

🧰 The Code (`lib/utils.ts`)

2. The Workhorse: The `ServerAction` Factory

🧰 The Code (`lib/server-action.ts`)

3. The API Sibling: `createApiHandler`

🧰 The Code (`lib/api-handler.ts`)

1. The Classic: Getters & Setters (`Object.defineProperty`)

2. The Modern Powerhouse: `Proxy`