DEV Community: Talisson

BulkActionsBar - Part 2 - Engineering a Robust and Accessible Bulk Actions Bar in React

Talisson — Fri, 12 Sep 2025 01:40:10 +0000

In Part 1, we explored how micro-interactions elevate the user experience of a Bulk Actions Bar. In this article, we’ll dive into the technical engineering challenges that made those interactions possible while ensuring flexibility, performance, and accessibility.

Overflow Detection: Calculating Visible Items

One of the first hurdles was determining how many buttons could fit inline based on container width. CSS alone wasn’t sufficient.

I built a custom hook useVisibleChildrenCount using ResizeObserver to dynamically calculate the number of visible items:

export function useVisibleChildrenCount({ containerEl, isEnabled, gap = 0 }) {
  const [visibleCount, setVisibleCount] = useState(0)

  const measureVisibleItems = useCallback(() => {
    if (!containerEl) return

    const childrenEls = Array.from(containerEl.children).filter(
      (el) => el instanceof HTMLDivElement
    )

    let totalWidth = 0
    let fitCount = 0

    for (let i = 0; i < childrenEls.length; i++) {
      const childWidth = childrenEls[i].offsetWidth
      const spaceRequired = totalWidth === 0 ? childWidth : childWidth + gap

      if (totalWidth + spaceRequired <= containerEl.offsetWidth) {
        totalWidth += spaceRequired
        fitCount += 1
      } else {
        break
      }
    }

    setVisibleCount(fitCount)
  }, [containerEl, gap])

  useEffect(() => {
    if (!isEnabled || !containerEl) return

    const observer = new ResizeObserver(() => {
      window.requestAnimationFrame(measureVisibleItems)
    })

    observer.observe(containerEl)
    measureVisibleItems()

    return () => observer.disconnect()
  }, [containerEl, isEnabled, measureVisibleItems])

  return isEnabled ? visibleCount : containerEl?.children.length || 0
}

This hook allowed the component to adapt in real-time as container dimensions changed.

The Dropdown Menu: Desktop vs Mobile Submenus

Calendly uses react-aria-components for accessible menus. Handling nested submenus that behave differently on desktop and mobile introduced challenges:

MenuTrigger/MenuContent structure is rigid.
Mobile submenus needed to stack as overlays.
Submenu depth was dynamic and recursive.

Attempt #1: Portal in Dropdown Item

In our first approach, we tried rendering submenus into a portal placed inside the dropdown menu item itself. The idea was to leverage a portal to visually stack submenus while keeping the parent menu open. However, React Aria’s strict DOM structure and focus management expectations made this unfeasible, as it broke assumptions about where menu content should exist in the hierarchy.

Attempt #2: Root Content Replacement with Stack State

The final solution was to manage a submenu stack state within MenuContent, where the active submenu would replace the root content entirely. On mobile, when a submenu is triggered, we swapped the root content node with the submenu node, simulating a page stack experience. This allowed us to preserve React Aria’s accessibility features while giving us full control over the submenu transitions.

Center Alignment with Side Navigation Constraints

Calendly’s main product has a persistent left sidebar, which shifted the content area. My initial implementation of the BulkActionsBar was viewport-centered, which appeared misaligned.

To fix this, we adopted an “Outlet Pattern”:

Render a wrapper Outlet component aligned to the main content area.
Pass a ref to this Outlet.
Use a portal strategy to render the BulkActionsBar into this outlet.

This approach ensured visual alignment regardless of sidebar presence.

Recursive Submenus Handling

Managing recursive submenus required handling focus, depth stacking, and keyboard navigation without assumptions on submenu levels. I designed a recursive rendering strategy that adapted based on context:

On desktop: inline flyouts.
On mobile: stacked overlays.

Keyboard focus was managed dynamically, ensuring a seamless navigation experience across varying depths.

Lessons Learned

Small UI components can introduce significant architectural considerations.
Design system constraints demand flexible yet robust engineering solutions.
Accessibility cannot be an afterthought—it's foundational to component architecture.

Conclusion

Engineering a flexible BulkActionsBar required a blend of creative problem-solving and meticulous attention to UX and accessibility details. It exemplifies how thoughtful component design goes beyond visual styling, intersecting architecture, user flows, and real-world product constraints.

References:

Special thanks to the Calendly Design Systems Team for the collaborative ideation and problem-solving sessions that made this component possible.

BulkActionBar - Part 1 - The UX Micro-Interactions that Make Bulk Actions Feel Intuitive

Talisson — Fri, 12 Sep 2025 01:39:50 +0000

Designing a seemingly simple Bulk Actions Bar can quickly become a complex UX challenge. From handling responsive layouts and overflow items to ensuring smooth user interactions, every detail matters. This article focuses on the micro-interactions and refinements that turned a functional component into a delightful user experience.

The Problem Statement

The task was to build a BulkActionsBar component to support bulk action workflows in Calendly's design system. Core behaviors included:

Showing or hiding the bar based on selection state.
Displaying or hiding the “selected” label on different viewports.
Managing overflow items into a “More Options” dropdown.

While these interactions seem simple, they are crucial in keeping users informed and the interface clean.

Simple Interactions, Big UX Value

At first glance, behaviors like showing/hiding the bar or toggling the “selected” label visibility might appear trivial. However, they play a significant role in maintaining clarity during user workflows.

For example:

Bar Appearance: When the BulkActionsBar appears, it slides up from the bottom, making its entrance noticeable and purposeful.
Label Responsiveness: The “selected” label is hidden on mobile devices to maximize space, keeping the interface focused.

These interactions guide the user’s attention and provide a sense of continuity as the UI adapts.

Overflow Items and the “More Options” Menu

Managing overflow actions through a “More Options” dropdown may sound easy but comes with subtle challenges:

Users need a visual cue when actions move into the dropdown.
Disappearing buttons without context can cause confusion.

To address this, I added smooth sliding animations for buttons as they overflow into the menu, giving users a clear indication of where their actions went. Additionally, the “More Options” button subtly pulses when new actions are added to it, signaling an update without overwhelming the user.

Developer-Driven Refinements Beyond the Design Spec

Many of these micro-interactions were not explicitly defined in the original design spec. They emerged from observing gaps in the user flow during development. For instance:

The shimmer effect on the “More Options” button was introduced to bridge the interaction gap when items overflowed.
The bar’s mount/unmount animation was added to avoid abrupt UI changes.

These refinements highlight the importance of proactive UX thinking during development, ensuring the component feels intuitive and polished.

Conclusion

What seems like small visual details often carries a big impact on user experience. By focusing on micro-interactions like smooth transitions, responsive visibility adjustments, and subtle feedback cues, the BulkActionsBar transformed from a functional component into an intuitive UX element.

In Part 2, we’ll dive into the technical challenges behind making this bar flexible, responsive, and accessible across different screen sizes and content contexts.

Linked Lists: The Hidden Power Behind React Hooks

Talisson — Thu, 07 Aug 2025 16:14:01 +0000

