DEV Community: Maxim Logunov

Mastering the Orchestration Pattern in React: Taming Complex Component Logic

Maxim Logunov — Mon, 30 Mar 2026 17:21:32 +0000

TL;DR: The Orchestration Pattern is a powerful way to manage complex interactions between components, API calls, and state updates in React. Instead of letting logic scatter across dozens of useEffect hooks and event handlers, you centralize it into a dedicated "orchestrator" component or hook. This approach makes your code more predictable, testable, and maintainable—especially in enterprise applications with complex workflows.

The Problem: When React Components Become Spaghetti

Let's be honest. We've all been there. You start building a feature—say, a multi-step checkout form. Initially, it's simple. A few inputs, a submit button.

But then requirements grow:

"We need to validate the address against a third-party API."
"If the user is a returning customer, pre-fetch their saved payment methods."
"Apply discount codes, but only after shipping is calculated."
"If payment fails, show a specific error and roll back the shipping selection."

Suddenly, your component looks like this:

const Checkout = () => {
  const [step, setStep] = useState(1);
  const [cart, setCart] = useState(null);
  const [shipping, setShipping] = useState(null);
  const [payment, setPayment] = useState(null);
  const [discount, setDiscount] = useState(null);
  const [errors, setErrors] = useState({});
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    // Fetch cart on mount
  }, []);

  useEffect(() => {
    // Recalculate shipping when address changes
  }, [address]);

  useEffect(() => {
    // Apply discount when cart or code changes
  }, [discountCode, cart]);

  const handlePayment = async () => {
    // Complex logic with multiple steps and error handling
  };

  // 300+ more lines of imperative, hard-to-follow code...
};

This is imperative spaghetti. The "what" (user wants to checkout) is buried in the "how" (fetch this, update that, call this API, show this error). It's hard to test, hard to debug, and even harder for new team members to understand.

Enter the Orchestration Pattern.

What Is the Orchestration Pattern in React?

Inspired by backend microservices architecture (where an orchestrator coordinates multiple services), the Orchestration Pattern in React applies the same principle: centralize complex workflow logic into a single coordinator.

Think of it like a movie director:

Orchestrator (Director): Knows the script. Calls "Action!" to the camera team, tells the actor when to enter, signals the lighting crew.
Components/APIs (Actors/Crew): Do one thing well. They don't know the full script—they just respond to commands.

In React terms, the orchestrator manages:

The sequence of operations (API call A, then B, then C)
Branching logic (if response X, do Y; else do Z)
Error handling and compensation (if step 3 fails, roll back step 2)
State transitions (loading → success → error)
Side effect coordination (avoiding race conditions)

A Simple Orchestration Pattern Implementation

Let's refactor the checkout example using a custom hook as our orchestrator.

Step 1: Define the Orchestrator Hook

// hooks/useCheckoutOrchestrator.js
import { useReducer, useCallback } from 'react';
import { validateAddress } from '../api/address';
import { calculateShipping } from '../api/shipping';
import { applyDiscount } from '../api/discount';
import { processPayment } from '../api/payment';

// State machine for the checkout process
const initialState = {
  status: 'idle', // idle, validating, calculating, paying, success, error
  step: 1,
  cart: null,
  address: null,
  shipping: null,
  discount: null,
  paymentResult: null,
  error: null,
};

function checkoutReducer(state, action) {
  switch (action.type) {
    case 'SET_CART':
      return { ...state, cart: action.payload };
    case 'SET_ADDRESS':
      return { ...state, address: action.payload };
    case 'VALIDATION_START':
      return { ...state, status: 'validating', error: null };
    case 'VALIDATION_SUCCESS':
      return { ...state, status: 'idle', step: 2 };
    case 'VALIDATION_ERROR':
      return { ...state, status: 'error', error: action.payload };
    case 'SHIPPING_START':
      return { ...state, status: 'calculating' };
    case 'SHIPPING_SUCCESS':
      return { ...state, status: 'idle', shipping: action.payload, step: 3 };
    case 'PAYMENT_START':
      return { ...state, status: 'paying' };
    case 'PAYMENT_SUCCESS':
      return { ...state, status: 'success', paymentResult: action.payload, step: 4 };
    case 'PAYMENT_ERROR':
      return { ...state, status: 'error', error: action.payload };
    case 'RESET':
      return initialState;
    default:
      return state;
  }
}

export function useCheckoutOrchestrator() {
  const [state, dispatch] = useReducer(checkoutReducer, initialState);

  const setCart = useCallback((cart) => {
    dispatch({ type: 'SET_CART', payload: cart });
  }, []);

  const setAddress = useCallback((address) => {
    dispatch({ type: 'SET_ADDRESS', payload: address });
  }, []);

  // The orchestrator's main workflow
  const validateAndProceed = useCallback(async (address) => {
    dispatch({ type: 'VALIDATION_START' });

    try {
      // Step 1: Validate address
      const isValid = await validateAddress(address);
      if (!isValid) {
        throw new Error('Invalid address format');
      }
      dispatch({ type: 'VALIDATION_SUCCESS' });

      // Step 2: Calculate shipping based on validated address
      dispatch({ type: 'SHIPPING_START' });
      const shippingOptions = await calculateShipping(address, state.cart);
      dispatch({ type: 'SHIPPING_SUCCESS', payload: shippingOptions });

    } catch (error) {
      dispatch({ type: 'VALIDATION_ERROR', payload: error.message });
    }
  }, [state.cart]);

  const applyDiscountCode = useCallback(async (code) => {
    if (!state.cart) return;

    try {
      const discount = await applyDiscount(code, state.cart);
      dispatch({ type: 'SET_DISCOUNT', payload: discount });
      // Recalculate shipping with discount applied
      dispatch({ type: 'SHIPPING_START' });
      const updatedShipping = await calculateShipping(state.address, state.cart, discount);
      dispatch({ type: 'SHIPPING_SUCCESS', payload: updatedShipping });
    } catch (error) {
      dispatch({ type: 'SET_ERROR', payload: error.message });
    }
  }, [state.cart, state.address]);

  const processPaymentAndComplete = useCallback(async (paymentDetails) => {
    dispatch({ type: 'PAYMENT_START' });

    try {
      const result = await processPayment({
        cart: state.cart,
        shipping: state.shipping,
        discount: state.discount,
        paymentDetails,
      });

      dispatch({ type: 'PAYMENT_SUCCESS', payload: result });

      // Optional: Navigate to success page
      return result;

    } catch (error) {
      dispatch({ type: 'PAYMENT_ERROR', payload: error.message });

      // Compensation logic: if payment fails, shipping selection remains
      // but we might want to show a retry option
      throw error;
    }
  }, [state.cart, state.shipping, state.discount]);

  const reset = useCallback(() => {
    dispatch({ type: 'RESET' });
  }, []);

  return {
    // State
    status: state.status,
    step: state.step,
    cart: state.cart,
    shipping: state.shipping,
    discount: state.discount,
    error: state.error,
    paymentResult: state.paymentResult,

    // Actions (the public API of our orchestrator)
    setCart,
    setAddress,
    validateAndProceed,
    applyDiscountCode,
    processPaymentAndComplete,
    reset,
  };
}

Step 2: Consume the Orchestrator in Components

Now your components become "dumb" presentational components that simply call the orchestrator's methods:

// CheckoutPage.jsx
import { useCheckoutOrchestrator } from '../hooks/useCheckoutOrchestrator';
import { AddressForm } from './AddressForm';
import { ShippingSelector } from './ShippingSelector';
import { PaymentForm } from './PaymentForm';
import { LoadingSpinner } from './LoadingSpinner';
import { ErrorAlert } from './ErrorAlert';

