DEV Community: Sambalicious

Type-Safe Compound Components in 2026 – The Generic Factory Pattern I Actually Use

Sambalicious — Sat, 07 Feb 2026 11:05:40 +0000

How I finally got real type safety on children values without losing the beautiful dot API

Compound components are awesome for building flexible UI primitives — think <Tabs>, <Accordion>, <RadioGroup>, or <Popover> — where the consumer controls the layout and composition.

But flexibility often meant zero type safety on children or values.

I used to write stuff like this:

<RadioGroup value={selected} onChange={setSelected}>
  <RadioItem value="draft">Draft</RadioItem>
  <RadioItem value="published">Published</RadioItem>
  <RadioItem value={123}>Wait what? {/* ← TypeScript is silent 😭 */}
</RadioItem>
</RadioGroup>

I wanted TypeScript to actually yell at me when the value type was wrong, while keeping the clean dot-notation DX everyone loves:

<StatusRadio.RadioGroup value={status} onValueChange={setStatus}>
  <StatusRadio.RadioItem value="draft">...</StatusRadio.RadioItem>
  {/* value={123} → red squiggle! */}
</StatusRadio.RadioGroup>

After reading TkDodo’s excellent post “Building Type-Safe Compound Components” (Jan 2, 2026), I extended the ideas into a tiny generic factory. It’s now my go-to for typed item groups (radios, tabs, segmented controls, steppers…).

Two Flavors of Compound Components

Max layout freedom (Card/Dialog style) Free-form children, arbitrary order:

<Card>
  <CardHeader>Title</CardHeader>
  <CardContent>Anything goes</CardContent>
  <CardFooter>Actions</CardFooter>
</Card>

→ Use simple context + sub-components. Super common in shadcn/ui, Radix, etc. (Not the focus here).

Strict typed children (Radio/Tabs/Steps style) Predictable items + strong value typing — factory time!

type Status = "draft" | "published" | "archived";

const StatusRadio = createTypedRadioGroup<Status>();

<StatusRadio.RadioGroup value={status} onValueChange={setStatus}>
  <StatusRadio.RadioItem value="draft">
    <StatusRadio.RadioIndicator />
    Draft
  </StatusRadio.RadioItem>
  {/* value={123} → compile error */}
</StatusRadio.RadioGroup>

The Reusable Factory Pattern

import { createContext, useContext } from "react";
import {
  RadioGroup as BaseRadioGroup,
  Radio,
  mergeProps,
} from "@base-ui/react";
import { radioGroupRootVariants, radioItemVariants, RadioIndicator } from "../ui/radio";

type RadioGroupContextValue = {
  size?: "sm" | "md" | "lg" | null;
  variant?: "default" | "outline" | null;
};

export function createTypedRadioGroup<T>() {
  const RadioGroupContext = createContext<RadioGroupContextValue | null>(null);

  function TypedRadioGroup({
    size,
    variant,
    orientation,
    className,
    children,
    ...props
  }: Omit<React.ComponentProps<typeof BaseRadioGroup>, "children" | "className"> & {
    size?: "sm" | "md" | "lg";
    variant?: "default" | "outline";
    orientation?: "horizontal" | "vertical";
    className?: string;
    children: React.ReactNode;
  }) {
    const ctxValue = { size: size ?? null, variant: variant ?? null };

    return (
      <RadioGroupContext.Provider value={ctxValue}>
        <BaseRadioGroup
          className={radioGroupRootVariants({ size, orientation })}
          {...props}
        >
          {children}
        </BaseRadioGroup>
      </RadioGroupContext.Provider>
    );
  }

  function TypedRadioItem({
    value,
    size: itemSize,
    className,
    children,
    ...props
  }: { value: T; size?: "sm" | "md" | "lg" } & Omit<
    React.ComponentProps<typeof Radio.Root>,
    "value" | "children"
  >) {
    const context = useContext(RadioGroupContext);
    if (!context) {
      throw new Error("RadioItem must be used inside RadioGroup");
    }

    const finalSize = itemSize ?? context.size ?? "md";

    const merged = mergeProps({ className }, {
      className: radioItemVariants({ size: finalSize }),
    });

    // Adapt value to string/number as needed by your base library
    return (
      <Radio.Root value={String(value)} className={merged.className} {...props}>
        {children}
      </Radio.Root>
    );
  }

  return {
    RadioGroup: TypedRadioGroup,
    RadioItem: TypedRadioItem,
    RadioIndicator,
  } as const;
}