When studying computer science, some concepts feel abstract or even irrelevant. One of the most misunderstood? Linked lists [1]. Many developers leave college thinking, "I'll never use this in real life." But what if I told you that every time you use React Hooks, you're relying on a linked list?

Let’s explore how.

What Is a Linked List?

A linked list is a fundamental data structure where each element (called a node) holds a value and a reference to the next node. Unlike arrays, which store elements contiguously in memory, linked lists form a chain of nodes, allowing for efficient insertions and removals, especially for dynamic or unknown sizes [1].

Here’s a simple example of a linked list node in JavaScript:

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

// Example: Creating a linked list
const node1 = new Node(1);
const node2 = new Node(2);
node1.next = node2; // Links node1 to node2

This flexibility makes linked lists ideal for scenarios where data needs to grow or shrink dynamically.

The Problem React Needed to Solve

When React introduced Hooks, it faced a challenge:

How do we track multiple hooks inside a single component without requiring developers to name or manage them explicitly?

React’s solution was to rely on call order, storing hook states in a singly linked list attached to the component’s internal structure. Linked lists are perfect here because they allow React to efficiently append new hooks without resizing or shifting elements, unlike arrays.

Hooks as a Linked List

In React, each component has a Fiber node that manages its state. Hooks are stored as nodes in a singly linked list, anchored to the Fiber’s memoizedState property. Here’s a simplified view:

Component Fiber
   |
   └── memoizedState → Hook1 → Hook2 → Hook3 → null

Each hook node contains:

{
  memoizedState: someStateValue, // The hook's current state
  next: referenceToNextHook,      // Pointer to the next hook
}

When React renders a component, it traverses this list in the exact order the hooks are called. This is why hooks cannot be called conditionally [2]—it would disrupt the list’s structure. For example:

// Bad: Conditional hook call breaks the linked list
if (condition) {
  const [value, setValue] = useState(0); // React loses track of hook order
}

Breaking this rule can cause errors like "Rendered more hooks than during the previous render," as React relies on consistent hook order across renders [2].

Inside React’s Codebase

Curious to see this in action? Check out React’s source code on GitHub, specifically the mountWorkInProgressHook function [3]. This function creates a new hook and links it to the list during the initial render:

// React adds a new hook to the linked list
if (workInProgressHook === null) {
  // First hook in the list
  firstWorkInProgressHook = workInProgressHook = hook;
} else {
  // Append to the end of the linked list
  workInProgressHook = workInProgressHook.next = hook;
}

On subsequent renders, React reuses this list, ensuring hooks are processed in the same order.

Why This Matters for Frontend Developers

You may not think about linked lists when building UIs, but understanding their role in React can give you an edge:

Write better custom hooks: Knowing hooks are stored in a linked list helps you design hooks that respect React’s order-based system.
Avoid subtle bugs: Misordering hooks (e.g., calling them in loops or conditionals) can break your app. Use React DevTools to inspect the hook chain and debug order-related issues [4].
Appreciate React’s elegance: Linked lists enable React to manage dynamic hook counts efficiently, contributing to its performance and simplicity.

Pro Tip: If you suspect a hook-related bug, open React DevTools, select your component, and check the hook order in the Fiber’s memoizedState to ensure consistency [4].

Beyond React: Linked Lists in Frontend Development

Linked lists aren’t just for React. They power features like browser history navigation (e.g., the back/forward stack) and undo/redo functionality in text editors or design tools. Understanding linked lists equips you to tackle a wide range of frontend challenges.

Want to Dive Deeper into React Hooks?

I recently wrote an article exploring the inner workings of Hooks—from linked lists to side effects.

👉 Hooks Under the Hood: How React Hooks Actually Work [5]

Final Thoughts

Linked lists are alive and well, quietly powering your favorite frontend library. The next time someone questions the relevance of data structures, share this insight to show how foundational concepts drive modern development.

Try experimenting with linked lists yourself—build a simple one in JavaScript or explore React’s source code to see them in action. You’ll be surprised at how often they appear!

References

Thanks for reading!

If you found this helpful, follow me @talissoncosta for more frontend deep dives.

Hooks in React 19: Why They Still Matter and What’s New

Talisson — Thu, 07 Aug 2025 00:14:49 +0000

React 19 builds on the foundation of React hooks, introduced in React 16.8, which transformed how developers manage state and side effects in functional components. While hooks remain fundamentally unchanged in their core mechanics, React 19 introduces optimizations and new APIs that enhance their usage. This follow-up to Hooks Under the Hood explores why understanding hooks is still critical, what updates React 19 brings, and how these changes impact your development workflow.

Why Hooks Knowledge Remains Essential

The internal mechanics of hooks—relying on a linked list within a component’s fiber, deterministic call order, and the Rules of Hooks—remain unchanged in React 19. This consistency ensures that your existing knowledge of hooks is still directly applicable. Here’s why deep hooks understanding is still vital:

Debugging and Optimization: Knowing how React tracks hooks via the fiber’s linked list helps diagnose issues like stale closures or unexpected re-renders, especially in complex components leveraging Concurrent Rendering.
Custom Hooks: Building reusable, composable logic with custom hooks requires strict adherence to hook order and dependency management, which React 19’s optimizations don’t alter.
Performance in Concurrent Mode: React 19’s enhanced Concurrent Rendering leans heavily on hooks like useEffect and useTransition to manage rendering interruptions and prioritize updates, making hook lifecycle knowledge critical.
Rules of Hooks: The strict rules (no conditional hooks, no hooks in loops) are enforced as strongly as ever, and breaking them still leads to errors like "Invalid Hook Call."

What’s New in React 19 for Hooks

React 19 introduces several updates that enhance hooks or complement their usage, particularly in the context of Concurrent Rendering and new APIs. Below are the key changes and their implications for hooks:

1. Improved Concurrent Rendering and Hooks

React 19 refines Concurrent Rendering, allowing React to pause, resume, or abandon renders to prioritize urgent updates. This impacts hooks like useEffect and useTransition:

useEffect in Concurrent Rendering: Effects may run multiple times if a render is interrupted and restarted. Understanding the hook linked list and cleanup phase is crucial to avoid unintended side effects. For example:

  useEffect(() => {
    const timer = setInterval(() => console.log('Running'), 1000);
    return () => clearInterval(timer); // Cleanup prevents leaks
  }, []);

In React 19, the cleanup function is guaranteed to run before re-running the effect during interrupted renders, ensuring predictable behavior.

useTransition for Smoother Updates: The useTransition hook, which marks updates as non-urgent, is more prominent in React 19 for managing UI transitions. It integrates seamlessly with the hook system:

  const [isPending, startTransition] = useTransition();
  const handleClick = () => {
    startTransition(() => {
      setCount(count + 1); // Non-urgent update
    });
  };

Understanding useTransition’s place in the hook linked list helps you manage state updates without blocking the UI.

2. New `useActionState` Hook

React 19 introduces the useActionState hook, designed to simplify form handling with actions (part of the new Form Actions API). It combines state management with action execution, reducing boilerplate compared to using useState alone.

Example:

const [state, submit, isPending] = useActionState(async (prevState, formData) => {
  const result = await submitForm(formData);
  return { ...prevState, result };
}, { result: null });