export const CheckoutPage = () => {
  const {
    status,
    step,
    cart,
    shipping,
    error,
    validateAndProceed,
    applyDiscountCode,
    processPaymentAndComplete,
    reset,
  } = useCheckoutOrchestrator();

  // Components don't need to know the complex flow!
  // They just call the orchestrator's methods.

  const handleAddressSubmit = async (addressData) => {
    await validateAndProceed(addressData);
  };

  const handleDiscountApply = async (code) => {
    await applyDiscountCode(code);
  };

  const handlePaymentSubmit = async (paymentDetails) => {
    try {
      await processPaymentAndComplete(paymentDetails);
      // Navigation happens automatically in the orchestrator
    } catch (err) {
      // Error is already in state, but we can show a toast if needed
    }
  };

  if (status === 'success') {
    return <OrderConfirmation order={paymentResult} onNewOrder={reset} />;
  }

  return (
    <div className="checkout">
      {error && <ErrorAlert message={error} onDismiss={() => reset()} />}

      {status === 'validating' || status === 'calculating' || status === 'paying' ? (
        <LoadingSpinner message="Processing your order..." />
      ) : (
        <>
          {step === 1 && (
            <AddressForm onSubmit={handleAddressSubmit} />
          )}

          {step === 2 && (
            <>
              <DiscountInput onApply={handleDiscountApply} />
              <ShippingSelector 
                options={shipping} 
                onSelect={handleShippingSelect} 
              />
              <button onClick={() => setStep(3)}>Continue to Payment</button>
            </>
          )}

          {step === 3 && (
            <PaymentForm 
              total={calculateTotal(cart, shipping, discount)}
              onSubmit={handlePaymentSubmit}
            />
          )}
        </>
      )}
    </div>
  );
};

Benefits of the Orchestration Pattern

1. Separation of Concerns

Components focus on presentation and user interactions
Orchestrator handles the "how" and "when"
API layers handle raw data fetching

2. Testability

Test the orchestrator in isolation without rendering UI:

test('checkout flow handles validation failure', async () => {
  const { result } = renderHook(() => useCheckoutOrchestrator());

  // Mock API to fail
  jest.spyOn(api, 'validateAddress').mockRejectedValue(new Error('Invalid'));

  await act(async () => {
    await result.current.validateAndProceed({ street: '123 Main' });
  });

  expect(result.current.status).toBe('error');
  expect(result.current.error).toBe('Invalid');
  expect(result.current.step).toBe(1); // Still on address step
});

3. Reusability

The same orchestrator can be used across different UI implementations:

Mobile checkout screen
Desktop checkout modal
Admin panel order creation

4. Observability

Centralized logic makes it easy to add logging, analytics, or error tracking:

const validateAndProceed = useCallback(async (address) => {
  analytics.trackEvent('checkout_address_validation_started');

  try {
    // ... validation logic
    analytics.trackEvent('checkout_address_validation_success');
  } catch (error) {
    analytics.trackEvent('checkout_address_validation_failed', { error });
    Sentry.captureException(error);
  }
}, []);

When to Use Orchestration (and When Not To)

✅ Great Use Cases:

Multi-step forms (checkout, onboarding, surveys)
Wizard-style workflows (report generation, deployment pipelines)
Features with complex dependencies (dashboard with sequential data fetches)
Operations requiring rollback/compensation (bank transfers, reservations)

❌ Overkill For:

Simple CRUD forms with one API call
Independent, isolated components with no coordination needs
Small applications where complexity doesn't justify abstraction

Best Practices

Keep orchestrators stateless where possible — store state in React state or a state machine, not in the orchestrator instance itself.
Use TypeScript — define clear interfaces for your orchestrator's context and events:

interface CheckoutContext {
  cart: Cart | null;
  address: Address | null;
  shipping: ShippingOption[] | null;
}

type CheckoutEvent = 
  | { type: 'VALIDATE_ADDRESS'; address: Address }
  | { type: 'SELECT_SHIPPING'; method: ShippingMethod }
  | { type: 'PROCESS_PAYMENT'; details: PaymentDetails };

Single responsibility — an orchestrator should coordinate ONE business process. Don't create a "god orchestrator" that handles checkout, profile updates, and notifications all in one place.
Compose orchestrators — for complex apps, create smaller orchestrators that work together:

function useOrderOrchestrator() {
  const cart = useCartOrchestrator();
  const checkout = useCheckoutOrchestrator();
  const payment = usePaymentOrchestrator();

  // Compose them into a higher-level workflow
}

Conclusion

The Orchestration Pattern transforms React applications from a collection of scattered useEffect hooks and imperative logic into a clean, declarative system. By centralizing workflow coordination, you get:

Components that are simple and focused on presentation
Orchestrators that clearly express business logic
Code that's easier to test, debug, and maintain

Whether you implement it with custom hooks, XState, or a full workflow engine, the principle remains the same: coordinate complexity in one place, not everywhere.

Have you used the Orchestration Pattern in your React apps? What challenges did you face? Let me know in the comments! 👇

Controlled vs. Uncontrolled Components in React: A Practical Guide

Maxim Logunov — Mon, 08 Dec 2025 19:08:10 +0000

In React development, one of the fundamental decisions you'll face when working with forms and inputs is whether to use controlled or uncontrolled components. This choice impacts everything from state management to performance and code structure.

What Are Controlled Components?

Controlled components are React components where form data is handled by React state. The component's state serves as the "single source of truth" for the input value.

import { useState } from 'react';

function ControlledForm() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log({ name, email });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Name"
      />
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email"
      />
      <button type="submit">Submit</button>
    </form>
  );
}

In this example, React completely controls the input values through state variables (name and email). Every keystroke triggers a state update and re-render.

What Are Uncontrolled Components?

Uncontrolled components are components where form data is handled by the DOM itself. You use refs to access DOM values when needed, rather than storing them in React state.

import { useRef } from 'react';

function UncontrolledForm() {
  const nameRef = useRef();
  const emailRef = useRef();

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log({
      name: nameRef.current.value,
      email: emailRef.current.value
    });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        ref={nameRef}
        placeholder="Name"
      />
      <input
        type="email"
        ref={emailRef}
        placeholder="Email"
      />
      <button type="submit">Submit</button>
    </form>
  );
}

Here, React doesn't track the input values—the DOM does. We only access the values when the form is submitted.

Key Differences at a Glance

Aspect	Controlled Components	Uncontrolled Components
Data Flow	React state → DOM	DOM → React (via refs)
Value Source	React state	DOM
Updates	On every change	On demand (form submit, etc.)
Validation	Real-time validation	Typically on submit
Re-renders	Every keystroke	Minimal
Complexity	More boilerplate	Less boilerplate

When to Use Controlled Components

1. Immediate Validation and Feedback

When you need to validate user input as they type (e.g., password strength meter, email format checking).

function PasswordInput() {
  const [password, setPassword] = useState('');
  const [strength, setStrength] = useState('');

  const evaluateStrength = (value) => {
    if (value.length < 5) return 'Weak';
    if (value.length < 10) return 'Medium';
    return 'Strong';
  };

  const handleChange = (e) => {
    const value = e.target.value;
    setPassword(value);
    setStrength(evaluateStrength(value));
  };

  return (
    <div>
      <input
        type="password"
        value={password}
        onChange={handleChange}
      />
      <span>Strength: {strength}</span>
    </div>
  );
}

2. Conditional Form Logic

When inputs depend on each other's values.

function TravelForm() {
  const [tripType, setTripType] = useState('one-way');
  const [returnDate, setReturnDate] = useState('');

  return (
    <form>
      <select value={tripType} onChange={(e) => setTripType(e.target.value)}>
        <option value="one-way">One-way</option>
        <option value="round-trip">Round-trip</option>
      </select>

      {/* Only show return date for round trips */}
      {tripType === 'round-trip' && (
        <input
          type="date"
          value={returnDate}
          onChange={(e) => setReturnDate(e.target.value)}
        />
      )}
    </form>
  );
}

