OpenWikilangchain-ai/langchain

Generative UI

Purpose and Scope

Generative UI is a frontend pattern where an agent produces a structured interface specification instead of only producing conversational text. In the official LangChain frontend documentation, the AI is asked for a UI such as a form, card, dashboard, or layout; the application constrains that generation with a component catalog; and a renderer turns the resulting JSON specification into real framework components. The central idea is that the model is not allowed to invent arbitrary code. It composes from a catalog of components that the developer owns, with typed props and descriptions that explain when each component should be used.

This page focuses on how to think about that pattern when building LangChain agent applications from this Python monorepo. The repository source directly associated with this page is not a renderer implementation; it is a JavaScript parser compatibility entry point in langchain_classic that dynamically resolves JavaScriptSegmenter from langchain_community. That source is still relevant to agent UI work because production agents often need to ingest, index, retrieve, or reason over frontend source files. Generative UI applications depend on well-defined component catalogs, and code-aware loading is one way to keep agent context aligned with the actual JavaScript or TypeScript UI surface. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

Relevant Source Files

  • libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py - Provides the langchain_classic import surface for JavaScriptSegmenter, delegating to the community JavaScript parser through a dynamic deprecated-import lookup. This is the repository-backed bridge for JavaScript source segmentation used in document-loading and retrieval workflows.

Core Primitives

A Generative UI application has four main primitives. The first is the catalog: a list of components the agent may use, including descriptions and prop schemas. The second is the prompt: the user or developer request that describes the desired interface. The third is the generated spec: a JSON document representing the component tree. The fourth is the renderer: the frontend runtime that validates and renders the spec with the application’s own components. In the official frontend guidance, json-render provides the catalog and rendering model, while schemas such as Zod define the allowed prop shapes.

The catalog acts as a guardrail rather than just documentation. Because the model can only choose known components and props that match their schemas, the output is constrained to a predictable interface tree. This is different from asking a model to emit raw HTML, JSX, or framework-specific code. The developer keeps control over styling, security boundaries, interaction behavior, and data access. The model contributes composition: it decides that a request should become, for example, a card containing a vertical stack with text inputs and action buttons.

A minimal catalog-oriented flow looks like this: define components such as Card, Stack, and TextInput; describe each component in natural language; attach a prop schema; send the user’s UI request plus catalog metadata to the model; parse the returned JSON spec; and pass that spec into the renderer. The exact frontend framework can vary. The official docs describe safe rendering across React, Vue, Svelte, and Angular, which means the component contract is more important than a single view implementation. LangChain’s role is to help orchestrate the model call, tool use, retrieval, and runtime context around that generation task.

System-to-Code Mapping

The repository source for this page maps to the context side of the workflow. libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py imports create_importer, defines a DEPRECATED_LOOKUP entry for JavaScriptSegmenter, builds _import_attribute, and exposes __getattr__ plus __all__. In practice, this means callers using the older langchain_classic.document_loaders.parsers.language.javascript import path can still resolve the JavaScript segmenter while the implementation lives in langchain_community.document_loaders.parsers.language.javascript. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

That mapping matters for generative UI because useful UI generation is rarely isolated from a codebase. If an agent needs to answer “build a settings panel using our existing components,” it may need source-aware context about available components, naming conventions, prop patterns, and layout utilities. JavaScript segmentation helps split frontend code into retrievable units so an agent can ground its choices in the application’s real catalog or component library. The shim itself does not define the catalog or renderer, but it preserves a stable import path for language-aware parsing infrastructure that can feed retrieval-augmented UI authoring.

Implementation Details

When using this pattern, separate generation from rendering. The model should produce a JSON spec that names catalog components and provides validated props; the renderer should be the only layer that turns the spec into visible UI. Avoid letting the model output executable JavaScript as the primary artifact. This matches the official Generative UI framing: the developer defines the allowed components, the AI composes them, and the renderer safely renders the result. The component catalog is the boundary between creative generation and application control.

A practical agent architecture usually includes a model, prompt instructions, optional retrieval over frontend source, validation, and a renderer. Retrieval can include component documentation, Storybook-like examples, design-system files, or parsed JavaScript modules. The repository path on this page supports the JavaScript parsing portion through JavaScriptSegmenter compatibility. The agent should use retrieved context to choose components that actually exist, while validation should reject specs that reference unknown component names or invalid prop values. This keeps the UI generation loop deterministic enough to test and safe enough to expose to users.

import { defineCatalog } from "@json-render/core";
import { schema } from "@json-render/react/schema";
import { z } from "zod";
 
const catalog = defineCatalog(schema, {
  components: {
    Card: {
      description: "A card container with optional title and padding",
      props: z.object({
        title: z.string().optional(),
        padding: z.enum(["sm", "md", "lg"]).optional(),
      }),
    },
    Stack: {
      description: "Layout children with consistent spacing",
      props: z.object({
        direction: z.enum(["vertical", "horizontal"]).optional(),
        gap: z.enum(["sm", "md", "lg"]).optional(),
      }),
    },
  },
});

The example shows the shape of the contract: component names, descriptions, and typed props. In a LangChain-backed application, the prompt should make this contract explicit and ask the model for a spec, not for source code. If the agent is connected to a repository index, use JavaScript-aware segmentation to keep catalog context fresh as components evolve. If the UI library changes, re-index the relevant files and update the catalog schema together, because the model-facing descriptions and the renderer-facing component implementations must remain synchronized.

Execution Flow

A typical execution flow starts when a user asks for an interface, such as a project dashboard or onboarding form. The application sends the request, catalog descriptions, and any retrieved component context to the model. The model returns a JSON UI tree. The application validates the tree against the catalog schema, rejects or repairs invalid specs, and then passes the accepted spec to the renderer. If the UI includes actions, those actions should map back to explicit application handlers or agent tools rather than arbitrary generated code.

For agent applications, this flow can also be iterative. The user may ask to add a filter, simplify the layout, or convert a card into a form. The agent should treat the current spec as state, apply the requested change within the same catalog constraints, and return a revised spec. Streaming interfaces can show intermediate reasoning or progress separately from the final renderable tree, but the committed UI artifact should remain structured and validated. This keeps the user experience responsive without weakening the safety boundary around rendering.

Testing Signals and Next Steps

Test a Generative UI feature at three levels. First, validate schemas directly: every catalog component should accept the props the model is expected to produce and reject invalid values. Second, test model prompts with representative requests and verify that generated specs only contain catalog components. Third, test rendering with known-good and known-bad specs so the frontend fails closed. If retrieval over source files is part of the system, include indexing checks that ensure JavaScript component context can be loaded and segmented through the maintained import surface. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

Next, read the frontend overview and streaming UI pages if your application needs a richer client experience around agent runs. Pair this page with tool-calling UI guidance when generated interfaces need to trigger external actions, approvals, or long-running tasks. For implementation, begin with a small catalog, validate every generated spec, and only then add retrieval over your component source so the agent can compose interfaces that match the real product design system.

Ask a question...