How It Works: useActionState is stored in the same hook linked list as other hooks, maintaining call order. It tracks the action’s state and pending status, similar to useState, but is optimized for server actions and progressive enhancement.
Why It Matters: This hook reduces the need for custom state management logic in forms, but understanding its integration with the fiber’s memoizedState helps debug issues like stale form states.

3. Optimized `useMemo` and `useCallback`

React 19 includes compiler optimizations (via React Compiler) that automatically memoize values and callbacks in many cases, reducing the need for manual useMemo and useCallback. However, these hooks remain relevant:

When to Use: For complex computations or when passing callbacks to unoptimized components, explicit useMemo and useCallback ensure performance.
Under the Hood: These hooks still store memoized values in the hook node’s linked list, with dependencies checked using shallow equality (Object.is), unchanged from React 18.

Example:

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

React 19’s compiler may skip redundant useMemo calls, but understanding dependency arrays ensures predictable behavior when manual memoization is needed.

4. Enhanced `use` Hook

The use hook, introduced in React 18 for reading resources like Promises in Server Components, is now more versatile in React 19. It can be used in more contexts, such as client components, for reading context or awaiting async data.

Example:

const data = use(fetchData()); // Awaits Promise in Server Components

How It Works: use is integrated into the hook linked list like other hooks, storing resolved values or context references. Its flexibility requires careful adherence to the Rules of Hooks to avoid runtime errors.
Why It Matters: Understanding use’s lifecycle helps manage async data flows, especially in mixed server-client rendering scenarios.

Updated Best Practices for Hooks in React 19

Leverage useActionState for Forms: Use this hook to simplify form handling, reducing reliance on multiple useState calls.
Minimize useMemo/useCallback: Rely on React Compiler for automatic memoization, but use these hooks explicitly for critical performance cases.
Handle Concurrent Rendering: Ensure useEffect cleanup functions are robust to handle multiple runs in Concurrent Mode.
Follow Rules of Hooks: Conditional hook calls or incorrect dependency arrays still break the linked list model, causing errors.
Use ESLint Rules: The eslint-plugin-react-hooks package is updated for React 19, catching issues like missing dependencies or invalid use hook usage.

Example: Combining Hooks in React 19

Here’s a practical example combining useActionState and useTransition for a form with smooth updates:

function FormComponent() {
  const [state, submit, isPending] = useActionState(async (_, formData) => {
    const name = formData.get('name');
    await saveName(name);
    return { success: true };
  }, { success: false });

  const [isPendingTransition, startTransition] = useTransition();

  const handleSubmit = (formData) => {
    startTransition(() => {
      submit(formData); // Non-urgent form submission
    });
  };

  return (
    <div>
      <input type="text" name="name" />
      <button disabled={isPending || isPendingTransition}>Submit</button>
      {state.success && <p>Form submitted!</p>}
    </div>
  );
}

This example leverages React 19’s hooks to manage form state and transitions efficiently, relying on the same linked list mechanics under the hood.

Recap: Hooks in React 19

Core Mechanics Unchanged: Hooks still rely on a linked list in the fiber’s memoizedState, enforcing call order and the Rules of Hooks.
New Hooks: useActionState simplifies form handling, while use expands async and context capabilities.
Optimizations: React Compiler reduces manual useMemo/useCallback usage, but explicit calls remain useful.
Concurrent Rendering: Hooks like useEffect and useTransition are critical for managing rendering interruptions.

Want to Dive Deeper?

Final Thoughts

Hooks remain the backbone of functional components in React 19, with their internal linked list model unchanged. New APIs like useActionState and optimizations like React Compiler enhance their power, but understanding their mechanics is still key to writing robust, performant code. By mastering hooks, you’ll navigate React 19’s advancements with confidence and build better applications.

Hooks Under the Hood: How React Hooks Actually Work

Talisson — Wed, 06 Aug 2025 23:10:48 +0000

React hooks revolutionized how we write components, but how well do you really understand what happens when you call useState or useEffect?

This article peels back the abstraction layer to explore how hooks work internally, including the mechanisms React uses to manage them. Whether you're building custom hooks, debugging tricky bugs, or just curious, this deep dive will make you a better React developer.

Why You Should Care

Hooks are not magic. They rely on pure JavaScript, follow strict rules, and depend on a deterministic call order. Understanding these concepts helps you:

Write predictable, bug-free components
Debug strange hook behavior
Build advanced custom hooks with confidence
Understand why the Rules of Hooks exist

The Core Idea

React maintains a linked list of hooks for each component, stored in a "fiber"—React’s internal data structure representing a component during reconciliation. When a component renders, React tracks every hook call in order, using a pointer to manage the list.

Here’s a simplified view of how React tracks hooks:

// Simplified: Represents the fiber's memoizedState linked list
let currentHookIndex = 0;

function useState(initialValue) {
  // Reset index at the start of each render
  if (isNewRender()) currentHookIndex = 0;

  // Get or create hook node
  const hook = hookStore[currentComponent][currentHookIndex] || { state: initialValue };

  const setState = (newValue) => {
    // Support functional updates
    hook.state = typeof newValue === 'function' ? newValue(hook.state) : newValue;
    scheduleRerender(currentComponent); // Batched in real React
  };

  hookStore[currentComponent][currentHookIndex] = hook;
  currentHookIndex++;

  return [hook.state, setState];
}

Key points:

Each hook is tracked by its index in the render cycle.
React expects the number and order of hooks to remain consistent across renders.
State updates are batched for performance, not applied immediately.

How React Tracks Hook Calls

React uses a linked list of hook nodes within each component’s fiber. A fiber is React’s internal representation of a component, used for reconciliation and rendering. Each hook (useState, useEffect, etc.) creates a node in this list.

During a render, React:

Sets the currentlyRenderingFiber.
Resets the workInProgressHook pointer to null.
For each hook call, creates or reuses a node in the linked list.
Stores values like state, effect dependencies, or cleanup functions in the node.

The linked list ensures hooks are processed linearly, matching the order of function calls, while persisting state across renders.

What Happens When You Call `useState`

Consider this code:

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

Under the hood:

React checks the current hook index in the fiber’s memoizedState.
On the first render, it stores the initial value (0) in the hook node.
setCount is a closure that enqueues an update (supporting functional updates like setCount(prev => prev + 1)) and schedules a re-render.
On re-renders, React retrieves the current state from the same node, ignoring the initialValue.

What About `useEffect`

useEffect manages side effects and works differently:

function useEffect(effect, deps) {
  // Get or create the next hook node
  const hook = getNextHook() || { deps: null, cleanup: null };

  // Shallow equality check for dependencies
  const hasChanged = !areDepsEqual(hook.deps, deps);

  if (hasChanged) {
    // Run cleanup before next effect or unmount
    if (hook.cleanup) hook.cleanup();

    // Schedule effect to run after commit phase
    scheduleEffect(() => {
      hook.cleanup = effect(); // Store cleanup function if returned
    });
  }

  hook.deps = deps;
}

