feat(react-ui-base): add thread-history compound component

[lachieh]

Summary

Adds thread-history compound component base primitives and styled wrapper.

Base: Root, Header, List, Item, CollapseToggle, NewThreadButton, SearchInput
Styled: Composes base components with Tailwind styling

Fixes TAM-1064

Test Plan

• Verify component renders in showcase
• Run npm run lint && npm run check-types && npm test

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cloud	Error		Feb 9, 2026 10:18pm
showcase	Error		Feb 9, 2026 10:18pm
tambo-docs	Error		Feb 9, 2026 10:18pm

[charliecreates]

The new base primitives are generally well-structured, but several components (CollapseToggle, NewThreadButton, Item) allow consumer onClick props to override core internal behavior due to {...props} spread order, which is a real correctness/compatibility risk. ThreadHistoryRoot introduces a global CSS variable side effect without cleanup, which can leak state across mounts. The styled wrapper’s collapsed behavior likely changed subtly because it no longer applies the prior collapse transition classes and instead returns null in render, potentially affecting layout/scroll behavior.

Additional notes (1)

• Readability | packages/ui-registry/src/components/thread-history/thread-history.tsx:271-289
  In the styled wrapper, ThreadHistoryBase.List is given a className but the render function returns null when collapsed. This is fine, but note that the base List still sets data-* attributes and can be styled via [data-collapsed]. The wrapper also removed the previous collapsed transition classes; now the parent will always have overflow-y-auto flex-1 ... even when collapsed.

This can cause layout/scroll affordances to differ from the old behavior (e.g., still reserving space / scroll container present).

Summary of changes

What changed

✨ New ThreadHistory compound component in react-ui-base

