You have a layout with a sidebar. Different pages need different sidebar content. The obvious solutions all have tradeoffs:

Prop drilling: Pass sidebar content up through every layer. Verbose, brittle.

Global state: Store sidebar config in Redux/Zustand. Now your UI is in a store.

Render props: <Layout sidebar={<Filters />}>. Works until you need sidebar content that depends on state defined inside the page.

That last point is the killer. Your filters component needs access to state that lives deep in your page component. Now what?

The Solution

A slot is a named portal target discovered at runtime via React context.

import { createContext, useContext, useState, PropsWithChildren } from 'react'
import { createPortal } from 'react-dom'

type SlotState = [
  HTMLDivElement | null,
  React.Dispatch<React.SetStateAction<HTMLDivElement | null>>,
]

export function createSlot(name: string) {
  const Context = createContext<SlotState | null>(null)

  function useSlot() {
    const ctx = useContext(Context)
    if (!ctx) {
      throw new Error(`${name} must be used within ${name}.Provider`)
    }
    return ctx
  }

  function Provider({ children }: PropsWithChildren) {
    const slotState = useState<HTMLDivElement | null>(null)
    return <Context.Provider value={slotState}>{children}</Context.Provider>
  }

  function Slot(props: React.HTMLAttributes<HTMLDivElement>) {
    const [, setSlot] = useSlot()
    return <div {...props} ref={setSlot} />
  }

  function Portal({ children }: PropsWithChildren) {
    const [slot] = useSlot()
    return slot ? createPortal(children, slot) : null
  }

  return { Provider, Slot, Portal }
}

Usage

const Sidebar = createSlot('Sidebar')

function Layout({ children }: PropsWithChildren) {
  return (
    <Sidebar.Provider>
      <div className="flex">
        <aside>
          <Sidebar.Slot />
        </aside>
        <main>{children}</main>
      </div>
    </Sidebar.Provider>
  )
}

function SearchPage() {
  const [filters, setFilters] = useState({ date: 'any', type: 'all' })
  const results = useSearch(filters)

  return (
    <>
      <ResultsList results={results} />

      <Sidebar.Portal>
        <Filters value={filters} onChange={setFilters} />
        <ResultCount count={results.length} />
      </Sidebar.Portal>
    </>
  )
}

The filters live in the sidebar visually, but in SearchPage logically. State stays colocated with the component that uses it.

Why This Works

React has two hierarchies: the component tree (data flow) and the DOM tree (visual layout). They're usually the same. Portals let you separate them.

Standard portals target fixed DOM nodes like document.body. This pattern targets a dynamic node discovered via context. The slot registers itself with a ref. The portal finds it through the same context.

Result: components inject content into arbitrary layout positions while preserving normal React data flow. Context, state, handlers — everything works as expected.

When to Use This

• Sidebars with page-specific content

• Header actions that depend on page state

• Toolbars that change based on selection

• Any layout where content source and content location should be decoupled

When Not To

If your sidebar content doesn't need state from inside the page, simpler patterns work fine. Render props or composition handle static content without the indirection.

The Problem

Imagine you have a list of items and a selected item ID. When items change, you need to clear the selection if the selected item no longer exists.

Here's the instinctive (but wrong) approach:

function ItemList() {
  const [selectedId, setSelectedId] = useState<string | null>(null)
  const items = useItems()

  useEffect(() => {
    if (selectedId !== null && !items.some((item) => item.id === selectedId)) {
      setSelectedId(null)
    }
  }, [items, selectedId])

  return <List items={items} selectedId={selectedId} />
}

This looks reasonable, but there's a hidden problem: for one render, selectedId points to an item that doesn't exist.

React renders with stale state, then the effect runs and fixes it. During that intermediate render, any code that assumes selectedId is valid will break.

But there's a deeper issue here — this code misunderstands what state is for.

The Mental Shift

When you call setSelectedId("abc"), you're not declaring "item abc is selected." You're recording an event: "the user selected item abc."

State is a record of what happened. It's historical. It doesn't make claims about whether that selection is still valid — that's a separate concern.

This reframing changes everything. Watch what happens when we rename the variable to reflect what it actually holds:

function ItemList() {
  const [lastSelectedId, setLastSelectedId] = useState<string | null>(null)
  const items = useItems()

  const selectedId = useMemo(
    () => items.some((item) => item.id === lastSelectedId) ? lastSelectedId : null,
    [items, lastSelectedId],
  )

  return <List items={items} selectedId={selectedId} />
}

Now the code reads honestly:

• lastSelectedId — the last ID the user selected (a fact about the past)

• selectedId — the currently valid selection (derived from present reality)

There's no useEffect. No sync. No intermediate broken render. The derivation happens synchronously during render, so selectedId is always consistent with items.

The Principle

State records what happened. Derived values describe what's true now.

When you try to store "what's true now" directly in state, you end up fighting to keep it updated — hence the useEffect trap. But when you store the raw historical fact and derive current truth from it, everything stays in sync automatically.

A Reusable Hook

This pattern comes up often enough that it's worth extracting:

function useSelection<TItem, TKey extends keyof TItem>(
  items: TItem[],
  identifierKey: TKey,
): [TItem[TKey] | null, (id: TItem[TKey] | null) => void] {
  const [lastSelectedId, setLastSelectedId] = useState<TItem[TKey] | null>(null)

  const selectedId = useMemo(
    () => items.some((item) => item[identifierKey] === lastSelectedId) ? lastSelectedId : null,
    [items, identifierKey, lastSelectedId],
  )

  return [selectedId, setLastSelectedId]
}

Usage is clean:

function ItemList() {
  const items = useItems()
  const [selectedId, setSelectedId] = useSelection(items, 'id')

  return <List items={items} selectedId={selectedId} />
}

The hook encapsulates the pattern: store the user's action, derive the valid state. Consumers get a selectedId that's always safe to use.

Takeaway

Next time you reach for useEffect to "fix" state based on other state, pause. Ask yourself: am I storing a fact about the past, or am I trying to store current truth?

Store the past. Derive the present.