Note: If your headless base (Radix/Ark/Base UI) supports generic values natively, drop the String(value) cast.

Real-World Examples:

Status Picker (string literals)

type Status = "draft" | "published" | "archived";

const StatusRadio = createTypedRadioGroup<Status>();

export function StatusPicker() {
  const [status, setStatus] = useState<Status>("draft");

  return (
    <StatusRadio.RadioGroup
      value={status}
      onValueChange={setStatus}
      size="md"
      variant="default"
    >
      <StatusRadio.RadioItem value="draft">
        <StatusRadio.RadioIndicator />
        Draft
      </StatusRadio.RadioItem>
      <StatusRadio.RadioItem value="published">
        <StatusRadio.RadioIndicator />
        Published
      </StatusRadio.RadioItem>
      <StatusRadio.RadioItem value="archived">
        <StatusRadio.RadioIndicator />
        Archived
      </StatusRadio.RadioItem>
    </StatusRadio.RadioGroup>
  );
}

Star Rating (numbers)

const RatingRadio = createTypedRadioGroup<number>();

<RatingRadio.RadioGroup value={rating} onValueChange={setRating} orientation="horizontal">
  {[1, 2, 3, 4, 5].map((n) => (
    <RatingRadio.RadioItem key={n} value={n}>
      <RatingRadio.RadioIndicator />
      {n} ★
    </RatingRadio.RadioItem>
  ))}
</RatingRadio.RadioGroup>

Object-based (real-world use case)

interface Option {
  id: string;
  label: string;
  description: string;
}

const OptionRadio = createTypedRadioGroup<Option>();

export function OptionPicker() {
  const options: Option[] = [
    { id: "1", label: "Option 1", description: "First option" },
    { id: "2", label: "Option 2", description: "Second option" },
    { id: "3", label: "Option 3", description: "Third option" },
  ];

  const [selected, setSelected] = useState<Option>(options[0]);

  return (
    <OptionRadio.RadioGroup value={selected} onValueChange={setSelected}>
      {options.map((option) => (
        <OptionRadio.RadioItem key={option.id} value={option}>
          <OptionRadio.RadioIndicator />
          <div>
            <div className="font-medium">{option.label}</div>
            <div className="text-sm text-gray-500">{option.description}</div>
          </div>
        </OptionRadio.RadioItem>
      ))}
    </OptionRadio.RadioGroup>
  );
}

Trade-offs – When to Use (or Skip) This
Use the factory when:

Strong value type safety is non-negotiable
Children order is predictable (list/group items)
You want that sweet dot-notation DX

Skip it (use plain context + sub-components) when:

1. You need a completely free-form layout/order
2. Building low-level primitives (just use Radix/Ark/Base UI directly)

Final Thoughts
This little factory has been my default for typed groups since 2026 simple, type-safe, minimal boilerplate.
Ideas to level it up:

Propagate disabled from group → items

Add defaultValue support
Generalize for <Tabs>, <Accordion>, <RadioGroup> etc.
Package it as a tiny npm lib

Steal it, tweak it, ship with it.
What’s your go-to pattern for typed compound components in 2026? Drop a comment — or hit me up on X: @sambalicious_ 🚀

Scalable Notifications in React with Pub/Sub (No State Store)

Sambalicious — Thu, 29 Jan 2026 20:44:41 +0000

Recently, I needed to add a flexible, scalable notification system to a large-scale React/Next.js application. The backend provided a handy endpoint that returns all pending notifications at once. My initial thought was simple: fetch them globally and render a single Notification component that switches UI based on the notification type.

Quickly, two problems emerged:

The endpoint could return multiple notifications at once—how do I handle queuing and displaying them without chaos?
For custom notification types (e.g., interactive modals, special banners), the single component would become bloated with conditionals and logic.

After some research, I landed on a classic design pattern perfectly suited for this: Publisher/Subscriber (Pub/Sub).

What is Pub/Sub?

Pub/Sub is an asynchronous messaging pattern that decouples the message sender (Publisher) from the receivers (Subscribers). Publishers broadcast events to a central event bus (or broker) without knowing who (if anyone) is listening. Subscribers register interest in specific event types and react only when relevant messages arrive.

It’s like a radio station: the broadcaster sends signals blindly, and anyone tuned to the right frequency picks them up.