3. Complex Form State Management

When using form libraries like Formik or React Hook Form, which internally use controlled patterns for advanced features.

4. Dynamic Form Generation

When form fields are generated based on external data or user actions.

When to Use Uncontrolled Components

1. Performance-Critical Forms

When dealing with large forms where re-rendering on every keystroke would cause performance issues.

function LargeUncontrolledForm() {
  const formRef = useRef();

  const handleSubmit = (e) => {
    e.preventDefault();
    const formData = new FormData(formRef.current);
    const data = Object.fromEntries(formData);
    // Process all form data at once
  };

  return (
    <form ref={formRef} onSubmit={handleSubmit}>
      {/* 50+ inputs here */}
      <input name="field1" defaultValue="" />
      <input name="field2" defaultValue="" />
      {/* ... */}
    </form>
  );
}

2. File Inputs

File inputs are always uncontrolled in React since their value is read-only.

function FileUpload() {
  const fileRef = useRef();

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log('Selected file:', fileRef.current.files[0]);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="file" ref={fileRef} />
      <button type="submit">Upload</button>
    </form>
  );
}

3. Simple Forms with No Validation

When you only need to collect data on submit without any intermediate processing.

4. Integrating with Non-React Libraries

When you need to integrate with third-party libraries that manage their own DOM state.

Hybrid Approach: The Best of Both Worlds

In practice, many applications use a combination of both approaches:

function HybridForm() {
  // Controlled for important fields
  const [email, setEmail] = useState('');

  // Uncontrolled for less important fields
  const phoneRef = useRef();
  const addressRef = useRef();

  const handleSubmit = (e) => {
    e.preventDefault();
    const data = {
      email, // From state
      phone: phoneRef.current.value, // From ref
      address: addressRef.current.value
    };
    console.log(data);
  };

  return (
    <form onSubmit={handleSubmit}>
      {/* Controlled: Need validation */}
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        required
      />

      {/* Uncontrolled: Simple data collection */}
      <input
        type="tel"
        ref={phoneRef}
        defaultValue=""
      />
      <textarea
        ref={addressRef}
        defaultValue=""
      />
    </form>
  );
}

Modern Solutions: Form Libraries

Modern React form libraries often abstract these decisions:

React Hook Form: Primarily uses uncontrolled components with refs for performance, but supports controlled components when needed.
Formik: Primarily uses controlled components for comprehensive state management.
Final Form: Uses a hybrid approach with subscription-based updates.

Best Practices and Recommendations

Default to controlled components for most form scenarios—they make your UI more predictable and easier to debug.
Consider uncontrolled components when:
- You have performance issues with complex forms
- You're integrating with non-React code
- You're building simple, submission-only forms
Use the right tool for the job:
- For login/registration forms: Controlled (immediate validation)
- For search inputs: Controlled (live search)
- For settings/preference forms: Either, depending on complexity
- For file uploads: Uncontrolled (required)
Remember accessibility: Both approaches can be accessible, but controlled components make it easier to implement real-time ARIA announcements and error messages.

Conclusion

The choice between controlled and uncontrolled components isn't about which is "better," but which is more appropriate for your specific use case. Controlled components give you more power and predictability, while uncontrolled components offer better performance and simpler code for certain scenarios.

As a general rule: Start with controlled components unless you have a specific reason not to. As your application grows, you can optimize with uncontrolled components where it makes sense, or leverage modern form libraries that handle these concerns for you.

Understanding both patterns makes you a more versatile React developer, capable of choosing the right approach for each situation and building more efficient, maintainable applications.

TypeScript Enums Showdown: `const enum` vs `enum` vs `object as const`

Maxim Logunov — Tue, 02 Sep 2025 18:17:41 +0000

Introduction

When working with TypeScript, developers often need to represent a set of related constants. While traditional enums are the obvious choice, TypeScript offers multiple approaches, each with distinct advantages and trade-offs. In this article, we'll explore three primary methods: const enum, regular enum, and object with as const, helping you make informed decisions for your projects.

1. Regular Enums (`enum`)

What they are: Traditional enums that exist both at compile time and runtime.

export enum UserRole {
  Admin = "ADMIN",
  User = "USER",
  Guest = "GUEST"
}

Compilation output:

export var UserRole;
(function (UserRole) {
    UserRole["Admin"] = "ADMIN";
    UserRole["User"] = "USER";
    UserRole["Guest"] = "GUEST";
})(UserRole || (UserRole = {}));

Pros:

✅ Runtime existence: Full object available during execution
✅ Reflection support: Can iterate, validate, and introspect values
✅ Cross-module compatibility: Works seamlessly across file boundaries
✅ Familiar syntax: Traditional enum behavior from other languages

Cons:

❌ Larger bundle size: Generates additional JavaScript code
❌ Poor tree-shaking: Hard to eliminate unused values
❌ Performance overhead: Object creation and property access

Best for: Public APIs, runtime validation, and scenarios needing introspection.

2. Const Enums (`const enum`)

What they are: Compile-time only enums that get completely erased from JavaScript output.

export const enum HttpStatus {
  OK = 200,
  Created = 201,
  NotFound = 404,
  ServerError = 500
}

Compilation result: Values are inlined directly where used:

// Instead of HttpStatus.OK, you get:
const status = 200;

Pros:

✅ Zero runtime overhead: No generated JavaScript code
✅ Excellent performance: Values inlined directly
✅ Perfect tree-shaking: No unused code remains
✅ Small bundle size: Minimal impact on final build

Cons:

❌ No runtime access: Cannot iterate or introspect
❌ Module boundary issues: Problems with isolated compilation
❌ Debugging challenges: Original enum names may be lost

Best for: Internal constants, performance-critical code, and simple value mappings.

3. Object with `as const`

What they are: TypeScript's modern approach using plain objects with const assertions.

export const UserRole = {
  Admin: "ADMIN",
  User: "USER",
  Guest: "GUEST"
} as const;

export type UserRole = typeof UserRole[keyof typeof UserRole];

Compilation output: (Identical to input)

export const UserRole = {
  Admin: "ADMIN",
  User: "USER",
  Guest: "GUEST"
};

Pros:

✅ No runtime cost: Plain object, no extra generated code
✅ Full type safety: Complete TypeScript integration
✅ Runtime access: Full object available for introspection
✅ Modern pattern: Aligns with TypeScript's evolution
✅ Flexible values: Can mix types (strings, numbers, etc.)

Cons:

❌ Manual type extraction: Requires additional type definition
❌ No built-in reverse mapping: Unlike numeric enums
❌ Slightly more verbose: Two declarations needed

Best for: Modern codebases, mixed value types, and when needing both compile-time and runtime access.

Comparative Analysis

Bundle Size Impact

// enum: ~150 bytes generated
enum Colors { Red, Green, Blue }

// const enum: 0 bytes generated  
const enum Colors { Red, Green, Blue }

// object as const: ~50 bytes (just the object)
const Colors = { Red: 0, Green: 1, Blue: 2 } as const

Runtime Performance

// enum: Object property access
const color = Colors.Red;

// const enum: Direct value inline (fastest)
const color = 0;

// object as const: Object property access
const color = Colors.Red;

Type Safety

All three approaches provide excellent type safety, but object as const offers the most flexibility with mixed types:

// Only possible with object as const
const Status = {
  Active: "ACTIVE",
  Pending: 0,
  Disabled: "DISABLED"
} as const;

Practical Examples

Scenario 1: API Response Handling

// Best: object as const (needs runtime validation)
export const ApiErrorCode = {
  NotFound: "NOT_FOUND",
  Unauthorized: "UNAUTHORIZED",
  ServerError: "SERVER_ERROR"
} as const;