• Added a new public export path @tambo-ai/react-ui-base/thread-history via packages/react-ui-base/package.json exports.
• Exposed ThreadHistory namespace and related prop/render-prop types from packages/react-ui-base/src/index.ts.
• Introduced base primitives under packages/react-ui-base/src/thread-history/*:
  • Root + context (ThreadHistoryRootContext)
  • Header, List, Item
  • CollapseToggle, NewThreadButton, SearchInput
• Implemented shared state in ThreadHistoryRoot using useTamboThreadList() / useTamboThread() and provided it via context.

🎨 Refactor UI registry component to compose base primitives

• Updated packages/ui-registry/src/components/thread-history/thread-history.tsx to:
  • Remove the local context + thread filtering logic
  • Compose UI using ThreadHistoryBase.* components and render props
  • Keep styling and thread rename/generate interactions in the styled wrapper

[charliecreates]

ThreadHistoryCollapseToggle hard-sets onClick={handleToggle} and then spreads {...props} afterwards. That means any consumer-provided onClick overrides the internal toggle, potentially breaking the component silently.

This is a correctness issue for a base primitive: it should always toggle, while still allowing consumers to run their own handler.

Suggestion

Change the click handler to compose with props.onClick instead of being overwritten (or overriding the consumer). For example:

const handleClick: React.MouseEventHandler<HTMLButtonElement> = (e) => {
  props.onClick?.(e);
  if (e.defaultPrevented) return;
  setIsCollapsed((prev) => !prev);
};

return (
  <Comp
    ...
    onClick={handleClick}
    {...props}
  />
);

This keeps the primitive reliable while preserving extensibility. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

ThreadHistoryNewThreadButton has the same handler precedence issue: onClick={handleNewThread} is set but then {...props} comes after, allowing a consumer onClick to override and prevent new thread creation.

Also, handleNewThread stops propagation only when invoked with a mouse event. If consumers call it via their own click handler (or if composed later), behavior may differ.

Suggestion

Compose props.onClick with the internal action and ensure internal behavior still runs unless prevented:

const handleClick: React.MouseEventHandler<HTMLButtonElement> = async (e) => {
  props.onClick?.(e);
  if (e.defaultPrevented) return;
  e.stopPropagation();
  await handleNewThread();
};

return (
  <Comp
    ...
    onClick={handleClick}
    {...props}
  />
);

(You can inline handleNewThread and remove the optional event param.) Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

ThreadHistoryNewThreadButton also allows onClick to override the internal handler

You pass onClick={handleNewThread} and then spread {...props} after, which means consumer onClick will override and prevent new thread creation.

Additionally, the global document.addEventListener('keydown', ...) means every mounted instance registers a hotkey and it will fire even when the user is typing in an input/textarea or when focus is inside a menu. That’s likely to cause surprising behavior.

Suggestion

1. Compose onClick like in the other primitives.

2. Gate the keyboard shortcut to avoid triggering while typing, and consider requiring focus within the ThreadHistory root.

React.useEffect(() => {
  const handleKeyDown = (event: KeyboardEvent) => {
    const el = event.target as HTMLElement | null;
    const isTypingTarget =
      el?.tagName === "INPUT" ||
      el?.tagName === "TEXTAREA" ||
      (el as HTMLElement | null)?.isContentEditable;

    if (isTypingTarget) return;

    if (event.altKey && event.shiftKey && event.key.toLowerCase() === "n") {
      event.preventDefault();
      void handleNewThread();
    }
  };

  document.addEventListener("keydown", handleKeyDown);
  return () => document.removeEventListener("keydown", handleKeyDown);
}, [handleNewThread]);

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

ThreadHistoryItem also risks breaking its core behavior because {...props} comes after onClick={handleClick}. A consumer-provided onClick would replace the internal switchCurrentThread call.

Additionally, if you do compose handlers, make sure to pass the click event through so consumers can preventDefault() / stopPropagation() when needed.

Suggestion

Compose the click handler instead of allowing it to be overridden:

const handleItemClick: React.MouseEventHandler<HTMLDivElement> = (e) => {
  props.onClick?.(e);
  if (e.defaultPrevented) return;
  switchCurrentThread(thread.id);
  onThreadChange?.();
};

return (
  <Comp
    ...
    onClick={handleItemClick}
    {...props}
  />
);

Also consider using a semantic element (e.g. button) when not asChild so the item is keyboard accessible by default. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

ThreadHistoryRoot mutates a global CSS variable on document.documentElement but never restores the previous value on unmount. If multiple sidebars mount/unmount (or different pages set the same variable), this can leave stale global state behind.

Since react-ui-base is a primitives package, global side effects should be carefully scoped and cleaned up.

Suggestion

Capture the previous value and restore it in the effect cleanup:

React.useEffect(() => {
  const el = document.documentElement;
  const prev = el.style.getPropertyValue("--sidebar-width");
  el.style.setProperty("--sidebar-width", isCollapsed ? "3rem" : "16rem");
  return () => {
    if (prev) el.style.setProperty("--sidebar-width", prev);
    else el.style.removeProperty("--sidebar-width");
  };
}, [isCollapsed]);

Alternatively, consider moving this responsibility to the styled wrapper (ui-registry) rather than the base primitive. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

Styled wrapper dropped explicit width handling

Previously the styled wrapper applied isCollapsed ? "w-12" : "w-64". After refactor, the width class is no longer applied in the wrapper; instead, the base root sets a global --sidebar-width variable. Unless the layout CSS elsewhere actually uses var(--sidebar-width), this change can break the visual collapse/expand behavior.

Even if it works today, it makes the wrapper’s sizing implicit and harder to reason about.

Suggestion

Keep width behavior local to the styled wrapper so it’s explicit and doesn’t rely on global CSS variables:

<ThreadHistoryBase.Root ...>
  {({ isCollapsed }) => (
    <div
      className={cn(
        "border-flat bg-container h-full transition-all duration-300 flex-none",
        position === "left" ? "border-r" : "border-l",
        isCollapsed ? "w-12" : "w-64",
        className,
      )}
    >
      ...
    </div>
  )}
</ThreadHistoryBase.Root>

(or ensure the component actually consumes --sidebar-width in its styles).

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

ThreadHistorySearchInput uses a fixed setTimeout(300) to focus, which is brittle

The focus logic assumes an animation duration and schedules focus 300ms later. That can easily desync if styles change, and can lead to focusing an element that has been unmounted.

Also, there’s no cancellation/cleanup of the timeout on unmount or on rapid toggles.

Suggestion

Prefer focusing on the next frame(s) and clean up pending timers. If you want to wait for expansion, use requestAnimationFrame twice or a timeout you cancel.

const focusTimerRef = React.useRef<number | null>(null);

React.useEffect(() => {
  return () => {
    if (focusTimerRef.current != null) {
      window.clearTimeout(focusTimerRef.current);
    }
  };
}, []);

const expandOnSearch = React.useCallback(() => {
  if (!isCollapsed) {
    searchInputRef.current?.focus();
    return;
  }

  setIsCollapsed(false);
  if (focusTimerRef.current != null) window.clearTimeout(focusTimerRef.current);
  focusTimerRef.current = window.setTimeout(() => {
    searchInputRef.current?.focus();
  }, 0);
}, [isCollapsed, setIsCollapsed]);

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.