// Simplified shallow equality check
function areDepsEqual(oldDeps, newDeps) {
  if (!oldDeps || !newDeps) return false;
  if (oldDeps.length !== newDeps.length) return false;
  return oldDeps.every((dep, i) => Object.is(dep, newDeps[i]));
}

Key points:

React stores the effect callback and dependency array in the hook node.
After the commit phase (post-paint), React compares dependencies using shallow equality (Object.is).
If dependencies change or it’s the first run, React runs the effect.
Cleanup functions (if returned) run before the next effect or when the component unmounts.

Why the Rules of Hooks Matter

React relies on consistent hook call order. Conditional hooks break this model, causing mismatches in the linked list.

Bad:

if (user) {
  useEffect(() => {
    // Breaks hook order
  }, []);
}

Good:

useEffect(() => {
  if (!user) return;
  // Safe conditional logic
}, [user]);

Breaking the Rules of Hooks (e.g., calling hooks conditionally or in loops) leads to errors like "Invalid Hook Call" because React can’t match hook nodes across renders.

Common Pitfalls

Stale Closures: Missing dependencies in useEffect can lead to stale values. Always include all variables used in the effect in the dependency array.
Overusing State: Derived values (e.g., count * 2) don’t always need state. Use computed values when possible to avoid unnecessary renders.
Concurrent Rendering: In Concurrent Mode, React may render components multiple times. The hook linked list ensures state consistency, but be aware of effects running more often.

Custom Hooks Use the Same Mechanism

Custom hooks are just functions that call other hooks:

function useDouble(count) {
  // Note: In practice, `count * 2` could be a computed value unless state is needed
  const [double, setDouble] = useState(count * 2);

  useEffect(() => {
    // Avoid redundant updates
    if (double !== count * 2) {
      setDouble(count * 2);
    }
  }, [count, double]);

  return double;
}

Custom hooks register in the same linked list, following the same call order. This allows nesting but requires adherence to the Rules of Hooks.

Recap: The Lifecycle of a Hook Call

Setup Phase: React prepares the fiber and resets the hook pointer.
Execution Phase: Calls the component function, executing hooks in order.
Tracking: Each hook call is tied to its position in the fiber’s linked list.
Commit Phase: React applies side effects (e.g., from useEffect) after painting.
Re-render: State updates trigger the cycle again, reusing the same hook nodes.

Want to Dive Deeper

Explore these resources:

Final Thoughts

Understanding hooks under the hood isn’t just academic. It equips you to debug issues, optimize performance, and build robust components. By grasping the linked list model, call order, and lifecycle, you’ll write more predictable React code and tackle complex problems with confidence.

Part 3 - Scaling the Outlet Pattern with Multiple Named Outlets in React

Talisson — Mon, 04 Aug 2025 01:15:22 +0000

In Part 1 and Part 2, we explored how the Outlet Pattern allows components to render outside their declaration point using React Portals and a shared context. This works well for a single outlet, but what happens when your layout requires multiple dynamic target areas?

Imagine a dashboard UI with:

A left sidebar for navigation.
A right sidebar for contextual info.
A bottom actions area.

You want components (modals, toolbars, notifications) to render into these zones, regardless of where they’re declared. This is where Named Outlets come into play.

The Problem with Single Outlet Context

The single Outlet context approach falls short when you need:

Multiple, independent outlet areas.
Dynamic component-to-outlet mappings.
Scalable architecture for complex layouts.

Introducing Named Outlets

A Named Outlet Pattern allows components to target specific areas of the layout by name, dynamically rendering into the correct placeholder.

Architecture Overview

NamedOutletProvider — Provides a map of named outlet refs.
NamedOutlet — Placeholder component with a name prop.
useNamedOutlet(name) — Hook to retrieve a specific outlet ref.
createPortal — Components render into the named outlet node.

Implementing Named Outlets

Step 1: Context for Named Outlets

import { createContext, useContext, useRef } from 'react'

const NamedOutletContext = createContext({})

export function useNamedOutlet(name) {
  const outlets = useContext(NamedOutletContext)
  return outlets[name]?.current || null
}

Step 2: NamedOutletProvider

export function NamedOutletProvider({ children }) {
  const outletRefs = useRef({})

  const registerOutlet = (name, ref) => {
    outletRefs.current[name] = ref
  }

  return (
    <NamedOutletContext.Provider value={outletRefs.current}>
      {children}
    </NamedOutletContext.Provider>
  )
}

Step 3: NamedOutlet Placeholder Component

export function NamedOutlet({ name }) {
  const ref = useRef(null)
  const outlets = useContext(NamedOutletContext)

  useEffect(() => {
    outlets[name] = ref
    return () => {
      delete outlets[name]
    }
  }, [name])

  return <div ref={ref} />
}

Step 4: Rendering into a Named Outlet

import { createPortal } from 'react-dom'

export function FloatingButton() {
  const targetNode = useNamedOutlet('bottom-actions')

  if (!targetNode) return null

  return createPortal(
    <button className="floating-button">Click Me</button>,
    targetNode
  )
}

Usage Example

<NamedOutletProvider>
  <Layout>
    <SidebarLeft>
      <NamedOutlet name="left-sidebar" />
    </SidebarLeft>
    <MainContent />
    <SidebarRight>
      <NamedOutlet name="right-sidebar" />
    </SidebarRight>
    <Footer>
      <NamedOutlet name="bottom-actions" />
    </Footer>
  </Layout>

  <FloatingButton />
</NamedOutletProvider>

Benefits of Named Outlets

Supports complex multi-zone layouts.
Components declaratively target a named slot.
Clean separation of layout structure and component behavior.
Scalable as your app grows in layout complexity.

Considerations

Ensure outlets are mounted before trying to render into them.
You may implement a loading/fallback mechanism for optional outlets.
Be cautious with nesting NamedOutletProviders—scoping becomes important.

Conclusion

The Named Outlet Pattern provides a scalable, flexible way to manage complex component placements across multiple layout zones in React applications. By combining React Portals with a dynamic registry of named slots, you gain fine-grained control over layout composition while keeping your component tree clean and declarative.

Part 2 - Applying the Outlet Pattern in Real-World UI Components

Talisson — Mon, 04 Aug 2025 01:11:22 +0000

In Part 1 of this series, we explored the Outlet Pattern — a technique to render components into specific areas of the DOM regardless of where they are declared in the React tree. In this article, we’ll dive into a real-world implementation of this pattern, using a Bulk Actions Bar component as a practical example.

The Scenario

Imagine you’re working on a Design System where a Bulk Actions Bar should appear anchored to a specific layout area (e.g., below a table header) when items are selected. The challenge? The component triggering the bar and the layout placement for the bar are in entirely different parts of the React tree.

This is where the Outlet Pattern becomes invaluable.

Key Components of the Pattern

1. Outlet Placeholder — `BulkActionsBarOutlet`

This component defines the exact DOM location where the Bulk Actions Bar should render.

export const BulkActionsBarOutlet = () => {
  const { bindRef, portalRendered } = useBulkActionsBarContext()

  if (!portalRendered) return null

  return (
    <div data-component="outlet" ref={bindRef} />
  )
}