export type ApiErrorCode = typeof ApiErrorCode[keyof typeof ApiErrorCode];

function handleError(code: ApiErrorCode) {
  if (Object.values(ApiErrorCode).includes(code)) {
    // Valid error code
  }
}

Scenario 2: Internal Constants

// Best: const enum (compile-time only)
export const enum Direction {
  Up = 1,
  Down = 2,
  Left = 3,
  Right = 4
}

function move(direction: Direction) {
  // Values get inlined: direction === 1, etc.
}

Scenario 3: Public Library API

// Best: regular enum (runtime compatibility)
export enum LogLevel {
  Error = 0,
  Warn = 1,
  Info = 2,
  Debug = 3
}

// Consumers can iterate or validate
console.log(Object.values(LogLevel));

Migration Example

From traditional enum:

enum OldStyle {
  Value1 = "VALUE1",
  Value2 = "VALUE2"
}

To modern object as const:

const NewStyle = {
  Value1: "VALUE1",
  Value2: "VALUE2"
} as const;

type NewStyle = typeof NewStyle[keyof typeof NewStyle];

Decision Guide

Use Case	Recommended Approach
Public library API	`enum`
Performance-critical code	`const enum`
Runtime validation	`object as const`
Mixed value types	`object as const`
Legacy codebase	`enum` (consistency)
New project	`object as const`
Cross-module usage	`enum` or `object as const`

Best Practices

Use object as const for most new development
Reserve const enum for performance-sensitive constants
Choose enum when publishing libraries for wider consumption
Consider tooling: Some build tools handle const enum poorly
Be consistent within your codebase

Conclusion

TypeScript offers multiple ways to handle constants, each serving different needs:

enum: The traditional choice for runtime access and compatibility
const enum: The performance optimizer for compile-time only values
object as const: The modern, flexible approach for most use cases

Understanding these options allows you to write more efficient, maintainable TypeScript code. For most modern applications, object as const provides the best balance of type safety, runtime access, and bundle size efficiency, while const enum remains valuable for performance-critical scenarios and enum maintains its place in public APIs and legacy codebases.

Choose based on your specific needs, and remember that consistency within a project is often more important than absolute optimization.

Advanced React Refs: Mastering the Callback Pattern

Maxim Logunov — Mon, 01 Sep 2025 18:06:05 +0000

In the world of React, refs are a powerful escape hatch that allow you to access DOM elements or React component instances directly. While most developers are familiar with the basic useRef hook (const ref = useRef(null)), its more advanced cousin, the ref callback, offers a level of flexibility and control that is essential for complex scenarios. This article will explore what a ref callback is, how it works, and the practical problems it can solve.

What is a Ref Callback?

A ref callback is a function that React will call when a component mounts, passing the DOM element (or class component instance) as its argument. Similarly, it will call the function with null when the component unmounts.

Instead of assigning the ref.current property for you (as useRef does), you handle the node yourself.

Basic Syntax:

function MyComponent() {
  const handleRef = (node) => {
    if (node) {
      // Node is mounted. Do something with the DOM element.
      console.log('Element mounted:', node);
      node.focus(); // Example: focus the input on mount
    } else {
      // Node is unmounted. Clean up if necessary.
      console.log('Element unmounted');
    }
  };

  return <input ref={handleRef} />;
}

Contrast this with the standard useRef approach:

function MyComponent() {
  const inputRef = useRef(null);

  useEffect(() => {
    // Now we need an effect to access the ref after mount.
    if (inputRef.current) {
      inputRef.current.focus();
    }
  }, []);

  return <input ref={inputRef} />;
}

While the useRef + useEffect pattern is common and perfectly valid for many cases, the ref callback approach is more direct for certain operations on mount.

Key Use Cases and Benefits

1. Dynamic Ref Handling for Lists

This is the most compelling reason to use a ref callback. Imagine you need to store refs for each item in a dynamically generated list. Using a standard useRef would require you to create an array of refs and manage them manually. A ref callback simplifies this immensely.

Example: Managing a list of refs

function DynamicList({ items }) {
  // Store our DOM nodes in a state array
  const [itemNodes, setItemNodes] = useState([]);

  const handleItemRef = (node) => {
    if (node) {
      // Add the node to our array when it's mounted
      setItemNodes((prevNodes) => [...prevNodes, node]);
    }
    // Note: In a real app, you'd also need a cleanup to remove nodes on unmount.
    // This can be done with a separate effect or a more complex ref callback.
  };

  // Now you can programmatically interact with any list item
  const scrollToIndex = (index) => {
    itemNodes[index]?.scrollIntoView();
  };

  return (
    <ul>
      {items.map((item) => (
        <li key={item.id} ref={handleItemRef}>
          {item.name}
        </li>
      ))}
    </ul>
  );
}

2. Abstracting Reusable Logic with Custom Hooks

Ref callbacks are the foundation for building powerful custom hooks that need to interact with the DOM. A hook can take a ref callback from its parent and merge it with its own internal ref logic.

Example: A custom useFocus hook

function useFocus(forwardedRef) {
  const innerRef = useRef(null);

  // This is the ref callback we'll return and assign to the component.
  const refCallback = useCallback((node) => {
    // Handle the internal ref
    innerRef.current = node;

    // Handle the forwarded ref (could be a function or a ref object)
    if (typeof forwardedRef === 'function') {
      forwardedRef(node);
    } else if (forwardedRef) {
      forwardedRef.current = node;
    }

    // Our hook's logic: focus the element when it mounts
    if (node) {
      node.focus();
    }
  }, [forwardedRef]); // Re-create the callback if the forwardedRef changes

  return refCallback;
}

// Usage in a component
function MyInput(props) {
  const myRef = useRef(null);
  const inputRef = useFocus(myRef); // Can also forward a ref from a parent

  return <input ref={inputRef} />;
}

This pattern of "ref forwarding" and merging is how libraries like react-aria or framer-motion manage to control DOM elements while still allowing you to pass your own refs.

3. Triggering Logic Directly on Mount/Unmount

Sometimes, you want to perform an action the moment a DOM node is available, without waiting for the useEffect to run after the render is committed to the screen. A ref callback fires synchronously during the render phase when the node is created.

function VideoPlayer({ src }) {
  const handleVideoRef = (node) => {
    if (node) {
      console.log('Video element is ready!');
      node.load(); // Load the video immediately
    } else {
      console.log('Video element is leaving the DOM.');
      // Clean up resources if needed
    }
  };

  return <video ref={handleVideoRef} src={src} controls />;
}

Important Caveats and Best Practices

Closures and Callback Dependencies: The ref callback is called on every render (if the ref itself changes). However, React will call it with null from the previous render and then with the current node. Be cautious of stale closures. If your callback depends on props or state, wrap it in useCallback to avoid unnecessary executions and cleanups.
```
const handleRef = useCallback((node) => {
  if (node) {
    // Do something that depends on `someProp`
    node.style.color = someProp;
  }
}, [someProp]); // Re-create the callback only when `someProp` changes
```
Avoiding Side Effects During Render: While ref callbacks are called during render, you should avoid setting state synchronously within them. This can lead to unpredictable behavior and infinite loops. If you need to set state based on a ref, use the else branch or a useEffect for the null case to handle cleanup.

Conclusion

The ref callback is a versatile tool that moves you from simply holding a DOM reference to reacting to its lifecycle. It's indispensable for:

Managing dynamic lists of refs.
Building composable custom hooks that need DOM access.
Executing code directly the moment a DOM node is created or destroyed.

While useRef(null) is sufficient for most simple cases, understanding and leveraging the ref callback pattern will undoubtedly elevate your ability to write clean, powerful, and flexible React code that interacts directly with the DOM.