The publisher sends messages to the topic without knowing who will receive them through a broker (Event bus) to subscribers, who receive only relevant messages that they subscribed to. This pattern allows for independent, asynchronous component operation.

Core Principles & Benefits

Loose Coupling: Publishers and subscribers don’t know about each other—no direct imports or references. They are not directly connected and do not need to know each other's identities or locations.
Scalability: Easily add more subscribers to a topic as your app grows; the bus handles distribution. The system can handle a large volume of events by adding more subscribers without impacting performance.
Asynchronous Communication: Publishers fire events and move on—no waiting for responses. They can send messages and continue their work without blocking.
Many-to-Many Relationships: One publisher can reach many subscribers, and one subscriber can listen to many publishers.

When to Use It in React/Next.js

Pub/Sub is ideal for fire-and-forget events like notifications, analytics tracking, theme changes, or global modals. Avoid it for complex shared state—use Zustand, Redux, Jotai, or Context instead.

Implementation: Lightweight Notification Event Bus

Let’s build it step by step.

1. The Event Bus

type EventKey = "Login" | "Registration" | "PasswordReset"; // Extend with your notification types

const listeners = new Map<string, Set<(...args: unknown[]) => void>>();

export const notificationEventBus = {
  subscribe: (eventKey: EventKey, callback: (...args: unknown[]) => void) => {
    if (!listeners.has(eventKey)) {
      listeners.set(eventKey, new Set());
    }
    listeners.get(eventKey)?.add(callback);

    // Return unsubscribe function
    return () => {
      listeners.get(eventKey)?.delete(callback);
    };
  },

  publish: (eventKey: EventKey, payload: unknown) => {
    const callbacks = listeners.get(eventKey);
    if (!callbacks) return;

    callbacks.forEach((cb) => {
      try {
        cb(payload);
      } catch (error) {
        console.error(
          `Error in notificationEventBus subscriber for event "${String(eventKey)}". Check the implementation of this subscriber to handle the error appropriately.`,
          error,
        );
      }
    });
  },
};

// Helper function to publish all notifications at once
export const publishNotifications = (
  notifications: NotificationData<PopupNotificationDetails>[],
) => {
  notifications.forEach((notification) => {
    notificationEventBus.publish(notification.type, notification);
  });
};

(Note: NotificationData and PopupNotificationDetails are placeholders—define them based on your notification structure, e.g., { type: EventKey; message: string; }.)

2. React Hook for Safe Subscriptions

"use client";

import { useEffect, useRef } from "react";

import type { EventKey } from "@soar/types"; // Adjust import based on your types

import { notificationEventBus } from "../helpers";

export const useNotificationEvent = <T = unknown>(
  eventKey: EventKey,
  handler: (data: T) => void,
) => {
  const handlerRef = useRef(handler);

  // Keep handler up-to-date without re-subscribing
  useEffect(() => {
    handlerRef.current = handler;
  });

  useEffect(() => {
    const stableHandler = (data: unknown) => {
      handlerRef.current(data as T);
    };

    const unsubscribe = notificationEventBus.subscribe(
      eventKey,
      stableHandler as (...args: unknown[]) => void,
    );

    return () => {
      unsubscribe();
    };
  }, [eventKey]);
};

3. Usage Example: Listening for a Specific Notification

useNotificationEvent("OrderDelivered", (notification) => {
  // Do whatever with the notification, e.g., show a toast or modal
});

4. Fetch and Publish Notifications in Your Component

// Example: Fetch and publish
// For one-time fetch; use polling or WebSockets for real-time.
useEffect(() => {
  fetch("/api/notifications")
    .then((res) => res.json())
    .then((notifications) => {
      publishNotifications(notifications); // Your helper function
    });
}, []);

Real-World Tips

Multiple Notifications: Publish per type—each subscriber handles its own UI cleanly.
Custom Notifications: Create dedicated subscriber components instead of one giant switch statement.

Conclusion

Pub/Sub gave me exactly what I needed: decoupled, scalable notifications without bloating components or pulling in heavy state management. It’s simple, performant, and easy to reason about.

Try it in your Next.js/React app—start with this event bus and hook, then expand to toasts, modals, or analytics. I made a little POC for this; fork the code and tweak it! Let me know how it works for you. 🚀

Questions or improvements? Hit me up on X: @sambalicious_