2. Content Component — `BulkActionsBar`

The Bulk Actions Bar component is rendered outside the layout flow but visually placed inside the Outlet.

if (refBound && portalRef.current) {
  return createPortal(wrappedToolbar, portalRef.current)
}

return wrappedToolbar

3. Context Bridge — `useBulkActionsBarContext`

A context manages the state and references needed for both Outlet and BulkActionsBar to communicate seamlessly.

Why This Pattern Works

Layout Agnosticism: The Bulk Actions Bar can be declared anywhere, but still rendered in the correct visual location.
No Deep Prop Drilling: Components don’t need to pass down placement-related props through multiple layers.
Portal Safety: Gracefully degrades to inline rendering if the Outlet isn’t ready.

Visual Flow

Layout renders the Outlet Placeholder.
The Outlet binds its ref to the context.
The Bulk Actions Bar checks if the Outlet is ready.
When ready, it uses createPortal to render into the Outlet’s DOM node.

Conclusion

The Outlet Pattern is a powerful architectural tool for decoupling component logic from layout structure. In real-world UI components, such as a Bulk Actions Bar, it provides a clean, scalable solution to complex rendering needs without sacrificing declarative React patterns.

In the next part of this series, we’ll explore how to scale this approach to handle multiple named outlets in a design system context.

Part 1 - Rendering Components Outside the DOM Tree with the Outlet Pattern in React

Talisson — Mon, 04 Aug 2025 01:10:49 +0000