Updating State Based on Previous State in React

Maxim Logunov — Fri, 22 Aug 2025 19:27:23 +0000

When working with React, properly managing state is crucial for building predictable and performant applications. One common point of confusion for developers is how to correctly update state based on its previous value. In this article, we'll explore why this matters and demonstrate the right way to do it.

The Problem with Direct State Updates

Consider this common mistake:

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

  const increment = () => {
    // ❌ Wrong approach
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

While this might work for simple cases, it can cause issues when:

Multiple state updates are queued in rapid succession
Your update depends on the previous state value
Async operations are involved

The Solution: Functional State Updates

React provides a solution through functional updates. Instead of passing a new value directly to the state setter, you pass a function that receives the previous state and returns the new state:

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

  const increment = () => {
    // ✅ Correct approach
    setCount(prevCount => prevCount + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

When Functional Updates Are Essential

1. Multiple State Updates

If you need to update state multiple times based on its previous value:

function MultipleUpdates() {
  const [score, setScore] = useState(0);

  const updateScore = () => {
    // ❌ This won't work as expected
    setScore(score + 5);
    setScore(score + 5); // Both use the same initial value

    // ✅ This will work correctly
    setScore(prevScore => prevScore + 5);
    setScore(prevScore => prevScore + 5); // Uses updated value
  };

  return (
    <div>
      <p>Score: {score}</p>
      <button onClick={updateScore}>Add 10 points</button>
    </div>
  );
}

2. Async State Updates

When working with asynchronous operations:

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

  const delayedIncrement = () => {
    setTimeout(() => {
      // ✅ Guaranteed to use latest state
      setCount(prevCount => prevCount + 1);
    }, 1000);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={delayedIncrement}>Increment after delay</button>
    </div>
  );
}

3. Complex State Objects

When your state is an object or array:

function TodoList() {
  const [todos, setTodos] = useState([]);
  const [input, setInput] = useState('');

  const addTodo = () => {
    if (input.trim()) {
      // ✅ Correctly updates based on previous state
      setTodos(prevTodos => [
        ...prevTodos,
        { id: Date.now(), text: input, completed: false }
      ]);
      setInput('');
    }
  };

  const toggleTodo = id => {
    // ✅ Updates specific item in array
    setTodos(prevTodos =>
      prevTodos.map(todo =>
        todo.id === id ? { ...todo, completed: !todo.completed } : todo
      )
    );
  };

  return (
    <div>
      <input
        value={input}
        onChange={e => setInput(e.target.value)}
        placeholder="Add a todo"
      />
      <button onClick={addTodo}>Add</button>
      <ul>
        {todos.map(todo => (
          <li
            key={todo.id}
            onClick={() => toggleTodo(todo.id)}
            style={{
              textDecoration: todo.completed ? 'line-through' : 'none'
            }}
          >
            {todo.text}
          </li>
        ))}
      </ul>
    </div>
  );
}

Class Components and setState

The same principle applies to class components:

class Counter extends React.Component {
  state = { count: 0 };

  increment = () => {
    // ✅ Functional update in class component
    this.setState(prevState => ({
      count: prevState.count + 1
    }));
  };

  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={this.increment}>Increment</button>
      </div>
    );
  }
}

Performance Considerations

Functional updates can also help with performance in some cases, as they allow React to batch updates more effectively and avoid unnecessary re-renders.

Conclusion

Always use functional updates when:

Your new state depends on the previous state
You're performing multiple state updates in sequence
Working with asynchronous operations
Updating complex state structures (objects, arrays)

This practice ensures your state updates are predictable and consistent, preventing subtle bugs that can occur when state updates are based on potentially stale values.

By adopting functional updates as a standard practice, you'll write more robust React components that behave consistently even as your application grows in complexity.

Understanding `event.target` and `event.currentTarget` in JavaScript

Maxim Logunov — Thu, 21 Aug 2025 19:24:32 +0000

When working with events in JavaScript, you'll frequently encounter two important properties: event.target and event.currentTarget. While they might seem similar at first glance, understanding their differences is crucial for effective event handling in your web applications.

What Are These Properties?

In JavaScript's event handling system, both event.target and event.currentTarget help you identify which element is involved with an event, but they serve different purposes:

event.target: Refers to the element that originally triggered the event
event.currentTarget: Refers to the element that currently has the event listener attached

A Practical Example

Let's consider a common scenario with event delegation:

<div id="container">
  <button>Click me</button>
  <button>No, click me!</button>
  <button>I'm the best button!</button>
</div>

<script>
  const container = document.getElementById('container');

  container.addEventListener('click', function(event) {
    console.log('target:', event.target.tagName); // The actual clicked element
    console.log('currentTarget:', event.currentTarget.tagName); // The DIV container
  });
</script>

In this example:

If you click a button, event.target will be the <BUTTON> element
event.currentTarget will always be the <DIV> with id="container"

When to Use Each Property

Use `event.target` when:

Event delegation: You want to identify which specific child element was interacted with
Identifying the source: You need to know the exact element that initiated the event
Conditional handling: You want to perform different actions based on which element was clicked

document.getElementById('menu').addEventListener('click', function(event) {
  if (event.target.classList.contains('menu-item')) {
    // Handle menu item click
    console.log('Menu item clicked:', event.target.textContent);
  }
});

Use `event.currentTarget` when:

Accessing the handler's context: You need to reference the element to which the event listener is attached
Working with this context: In regular functions, event.currentTarget equals this
Consistent element reference: You want to always reference the same element regardless of what child was clicked

const buttons = document.querySelectorAll('.btn');

buttons.forEach(button => {
  button.addEventListener('click', function(event) {
    // Both approaches work the same way
    console.log(event.currentTarget.dataset.id);
    console.log(this.dataset.id); // 'this' refers to the button element
  });
});

Key Differences in a Nutshell

Property	Description	Changes during event bubbling?
`event.target`	The element that triggered the event	Never changes
`event.currentTarget`	The element with the event listener	Changes as the event bubbles

Common Pitfalls and Best Practices

Arrow functions: Remember that arrow functions don't have their own this context, so event.currentTarget becomes essential:

// With regular function - both work
element.addEventListener('click', function(event) {
  console.log(this === event.currentTarget); // true
});

// With arrow function - only currentTarget works
element.addEventListener('click', (event) => {
  console.log(event.currentTarget); // works
  console.log(this); // may not be what you expect
});

Event delegation efficiency: Use event.target for efficient event handling on parent elements rather than attaching multiple listeners to child elements.
Stopping propagation: Be cautious when using event.stopPropagation() as it affects the bubbling phase and thus which elements will receive the event.

Real-World Use Cases

Dynamic content management:

// Handle clicks on dynamically added items
document.getElementById('list').addEventListener('click', function(event) {
  if (event.target.classList.contains('delete-btn')) {
    deleteItem(event.target.closest('.item').dataset.id);
  }
});

Form handling:

// Handle all input changes in a form
document.getElementById('myForm').addEventListener('change', function(event) {
  if (event.target.type === 'checkbox') {
    updatePreferences(event.target.name, event.target.checked);
  }
});

Conclusion

Understanding the distinction between event.target and event.currentTarget is fundamental to effective JavaScript event handling. Use event.target to identify the origin of an event, particularly in event delegation scenarios. Use event.currentTarget when you need to reference the element that's currently handling the event. This knowledge will help you write more efficient, maintainable, and bug-free event handling code in your web applications.

Remember: event.target is where the event started, while event.currentTarget is where it's currently being handled.

How to Safely Use `dangerouslySetInnerHTML` in React Applications

Maxim Logunov — Fri, 15 Aug 2025 19:05:50 +0000

