Feature request: Add a fallback renderer for runtime-named server tools in @tanstack/ai-react/ui

[duohelingdukele]

Problem

createChatHook() / createChatUI() dispatches tool UI by an exact,
module-scope toolsComponents[toolName] mapping.

This works well for statically declared client tools, but it cannot render
server tools whose names are created at runtime.

A concrete use case is multi-knowledge-base retrieval:
the server creates one read-only tool per knowledge base, such as:

• kb_search_8d5...
• kb_search_1a2...

The tool names and descriptions are intentionally runtime-derived so the model
can choose a knowledge base from its description. The client cannot know every
tool name when the module is compiled.

Currently, when a tool name is not present in toolsComponents, the UI warns
about the missing component and renders nothing. partsComponents.fallback
does not help because tool dispatch happens before generic part fallback.

Proposal

Add an optional fallback renderer for unknown tool names:

toolsComponents: {
  getWeather: WeatherTool,
  fallback: ({ part, result, interrupt }) => (
    <DynamicServerToolCard
      name={part.name}
      part={part}
      result={result}
      interrupt={interrupt}
    />
  ),
}

Suggested dispatch order:

1. Render toolsComponents[part.name] when present.
2. Otherwise render toolsComponents.fallback when present.
3. Otherwise keep the current development warning and render null.
   The fallback props should intentionally use broad tool-call/result types,
   because the tool name and schemas are not statically known.
   Why this matters
   This preserves the factory's precise typing for statically registered tools,
   while allowing safe rendering of server-authoritative runtime tools.
   It avoids workarounds such as recreating the factory at runtime or mutating
   the tool-component registry after initialization.
   Acceptance criteria

• A statically registered tool continues to use its exact typed component.
• An unknown runtime tool renders through toolsComponents.fallback.
• Tool call state, result, and optional approval/interrupt state are available
  to the fallback.
• Without a fallback, current warning/null behavior remains unchanged.
• Add React UI tests for named dispatch, fallback dispatch, and missing dispatch.

[AlemTuzlak]

This was an oversight, it was intended to work that way from the beginning, I'll look into this!