When working on complex UI layouts, you often encounter scenarios where a component must render in a different part of the DOM tree than where it is declared. This is where the Outlet Pattern becomes a powerful technique. Unlike patterns tied to routing (like React Router's Outlet), this approach is layout-agnostic and purely structural — it helps you control where in the DOM a component should render, without tight coupling to its declaration point.

In this article, we’ll explore how the Outlet Pattern works, when you should consider using it, and how to implement it with React Portals.

The Problem: Component Misalignment

Consider a situation where you’re building a design system component — for example, a Bulk Actions Bar that appears when items are selected. You want this bar to:

Render at a specific position within a content layout.
Be decoupled from its logical parent component (e.g., a Table or List component).
Avoid issues with CSS stacking context and layout constraints.

If you render the bar inline, it might break the layout flow. You need a way to teleport its rendered output to a precise location in the DOM — but still control it declaratively in React.

The Solution: Outlet Pattern with React Portals

The Outlet Pattern introduces a placeholder (Outlet component) in the desired DOM location and a render controller (OutletProvider) that allows components elsewhere in the tree to render into that placeholder.

The Key Pieces:

Outlet Component — A placeholder that provides a DOM node reference.
OutletProvider/Context — Shares the target DOM node with components that want to render into the Outlet.
Portals — Used by child components to render into the provided DOM node.

Implementing the Outlet Pattern

Step 1: Create the Outlet Context

import { createContext, useContext, useRef, useState } from 'react'

const OutletContext = createContext(null)

export function useOutlet() {
  const context = useContext(OutletContext)
  if (!context) {
    throw new Error('useOutlet must be used within an OutletProvider')
  }
  return context
}

Step 2: Build the Outlet Component

export function Outlet() {
  const [, setNode] = useOutlet()

  const callbackRef = useCallback((nodeRef) => {
    if(nodeRef) {
       setNode(nodeRef)
    }
  }, [setNode])

  return <div ref={callbackRef} />
}

Step 3: Provide the Outlet Context

export function OutletProvider({ children }) {
  const [node, setNode] = useState(null)
  return (
    <OutletContext.Provider value={[node, setNode]}>
      {children}
    </OutletContext.Provider>
  )
}

Step 4: Rendering into the Outlet

import { createPortal } from 'react-dom'

export function BulkActionsBar() {
  const [node] = useOutlet()

  if (!node) return null

  return createPortal(
    <div className="bulk-actions-bar">I’m rendered in the Outlet!</div>,
    node
  )
}

Usage Example

<OutletProvider>
  <Layout>
    <MainContent />
    <Outlet />
  </Layout>

  <BulkActionsBar />
</OutletProvider>

When Should You Use the Outlet Pattern?

You need to render floating elements (toolbars, modals, bulk action bars) into a specific layout area.
You want a clean separation of component logic vs layout positioning.
You need a flexible layout structure without deep prop drilling.

Conclusion

The Outlet Pattern is a simple yet powerful technique when you need to control where a component renders in the DOM, independently from its logical position in the React tree. Combined with React Portals, it becomes an elegant solution for layout composition challenges.

Slot-Based APIs in React: Designing Flexible and Composable Components

Talisson — Sat, 02 Aug 2025 18:19:27 +0000

In UI development, flexibility is everything. You want to give developers control over what content they render while maintaining how it's structured and styled.

Traditional component APIs often fall into the trap of prop bloat — passing specific props like headerContent, footerActions, or leftIcon. As components grow, these APIs become rigid and cumbersome.

A better pattern? Slot-Based APIs.

What Are Slots in UI Components?

A Slot is a named placeholder within a component's structure where developers can inject custom content.

It’s like giving developers controlled "hooks" inside your component's layout:

“Here’s a spot where you can put custom content — and it will render in the right place, with consistent styling.”

Think of slots as the content injection points of a component.

Why Slot-Based APIs Are Powerful

Problem	Slot-Based API Solution
Components with too many specific props	Replace with flexible named slots
Rigid structure, hard to customize content	Allow arbitrary JSX to be injected in slots
Props don’t scale with complex components	Slots decouple structure from content
Need for layout consistency with content flexibility	Slots enforce structure but let content be dynamic

Real-World Example: Card Component

Props-Driven API (Rigid & Bloated)

<Card
  title="User Profile"
  description="User details"
  headerIcon={<UserIcon />}
  footerActions={<Button>Edit</Button>}
/>

Slot-Based API (Flexible & Scalable)

<Card>
  <Card.Header>
    <UserIcon />
    <h2>User Profile</h2>
  </Card.Header>
  <Card.Body>
    User details go here.
  </Card.Body>
  <Card.Footer>
    <Button>Edit</Button>
  </Card.Footer>
</Card>

How to Implement Slot-Based APIs in React

1. Compound Components + Context (Recommended)

const CardContext = createContext({});

function Card({ children }: { children: React.ReactNode }) {
  return <CardContext.Provider value={{}}>{children}</CardContext.Provider>;
}

function CardHeader({ children }: { children: React.ReactNode }) {
  return <div className="card-header">{children}</div>;
}

function CardBody({ children }: { children: React.ReactNode }) {
  return <div className="card-body">{children}</div>;
}

function CardFooter({ children }: { children: React.ReactNode }) {
  return <div className="card-footer">{children}</div>;
}

Card.Header = CardHeader;
Card.Body = CardBody;
Card.Footer = CardFooter;

2. React.Children & cloneElement (Positional Slots)

function Modal({ children }: { children: React.ReactNode }) {
  const header = React.Children.toArray(children).find(child => React.isValidElement(child) && child.type === ModalHeader);
  const footer = React.Children.toArray(children).find(child => React.isValidElement(child) && child.type === ModalFooter);
  const body = React.Children.toArray(children).filter(child => child !== header && child !== footer);

  return (
    <div className="modal">
      {header}
      <div className="modal-body">{body}</div>
      {footer}
    </div>
  );
}

function ModalHeader({ children }: { children: React.ReactNode }) {
  return <div className="modal-header">{children}</div>;
}

function ModalFooter({ children }: { children: React.ReactNode }) {
  return <div className="modal-footer">{children}</div>;
}

3. Advanced Slot Components (Radix UI's Slot and React Aria's Slot Patterns)

Radix UI's Slot Component

Radix provides a Slot component that forwards props, refs, and classNames to its child element.

import { Slot } from '@radix-ui/react-slot';

function IconButton({ children }: { children: React.ReactNode }) {
  return (
    <button className="icon-button">
      <Slot className="button-icon" />
      {children}
    </button>
  );
}

Example: `asChild` API

function Button({ asChild = false, ...props }: { asChild?: boolean } & React.ComponentProps<'button'>) {
  const Comp = asChild ? Slot : 'button';
  return <Comp className="button" {...props} />;
}

export default function Example() {
  return (
    <Button asChild>
      <a href="/contact">Contact</a>
    </Button>
  );
}

Handling Event Handlers in Radix Slot

Radix Slot merges event handlers, prioritizing the child’s handler.

<Button asChild onClick={(e) => {
  console.log('from Slot');
  if (e.defaultPrevented) return;
}}>
  <a href="/contact" onClick={(e) => {
    e.preventDefault();
    console.log('from Child');
  }}>Contact</a>
</Button>

React Aria's Slot System (Slot Prop Injection)

React Aria Components use a slot prop pattern to inject ARIA roles and behaviors.

import { Dialog, Heading, Button } from 'react-aria-components';

function ExampleDialog() {
  return (
    <Dialog>
      <Heading slot="title">Settings</Heading>
      <p>Dialog content here</p>
      <Button slot="close">Close</Button>
    </Dialog>
  );
}

Props and accessibility attributes are merged internally based on the slot prop.

Slot Component: Radix UI vs React Aria

Library	Slot Mechanism	Purpose
Radix UI	`<Slot>` component that forwards props, refs, and classNames to its child.	Flexible composition, element-level prop merging.
React Aria	Context-based slot props injection system (no visual component).	Accessibility-focused, named prop injection into structured components.

Best Practices

Name slots meaningfully (Header, Footer, etc.).
Avoid prop bloat by favoring compositional slots.
Ensure slot content inherits design tokens.
Document slot usage in your design system.

References

Radix UI Slot Documentation: https://www.radix-ui.com/primitives/docs/utilities/slot
React Aria Slots Pattern (Advanced Composition Guide): https://react-spectrum.adobe.com/react-aria/advanced.html#slots

Do you use Slot-Based APIs in your projects? Share your patterns and thoughts below!

Compound Components in React: A Design System Superpower

Talisson — Sat, 02 Aug 2025 12:53:54 +0000

When building component libraries or design systems, flexibility and developer ergonomics are key. You want developers to compose your components like Lego blocks, without worrying about internal state wiring.

That’s where Compound Components come in.

What Are Compound Components?

Compound Components are a React design pattern where:

A Parent Component (Root) holds shared state or behavior.
Child Components consume context from the parent, without needing to pass props manually.

It allows developers to compose UIs declaratively, while the library handles the interactions under the hood.

Real-World Examples

Library	Compound Components API
Radix UI	`<Tabs.Root> <Tabs.List> <Tabs.Trigger> <Tabs.Content> </Tabs.Root>`
React Aria Components	`<DialogTrigger> <Dialog> <DialogContent> </DialogTrigger>`
Headless UI (Tailwind)	`<Menu> <MenuButton> <MenuItems> </Menu>`

In all these cases, developers don’t manage state explicitly — the parent component does.

Why Compound Components?

Benefit	Why It Matters
Declarative APIs	Developers compose UIs by nesting components
State & Behavior Encapsulation	Parent handles logic; children stay dumb
Flexible Composition	Devs can reorder or style components freely
Avoid Prop Drilling	No need to pass props down manually

Example: Building a Tabs Compound Component

1. Tabs Context

const TabsContext = createContext<{ value: string; setValue: (val: string) => void } | undefined>(undefined);

function useTabsContext() {
  const context = useContext(TabsContext);
  if (!context) throw new Error('Tabs components must be used within <Tabs.Root>');
  return context;
}

2. Tabs.Root (Parent)

function TabsRoot({ children, defaultValue }: { children: ReactNode; defaultValue: string }) {
  const [value, setValue] = useState(defaultValue);

  return (
    <TabsContext.Provider value={{ value, setValue }}>
      <div>{children}</div>
    </TabsContext.Provider>
  );
}

3. Tabs.Trigger (Child)

function TabsTrigger({ value: triggerValue, children }: { value: string; children: ReactNode }) {
  const { value, setValue } = useTabsContext();
  const isActive = value === triggerValue;

  return (
    <button onClick={() => setValue(triggerValue)} aria-selected={isActive}>
      {children}
    </button>
  );
}

4. Tabs.Content (Child)

function TabsContent({ value: contentValue, children }: { value: string; children: ReactNode }) {
  const { value } = useTabsContext();
  return value === contentValue ? <div>{children}</div> : null;
}

5. Usage

<TabsRoot defaultValue="account">
  <div>
    <TabsTrigger value="account">Account</TabsTrigger>
    <TabsTrigger value="settings">Settings</TabsTrigger>
  </div>
  <TabsContent value="account">Account Content</TabsContent>
  <TabsContent value="settings">Settings Content</TabsContent>
</TabsRoot>

Key Points:

Developers compose structure.
The library handles behavior wiring via Context.
Developers don’t need to pass down onClick, isActive, etc.

When Should You Use Compound Components?

Use Case	Compound Components?
Complex interactions across parts	Yes
State shared among siblings	Yes
Simple isolated UI elements	No

Best Practices

Use Context API to share state across compounds.
Ensure child components throw helpful errors if misused outside Root.
Document clearly how developers should compose them.
Provide sensible defaults (e.g., default active tab).

Conclusion

Compound Components are a superpower for design systems. They provide an intuitive API for developers, while keeping state and behavior encapsulated under the hood. It leads to better DX, more flexibility, and cleaner components.

Mastering this pattern will elevate your component library architecture.

Do you already use Compound Components? Share your experience or questions below!

UI Logic Should Live in Hooks, Not in JSX

Talisson — Fri, 01 Aug 2025 21:30:05 +0000

When building React components, it's tempting to write logic directly inside JSX. After all, JSX looks like HTML, and sprinkling some conditional rendering or small calculations inline feels natural. But as your UI grows, this approach quickly leads to cluttered components that are hard to read, reuse, and maintain.

There's a better way: Move UI logic into custom hooks.

What Do We Mean by "UI Logic"?

UI logic refers to any behavior that controls how something is displayed or interacted with in the UI. This includes things like:

Conditional rendering (show/hide elements based on state)
Derived state (e.g., isSelected = currentId === item.id)
Event handling logic
Accessibility behaviors (e.g., focus management)
Animation triggers and states

These are not business rules or API calls — they're decisions that shape the UI experience.

The Problem with JSX-Centric Logic

Let's look at a typical example:

export function UserCard({ user, selectedId, onSelect }: Props) {
  return (
    <div
      className={`user-card ${selectedId === user.id ? 'selected' : ''}`}
      onClick={() => onSelect(user.id)}
    >
      {user.isAdmin && <span className="badge">Admin</span>}
      <p>{user.name}</p>
    </div>
  );
}

This works fine — until it doesn't. What happens when:

The "selected" logic becomes more complex?
You need additional accessibility handling (e.g., ARIA attributes)?
The badge rendering requires more rules?
You want to reuse this logic elsewhere?

JSX becomes noisy, making the component harder to scan. Every new requirement increases cognitive load.

Why Hooks Are the Right Place for UI Logic

Custom hooks provide a clean separation between behavior and structure.

Let's refactor the example using a hook:

function useUserCard(user, selectedId, onSelect) {
  const isSelected = selectedId === user.id;

  const handleClick = () => {
    onSelect(user.id);
  };

  const showBadge = user.isAdmin;

  return { isSelected, handleClick, showBadge };
}

export function UserCard({ user, selectedId, onSelect }: Props) {
  const { isSelected, handleClick, showBadge } = useUserCard(user, selectedId, onSelect);

  return (
    <div className={`user-card ${isSelected ? 'selected' : ''}`} onClick={handleClick}>
      {showBadge && <span className="badge">Admin</span>}
      <p>{user.name}</p>
    </div>
  );
}

Notice how:

JSX now only describes the structure of the UI.
Logic is testable in isolation.
You can reuse useUserCard elsewhere.

Real-World Example: NavigationItem Refactor

Let's take a real-world example of a complex component and refactor it.

Before: All-in-One Component

export const NavigationItem = forwardRef<HTMLButtonElement, NavigationItemProps>(
  ({ label, icon, isActive = false, ...props }, forwardedRef) => {
    const [open, setOpen] = useState(false);
    const [isFocused, setIsFocused] = useState(false);
    const [isOverflowing, setIsOverflowing] = useState(false);
    const contentRef = useRef<HTMLSpanElement | null>(null);

    const toggleOpen = () => setOpen((prev) => !prev);

    const handleContextMenu = (e) => { /* logic */ };
    const handleKeyDown = (e) => { /* logic */ };
    const handleClick = (e) => { /* logic */ };

    useEffect(() => { /* measure overflow */ }, [label]);

    const renderedIcon = isActive || isFocused ? cloneElement(icon, { color: 'activeColor' }) : icon;

    return (
      <Button {...props} ref={forwardedRef}>
        {/* structure mixed with logic */}
      </Button>
    );
  }
);

Problems:

Logic and rendering tightly coupled.
Hard to reuse logic (e.g., overflow detection, toggle state).
JSX cluttered with inline handlers.

After: Hooks Composition Pattern

I broke the logic into small focused hooks:

useControlledToggle → Handles open state management.
useFocusState → Tracks focus/blur state.
useTextOverflow → Detects overflow content.
useActiveIcon → Derives icon state based on activity/focus.

export const NavigationItem = forwardRef<HTMLButtonElement, NavigationItemProps>(
  ({ label, icon, isActive = false, onToggleDropdown, ...props }, forwardedRef) => {
    const [open, setOpen, toggleOpen] = useControlledToggle(undefined, onToggleDropdown);
    const { isFocused, onFocus, onBlur } = useFocusState();
    const contentRef = useRef<HTMLSpanElement | null>(null);
    const isOverflowing = useTextOverflow(contentRef, [label]);
    const renderedIcon = useActiveIcon(icon, isActive, isFocused);

    const handleContextMenu = (e) => { /* simplified */ };
    const handleKeyDown = (e) => { /* simplified */ };
    const handleClick = (e) => { /* simplified */ };

    return (
      <NavigationDropdown isOpen={open} onOpenChange={setOpen}>
        <Tooltip content={isOverflowing ? label : undefined}>
          <Button
            ref={forwardedRef}
            onClick={handleClick}
            onKeyDown={handleKeyDown}
            onContextMenu={handleContextMenu}
            onFocus={onFocus}
            onBlur={onBlur}
            aria-current={isActive ? 'page' : undefined}
            variant={isActive ? 'active' : 'standard'}
            {...props}
          >
            <InnerText ref={contentRef}>{renderedIcon}{!isOverflowing && label}</InnerText>
            <VerticalDotsIcon data-visible={isActive} />
          </Button>
        </Tooltip>
      </NavigationDropdown>
    );
  }
);

Division of Responsibilities:

Concern	Hook / Responsibility
Dropdown Open State	`useControlledToggle`
Focus State Management	`useFocusState`
Overflow Detection	`useTextOverflow`
Icon State Logic	`useActiveIcon`
Rendering Structure	`NavigationItem` Component JSX

Benefits of Hooks Composition:

Encapsulation: Each concern is isolated in its own hook.
Reusability: Hooks like useTextOverflow can be reused in tabs, breadcrumbs, etc.
Simplified JSX: JSX now reads as a structure blueprint, free of logic noise.
Testability: Hooks can be tested in isolation without rendering components.
Scalability: Adding new behaviors (animations, ARIA patterns) won’t bloat the component.

Avoiding Over-Engineering: When Not to Abstract Hooks

While hooks are a powerful tool for managing UI logic, over-abstracting too early can hurt more than help. Abstraction should serve clarity, not complexity.

Here’s when it’s better to keep logic inside the component:

If it’s only a few lines and unlikely to be reused, it’s fine to leave it inline.
Avoid moving visual structure (markup decisions) into hooks — hooks should handle behavior and state, not render JSX.
Prioritize readability: Don’t split trivial logic into many micro-hooks if it makes the component harder to follow.

A hook’s purpose is to clarify responsibilities, not just to “move code out of the component.” Use hooks to:

Group related behaviors.
Isolate side effects.
Derive complex UI state.

But don’t feel pressured to abstract everything prematurely. A balanced approach wins.

A Rule of Thumb

Whenever you find yourself writing derived values like this:

const isSelected = selectedId === item.id;
const visibleItems = items.filter(item => item.visible);

Or complex conditions directly in JSX:

{user.isAdmin && permissions.includes('edit') && (
  <Button>Edit</Button>
)}

Ask yourself:

"Is this logic shaping UI behavior? Would it improve readability and reuse if I moved it to a hook?"

If the answer is yes, abstract it. If it’s trivial and specific to this component, keep it inline.

Hooks should clarify, not overcomplicate your codebase.

Conclusion

Great UIs are not just about visuals; they’re about maintainable, scalable architecture. By moving UI logic into hooks, you create components that are easier to read, extend, and reuse. Your JSX becomes declarative and your logic composable.

Stop putting logic in your JSX. Embrace hooks as the home for UI behavior.

What do you think? Are you team logic-in-hooks or do you still prefer inline logic? Let’s discuss in the comments!

From Component to System: How I Built with Design System Thinking

Talisson — Tue, 22 Jul 2025 23:38:04 +0000

Introduction

When working on a recent take-home project, I was tasked with building a page navigation UI with drag and drop, inline add buttons, and contextual menus. Instead of rushing to just meet the functional requirements, I decided to treat it like the foundation of a design system.

I asked myself:

How reusable are these components?
Are they accessible by default?
Will they scale with consistency across a real product?

In this article, I’ll walk through how I approached this project with a design system mindset. From tokens and foundations to testing and documentation, this mindset helped me build faster, more confidently, and with a higher standard of quality.

1. Building Foundations First: From Tokens to Buttons

Before writing any component logic, I started with design tokens. I broke down the design into structured values:

Text colors, background layers, surface tones
Icon colors and interaction states (hover, focus, active)
Border radius, z-index, shadows, and spacing

Establishing these early allowed every component to be visually consistent and easier to maintain. I didn’t need to guess colors or spacing since they were already defined.

Next, I tackled icons. Icons are a critical part of the interface. They give users immediate visual context. By organizing and documenting them early, I avoided inconsistencies and made the UI easier to scale.

Then came the buttons. Buttons are one of the most reused and visible components in any system. I created well-defined variants, sizes, and interaction states to ensure they could be used confidently across the project.

With tokens, icons, and buttons in place, I had a strong foundation to build more complex interactive components while reducing errors and increasing speed.

2. Designing for Accessibility, Always

One thing I always keep in mind when building any component is keyboard navigation.

Even though the prompt didn’t explicitly ask for accessibility, I built every component to be fully usable via keyboard:

Buttons and dropdowns could be focused and triggered
Items inside menus were navigable using arrow keys
Drag and drop interactions had visible focus and feedback

By doing this from the beginning, I wasn’t adding accessibility later. I was building accessibly from the start.

3. Motion, Feedback, and User Experience

Beyond consistency, I focused deeply on motion and interaction.

Animations were designed to guide and enhance the experience. The way dropdowns opened, the direction, the easing — everything contributed to smoother UX.
When dragging an item, buttons subtly created space to show possible drop targets.
After dropping, a brief highlight signaled the action was complete. This helped users understand the result of their interactions.

Motion was not just decoration. It was a way to communicate clearly and make the interface feel alive.

Combined with design tokens, this attention to motion kept the experience smooth, expressive, and consistent across multiple components.

4. Documentation: The Key to Adoption and Consistency

A design system is only useful if people understand how to use it. That’s why I treated documentation as a first-class priority.

I used Storybook to document:

Every button variant and size
Icon options with names and use cases
Examples of dropdowns, drag and drop behavior, and page states

Good documentation ensures developers don’t reinvent the wheel. It also helps designers validate behavior in real contexts. Even something as simple as documenting icons made the system more discoverable and reliable.

5. Testing for Reliability, Speed, and Confidence

Since I was treating this like a proper design system, tests were essential.

I used Chromatic for visual and interaction testing. It helped catch regressions and inconsistent patterns directly in the CI pipeline.
TypeScript checks ensured every commit produced a stable build.
Lint rules helped maintain code quality and prevent technical debt.

These tests didn’t slow me down. They helped me move faster. With only a weekend to complete the project, knowing I had these safety nets allowed me to develop with confidence and speed.

Final Thoughts

This wasn’t just a take-home assignment. It was an opportunity to build something with intention and long-term value.

By approaching the work with a design system mindset — focusing on reusability, accessibility, tokens, motion, documentation, and testing — I created more than just a UI. I created a foundation that can scale.

Design systems aren’t about limitation. They’re about unlocking creativity, increasing speed, and raising the quality bar for the whole product.

DEV Community: Talisson

BulkActionsBar - Part 2 - Engineering a Robust and Accessible Bulk Actions Bar in React

Overflow Detection: Calculating Visible Items

The Dropdown Menu: Desktop vs Mobile Submenus

Attempt #1: Portal in Dropdown Item

Attempt #2: Root Content Replacement with Stack State

Center Alignment with Side Navigation Constraints

Recursive Submenus Handling

Lessons Learned

Conclusion

References:

BulkActionBar - Part 1 - The UX Micro-Interactions that Make Bulk Actions Feel Intuitive

The Problem Statement

Simple Interactions, Big UX Value

Overflow Items and the “More Options” Menu

Developer-Driven Refinements Beyond the Design Spec

Conclusion

Linked Lists: The Hidden Power Behind React Hooks

What Is a Linked List?

The Problem React Needed to Solve

Hooks as a Linked List

Inside React’s Codebase

Why This Matters for Frontend Developers

Beyond React: Linked Lists in Frontend Development

Want to Dive Deeper into React Hooks?

Final Thoughts

References

Hooks in React 19: Why They Still Matter and What’s New

Why Hooks Knowledge Remains Essential

What’s New in React 19 for Hooks

1. Improved Concurrent Rendering and Hooks

2. New useActionState Hook

3. Optimized useMemo and useCallback

4. Enhanced use Hook

Updated Best Practices for Hooks in React 19

Example: Combining Hooks in React 19

Recap: Hooks in React 19

Want to Dive Deeper?

Final Thoughts

Hooks Under the Hood: How React Hooks Actually Work

Why You Should Care

The Core Idea

How React Tracks Hook Calls

What Happens When You Call useState

What About useEffect

Why the Rules of Hooks Matter

Common Pitfalls

Custom Hooks Use the Same Mechanism

Recap: The Lifecycle of a Hook Call

Want to Dive Deeper

Final Thoughts

Part 3 - Scaling the Outlet Pattern with Multiple Named Outlets in React

The Problem with Single Outlet Context

Introducing Named Outlets

Architecture Overview

Implementing Named Outlets

Step 1: Context for Named Outlets

Step 2: NamedOutletProvider

Step 3: NamedOutlet Placeholder Component

Step 4: Rendering into a Named Outlet

Usage Example

Benefits of Named Outlets

Considerations

Conclusion

Part 2 - Applying the Outlet Pattern in Real-World UI Components

The Scenario

Key Components of the Pattern

1. Outlet Placeholder — BulkActionsBarOutlet

2. Content Component — BulkActionsBar

3. Context Bridge — useBulkActionsBarContext

Why This Pattern Works

Visual Flow

Conclusion

Part 1 - Rendering Components Outside the DOM Tree with the Outlet Pattern in React

The Problem: Component Misalignment

The Solution: Outlet Pattern with React Portals

The Key Pieces:

Implementing the Outlet Pattern

Step 1: Create the Outlet Context

Step 2: Build the Outlet Component

2. New `useActionState` Hook

3. Optimized `useMemo` and `useCallback`

4. Enhanced `use` Hook

What Happens When You Call `useState`

What About `useEffect`

1. Outlet Placeholder — `BulkActionsBarOutlet`

2. Content Component — `BulkActionsBar`

3. Context Bridge — `useBulkActionsBarContext`

Example: `asChild` API