React is designed to protect against Cross-Site Scripting (XSS) attacks by automatically escaping HTML content. However, there are cases where you need to render raw HTML, such as when working with rich text from a CMS or third-party API. React provides dangerouslySetInnerHTML for this purpose—but as the name suggests, it must be used with caution.

In this article, we’ll explore best practices for using dangerouslySetInnerHTML safely in React applications.

What is `dangerouslySetInnerHTML`?

dangerouslySetInnerHTML is a React prop that allows you to inject raw HTML into a component. It bypasses React’s default escaping mechanism, making it potentially dangerous if misused.

Basic Usage:

function MyComponent({ htmlContent }) {
  return <div dangerouslySetInnerHTML={{ __html: htmlContent }} />;
}

Risks of Using `dangerouslySetInnerHTML`

Since this prop directly injects HTML, it can expose your application to:

XSS Attacks: Malicious scripts can execute if the HTML contains untrusted content.
Data Leakage: Injected scripts can steal sensitive user data.
Broken UI: Invalid or poorly formatted HTML can break your layout.

Best Practices for Safe Usage

1. Sanitize HTML Before Rendering

Always sanitize HTML content to remove dangerous scripts, event handlers, and unwanted tags. Use libraries like:

DOMPurify (Recommended)
sanitize-html

Example with DOMPurify:

import DOMPurify from 'dompurify';

function SafeHTMLRenderer({ html }) {
  const cleanHTML = DOMPurify.sanitize(html);
  return <div dangerouslySetInnerHTML={{ __html: cleanHTML }} />;
}

2. Use a Trusted Source

Only use dangerouslySetInnerHTML with content from trusted sources (e.g., your backend with proper sanitization). Never render user-generated content without validation.

3. Limit Scope with Custom Elements

Instead of rendering large chunks of HTML, isolate dynamic content in specific components:

function TrustedContent({ content }) {
  return <div className="trusted-content" dangerouslySetInnerHTML={{ __html: content }} />;
}

4. Avoid Inline Event Handlers

Even if sanitized, avoid allowing onclick, onload, or other inline JavaScript handlers.

5. Implement CSP (Content Security Policy)

A strong CSP can mitigate risks by restricting script execution:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">

6. Use TypeScript for Additional Safety

Enforce type checks to ensure only valid HTML strings are passed:

interface SafeHTMLProps {
  html: string;
}

const SafeHTML: React.FC<SafeHTMLProps> = ({ html }) => {
  const clean = DOMPurify.sanitize(html);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
};

When to Avoid `dangerouslySetInnerHTML`

User-generated content (comments, forms) unless strictly sanitized.
Dynamic script injection – use React components instead.
Unverified third-party data – prefer APIs that return structured data.

Conclusion

While dangerouslySetInnerHTML is a powerful tool, it should be used sparingly and with extreme caution. Always sanitize content, trust your sources, and enforce security policies like CSP. By following these best practices, you can minimize risks while leveraging dynamic HTML rendering in React.

Stay safe and happy coding! 🚀

How React Batches State Updates to Optimize Rendering

Maxim Logunov — Mon, 04 Aug 2025 19:19:47 +0000

Introduction

In React applications, managing state updates efficiently is crucial for maintaining high performance and a smooth user experience. One of React's key optimization techniques is batching state updates, which minimizes unnecessary re-renders and improves application performance. In this article, we'll explore how batching works, when it occurs, and how you can leverage it effectively in your React applications.

What is Batching?

Batching refers to React's practice of grouping multiple state updates into a single re-render for better performance. Instead of triggering a re-render for every individual state change, React can collect several updates and process them together.

// Without batching (older React versions or certain scenarios)
setCount(1); // Re-render 1
setCount(2); // Re-render 2
setCount(3); // Re-render 3

// With batching (modern React)
setCount(1);
setCount(2);
setCount(3); // Only one re-render occurs

When Does Batching Occur?

Automatic Batching in React 18+

Starting with React 18, batching is applied automatically to all state updates regardless of where they originate:

Event handlers: All updates within the same event handler are batched
Async operations: Updates within promises, setTimeout, native event handlers, etc.
Multiple state setters: Calls to multiple useState setters or useReducer dispatches

function handleClick() {
  setCount(c => c + 1);    // These will
  setFlag(f => !f);        // be batched into
  setName('Updated');      // a single re-render
}

Special Cases Before React 18

Prior to React 18, batching only occurred in React event handlers. Updates inside promises, setTimeout, or native event handlers weren't batched:

// React 17 and earlier:
function handleClick() {
  // Batched (inside React event handler)
  setCount(c => c + 1);
  setFlag(f => !f);

  setTimeout(() => {
    // NOT batched (in setTimeout)
    setCount(c => c + 1);
    setFlag(f => !f);
  }, 1000);
}

How to Control Batching

While automatic batching is generally beneficial, there might be cases where you need more control:

1. `flushSync` for Immediate Updates

React provides flushSync to opt-out of batching when necessary:

import { flushSync } from 'react-dom';

function handleClick() {
  flushSync(() => {
    setCount(1); // Immediate update
  });
  // DOM is updated here
  flushSync(() => {
    setFlag(true); // Immediate update
  });
  // DOM is updated again here
}

2. `unstable_batchedUpdates` for Legacy Code

In older versions or special cases, you can use the (unstable) batchedUpdates API:

import { unstable_batchedUpdates } from 'react-dom';

unstable_batchedUpdates(() => {
  setCount(1);
  setFlag(true);
});

Performance Benefits

Batching provides several performance advantages:

Reduced re-renders: Fewer render passes means better performance
Avoiding "tearing": Prevents partial state updates from being visible
Consistent UI: Ensures the UI updates with a complete new state

Best Practices

Trust React's batching: Don't try to manually optimize unless you have measurable performance issues
Group related state: Consider using useReducer for complex, related state
Be mindful of dependencies: Ensure effects and memoized values account for batched updates
Test edge cases: Verify behavior in asynchronous scenarios

Common Pitfalls

Assuming immediate updates: State setters are asynchronous
Reading state right after setting it: Use the updater function form if you need the latest value
Overusing flushSync: This can hurt performance by forcing too many renders

Conclusion

React's batching mechanism is a powerful optimization that works behind the scenes to keep your application performant. With React 18's improved automatic batching, developers can write more straightforward code while still benefiting from optimized rendering. Understanding how and when batching occurs helps you write more efficient React components and avoid common performance pitfalls.

By working with React's batching system rather than against it, you can build applications that are both performant and maintainable.

Using AbortController in Web Development: Controlling Asynchronous Operations

Maxim Logunov — Tue, 29 Jul 2025 18:47:38 +0000

Introduction to AbortController

Modern web development frequently involves asynchronous operations such as API requests, file downloads, or complex computations. AbortController is a powerful JavaScript API that allows developers to cancel such operations when needed.

What is AbortController?

AbortController is an interface representing a controller object that can abort one or more DOM requests and asynchronous operations. It consists of:

An AbortController object that creates a signal
A signal property passed to asynchronous functions
An abort() method that triggers cancellation

Primary Use Cases

1. Canceling Fetch Requests

const controller = new AbortController();
const signal = controller.signal;

fetch('https://api.example.com/data', { signal })
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(err => {
    if (err.name === 'AbortError') {
      console.log('Fetch aborted');
    } else {
      console.error('Fetch error:', err);
    }
  });

// To cancel the request:
controller.abort();

2. Aborting Multiple Requests Simultaneously

const controller = new AbortController();
const signal = controller.signal;

const requests = [
  fetch('/api/data1', { signal }),
  fetch('/api/data2', { signal }),
  fetch('/api/data3', { signal })
];

Promise.all(requests)
  .then(responses => /* process data */)
  .catch(err => {
    if (err.name === 'AbortError') {
      console.log('One or more requests were aborted');
    }
  });

// Cancel all requests at once
controller.abort();

3. Canceling Timers and Custom Async Operations

function cancellableTimeout(callback, delay, signal) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => {
      callback();
      resolve();
    }, delay);

    signal.addEventListener('abort', () => {
      clearTimeout(timer);
      reject(new DOMException('Aborted', 'AbortError'));
    });
  });
}

const controller = new AbortController();
cancellableTimeout(() => console.log('Done'), 5000, controller.signal)
  .catch(err => console.log(err));

// Cancel the timeout
controller.abort();

Advanced Techniques

1. Integration with React Custom Hooks

function useAbortableFetch() {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(false);
  const controllerRef = useRef(null);

  const fetchData = async (url) => {
    if (controllerRef.current) {
      controllerRef.current.abort();
    }

    controllerRef.current = new AbortController();
    setLoading(true);

    try {
      const response = await fetch(url, { 
        signal: controllerRef.current.signal 
      });
      const result = await response.json();
      setData(result);
    } catch (err) {
      if (err.name !== 'AbortError') {
        setError(err);
      }
    } finally {
      setLoading(false);
    }
  };

  const abort = () => {
    if (controllerRef.current) {
      controllerRef.current.abort();
    }
  };

  return { data, error, loading, fetchData, abort };
}

2. Usage with Web Workers

// Main thread
const controller = new AbortController();
const worker = new Worker('worker.js');

worker.postMessage({ 
  signal: controller.signal,
  task: 'heavyComputation'
});

// To abort
controller.abort();

// worker.js
self.onmessage = function(e) {
  const { signal, task } = e.data;

  if (signal) {
    signal.addEventListener('abort', () => {
      // Clean up resources
      self.close();
    });
  }

  // Execute task
};

Best Practices

Error Handling: Always check error types in catch blocks to distinguish between operation cancellation and other errors.
Resource Cleanup: Use the 'abort' event to release resources when canceling operations.
Controller Reusability: Create a new AbortController for each operation rather than reusing a single controller for multiple independent operations.
Browser Support: Verify AbortController support in target browsers or include polyfills when necessary.

Polyfills and Compatibility

While AbortController is supported in all modern browsers, you can use polyfills for older environments:

import 'abortcontroller-polyfill/dist/abortcontroller-polyfill-only';

Conclusion

AbortController provides developers with a powerful mechanism for managing asynchronous operations, improving both user experience and application efficiency. It's particularly valuable for scenarios involving long-running requests where users might need to cancel operations or when components unmount before requests complete.

CSS Transforms and Transitions: Bringing Motion to the Web

Maxim Logunov — Fri, 25 Jul 2025 19:25:35 +0000

Introduction

Modern web design isn’t just about static layouts—it’s about creating engaging, interactive experiences. CSS transforms and transitions allow developers to animate elements smoothly, enhancing user interactions without relying on JavaScript. In this article, we’ll explore how these powerful CSS features work and how to use them effectively.

CSS Transforms: Reshaping Elements

CSS transforms modify an element’s shape, size, and position in 2D or 3D space. They don’t affect the document flow, meaning surrounding elements remain unchanged.

Common Transform Functions

Translate() – Moves an element along the X and Y axes.

   .box {
     transform: translate(50px, 20px);
   }

Rotate() – Spins an element by a specified angle.

   .box {
     transform: rotate(45deg);
   }

Scale() – Resizes an element.

   .box {
     transform: scale(1.5); /* 1.5 times its original size */
   }

Skew() – Tilts an element along the X or Y axis.

   .box {
     transform: skew(20deg, 10deg);
   }

3D Transforms – Adds depth with functions like rotateX(), rotateY(), and translateZ().

CSS Transitions: Smooth Animations

While transforms change an element’s appearance, transitions control how those changes happen over time. They allow animations to occur smoothly instead of instantly.

Transition Properties

To create a transition, define:

transition-property – Which CSS property to animate (e.g., transform, opacity).
transition-duration – How long the animation lasts (e.g., 0.5s).
transition-timing-function – The speed curve (e.g., ease-in, linear).
transition-delay – Optional delay before the animation starts.

Example: Hover Effect with Transition

.button {
  background: blue;
  transition: background 0.3s ease, transform 0.2s;
}

.button:hover {
  background: darkblue;
  transform: scale(1.1);
}

This makes the button darken and grow slightly when hovered, with a smooth transition.

Combining Transforms and Transitions

Used together, these features create engaging animations. For example:

.card {
  transition: transform 0.5s ease;
}

.card:hover {
  transform: rotate(5deg) scale(1.05);
}

This gives a subtle 3D-like tilt and zoom effect on hover.

Best Practices

Performance – Prefer transform and opacity for animations (they’re GPU-accelerated).
Subtlety – Avoid excessive motion; smooth, small animations often work best.
Fallbacks – Ensure usability if animations are disabled (e.g., via prefers-reduced-motion).

Conclusion

CSS transforms and transitions open up a world of creative possibilities, from simple hover effects to complex animations—all with minimal code. By mastering these tools, you can make your websites more dynamic and interactive while keeping performance smooth.

Experiment with different transforms and transitions to see what works best for your designs! 🚀

Ultimate Guide to CSS Pseudo-Classes and Pseudo-Elements

Maxim Logunov — Thu, 24 Jul 2025 19:11:25 +0000

Pseudo-classes (:pseudo-class) and pseudo-elements (::pseudo-element) are powerful CSS tools that allow you to style elements based on their state or position in the DOM. This comprehensive guide covers all major pseudo-classes and pseudo-elements with practical examples and explanations.

1. Pseudo-Classes

Pseudo-classes select elements in specific states.

1.1. Link and Interaction States

Pseudo-Class	Example	Description
`:link`	`a:link { color: blue; }`	Unvisited links
`:visited`	`a:visited { color: purple; }`	Visited links
`:hover`	`button:hover { background: #eee; }`	Element on mouse hover
`:active`	`a:active { color: red; }`	Element being clicked
`:focus`	`input:focus { border-color: blue; }`	Focused form element

1.2. Form States

Pseudo-Class	Example	Description
`:checked`	`input:checked { accent-color: green; }`	Checked checkboxes/radio buttons
`:disabled`	`input:disabled { opacity: 0.5; }`	Disabled form elements
`:enabled`	`input:enabled { border: 1px solid #ccc; }`	Enabled form elements
`:valid`	`input:valid { border-color: green; }`	Valid form input
`:invalid`	`input:invalid { border-color: red; }`	Invalid form input
`:placeholder-shown`	`input:placeholder-shown { color: gray; }`	Input showing placeholder text

1.3. Structural and Positional

Pseudo-Class	Example	Description
`:first-child`	`li:first-child { font-weight: bold; }`	First child element
`:last-child`	`li:last-child { border-bottom: none; }`	Last child element
`:nth-child(n)`	`tr:nth-child(odd) { background: #f5f5f5; }`	Elements matching position (even, odd, formulas)
`:first-of-type`	`p:first-of-type { font-size: 1.2em; }`	First element of its type
`:last-of-type`	`p:last-of-type { margin-bottom: 0; }`	Last element of its type
`:empty`	`div:empty { display: none; }`	Empty elements (no children)
`:not()`	`div:not(.hidden) { display: block; }`	Elements not matching selector

2. Pseudo-Elements

Pseudo-elements style specific parts of elements or generate content.

Pseudo-Element	Example	Description
`::before`	`p::before { content: "→ "; }`	Inserts content before element
`::after`	`button::after { content: " »"; }`	Inserts content after element
`::first-letter`	`p::first-letter { font-size: 2em; }`	Styles first letter of text
`::first-line`	`p::first-line { font-weight: bold; }`	Styles first line of text
`::selection`	`::selection { background: yellow; }`	Styles selected text
`::placeholder`	`input::placeholder { color: #999; }`	Styles placeholder text
`::marker`	`li::marker { color: red; }`	Styles list markers

3. Practical Examples

3.1. Styling Lists

/* Alternate row colors */
li:nth-child(even) {
  background: #f9f9f9;
}

/* Drop-cap effect */
p::first-letter {
  font-size: 1.5em;
  color: darkblue;
}

3.2. Interactive Buttons

button {
  padding: 10px 20px;
  transition: background 0.3s;
}

button:hover {
  background: #ddd;
}

button:active {
  transform: scale(0.98);
}

3.3. Custom Checkboxes

input[type="checkbox"]:checked + label {
  font-weight: bold;
  color: green;
}

4. Key Takeaways

Pseudo-classes and pseudo-elements enable you to:
✅ Create dynamic, state-dependent styles

✅ Precisely target elements by DOM position

✅ Add decorative elements without extra HTML

Bookmark this cheat sheet to build more interactive and stylish interfaces! 🚀

The New Cookie Store API: Modern Cookie Management for the Web

Maxim Logunov — Mon, 21 Jul 2025 18:57:08 +0000

Introduction

For decades, web developers have relied on the document.cookie interface to manage cookies in browsers. While functional, this API has always been clunky and limited. Enter the new Cookie Store API - a modern, promise-based interface that provides a more powerful and intuitive way to work with cookies in web applications.

What is the Cookie Store API?

The Cookie Store API is a new JavaScript API that offers a better way to read and write cookies compared to the traditional document.cookie approach. It's designed to address several limitations of the old method while adding new capabilities that are essential for modern web development.

Key Features and Benefits

1. Promise-based Interface

Unlike document.cookie which operates synchronously, the Cookie Store API uses promises, making it work seamlessly with modern asynchronous JavaScript code.

// Writing a cookie
await cookieStore.set({
  name: "session_id",
  value: "12345",
  expires: Date.now() + 24 * 60 * 60 * 1000, // 1 day
  domain: "example.com"
});

// Reading a cookie
const sessionCookie = await cookieStore.get("session_id");
console.log(sessionCookie.value);

2. Better Error Handling

The API provides proper error handling through rejected promises rather than silent failures.

3. Full Cookie Metadata Access

You can access all cookie attributes (domain, path, expiration, etc.) not just the name-value pairs.

const allCookies = await cookieStore.getAll();
allCookies.forEach(cookie => {
  console.log(`Name: ${cookie.name}, Secure: ${cookie.secure}`);
});

4. Cookie Change Events

Subscribe to notifications when cookies are set or deleted.

cookieStore.addEventListener('change', (event) => {
  event.changed.forEach(cookie => {
    console.log(`Cookie changed: ${cookie.name}`);
  });
  event.deleted.forEach(cookie => {
    console.log(`Cookie deleted: ${cookie.name}`);
  });
});

5. Service Worker Support

The API works in both window contexts and service workers, enabling better offline/PWA cookie management.

// In a service worker
self.addEventListener('fetch', (event) => {
  if (event.request.url.includes('auth')) {
    event.respondWith(
      cookieStore.get('session_token')
        .then(cookie => {
          if (!cookie) {
            return new Response('Unauthorized', { status: 401 });
          }
          return fetch(event.request);
        })
    );
  }
});

Browser Support and Availability

As of 2023, the Cookie Store API is supported in:

Chrome 87+ (fully supported)
Edge 87+
Opera 73+
Firefox 140+
Safari 18.4+

You can check for API availability with:

if ('cookieStore' in window) {
  // API is available
}

Migration from document.cookie

Here's how common operations translate between the old and new APIs:

Operation	document.cookie	Cookie Store API
Set cookie	`document.cookie = "name=value; expires=..."`	`await cookieStore.set({name, value, expires})`
Get cookie	Parse `document.cookie` string	`await cookieStore.get(name)`
Get all cookies	Parse `document.cookie` string	`await cookieStore.getAll()`
Delete cookie	Set expiration in past	`await cookieStore.delete(name)`

Security Considerations

The Cookie Store API follows the same security restrictions as document.cookie:

You can only access cookies for the current domain
Secure cookies (with HttpOnly flag) are still not readable via JavaScript
The API respects same-origin policy and cookie permission settings

Use Cases

Authentication flows: More robust handling of session cookies
Analytics: Better management of tracking consent cookies
Feature flags: Easier management of feature toggle cookies
PWAs: Cookie management in service workers
Real-time updates: Reacting to cookie changes without polling

Conclusion

The Cookie Store API represents a significant improvement over the venerable but limited document.cookie interface. With its promise-based design, comprehensive metadata access, and change notifications, it provides web developers with the tools needed for proper cookie management in modern web applications.

While browser support is not yet universal, the API is worth adopting in compatible environments and can be polyfilled or feature-detected for graceful fallbacks. As the web platform continues to evolve, APIs like this demonstrate how even fundamental capabilities are being modernized for today's development needs.

For more information, check out the W3C specification and MDN documentation.

DEV Community: Maxim Logunov

Mastering the Orchestration Pattern in React: Taming Complex Component Logic

The Problem: When React Components Become Spaghetti

What Is the Orchestration Pattern in React?

A Simple Orchestration Pattern Implementation

Step 1: Define the Orchestrator Hook

Step 2: Consume the Orchestrator in Components

Benefits of the Orchestration Pattern

1. Separation of Concerns

2. Testability

3. Reusability

4. Observability

When to Use Orchestration (and When Not To)

✅ Great Use Cases:

❌ Overkill For:

Best Practices

Conclusion

Controlled vs. Uncontrolled Components in React: A Practical Guide

What Are Controlled Components?

What Are Uncontrolled Components?

Key Differences at a Glance

When to Use Controlled Components

1. Immediate Validation and Feedback

2. Conditional Form Logic

3. Complex Form State Management

4. Dynamic Form Generation

When to Use Uncontrolled Components

1. Performance-Critical Forms

2. File Inputs

3. Simple Forms with No Validation

4. Integrating with Non-React Libraries

Hybrid Approach: The Best of Both Worlds

Modern Solutions: Form Libraries

Best Practices and Recommendations

Conclusion

TypeScript Enums Showdown: `const enum` vs `enum` vs `object as const`

Introduction

1. Regular Enums (enum)

Pros:

Cons:

2. Const Enums (const enum)

Pros:

Cons:

3. Object with as const

Pros:

Cons:

Comparative Analysis

Bundle Size Impact

Runtime Performance

Type Safety

Practical Examples

Scenario 1: API Response Handling

Scenario 2: Internal Constants

Scenario 3: Public Library API

Migration Example

Decision Guide

Best Practices

Conclusion

Advanced React Refs: Mastering the Callback Pattern

What is a Ref Callback?

Key Use Cases and Benefits

1. Dynamic Ref Handling for Lists

2. Abstracting Reusable Logic with Custom Hooks

3. Triggering Logic Directly on Mount/Unmount

Important Caveats and Best Practices

Conclusion

Updating State Based on Previous State in React

The Problem with Direct State Updates

The Solution: Functional State Updates

When Functional Updates Are Essential

1. Multiple State Updates

2. Async State Updates

3. Complex State Objects

Class Components and setState

Performance Considerations

Conclusion

Understanding `event.target` and `event.currentTarget` in JavaScript

What Are These Properties?

A Practical Example

When to Use Each Property

1. Regular Enums (`enum`)

2. Const Enums (`const enum`)

3. Object with `as const`

Use `event.target` when:

Use `event.currentTarget` when:

What is `dangerouslySetInnerHTML`?

Risks of Using `dangerouslySetInnerHTML`

When to Avoid `dangerouslySetInnerHTML`

1. `flushSync` for Immediate Updates

2. `unstable_batchedUpdates` for Legacy Code