Overview
The Components module contains 252 reusable UI building blocks: Shadcn/ui primitives (buttons, dialogs, forms) and RAGFlow-specific components (graph canvas nodes, visual form builder). All components follow accessibility best practices and theme consistency via Tailwind CSS + localStorage-based theme switching.
🎨 Component Categories
Shadcn Primitives
src/components/ui/ — Copied from registry
Canvas Components
src/components/canvas/ — Graph node types
- NodeCard — Agent DSL node wrapper
- NodeInput/Output — Port definitions
- ContextMenu — Right-click canvas actions
- Controls — Zoom, pan, fit-view buttons
XyFlow Wrappers
src/components/xyflow/ — React Flow integration
- Canvas wrapper (initializes @xyflow/react)
- Node renderer with typed node registry
- Edge renderer with custom styling
- State sync: Zustand ↔ React Flow
RagFlow Form Builder
src/components/ragflow-form/ — Dynamic schema forms
- JSON schema → React form compiler
- Nested object/array fields
- Conditional field visibility
- Real-time validation with Zod
Layout Components
src/components/layout/ — App structure
- Sidebar navigation
- Header with theme toggle
- Modal/Drawer wrappers
- Breadcrumb navigation
Data Display
src/components/data/ — Tables & lists
- DataTable (sortable, filterable)
- VirtualList (1000+ rows)
- Card grid layouts
- Empty state components
📂 Component Organization
src/components/
├── ui/ # Shadcn primitives
│ ├── button.tsx
│ ├── dialog.tsx
│ ├── select.tsx
│ └── ... 17+ primitives
├── canvas/ # Graph node components
│ ├── NodeCard.tsx
│ ├── ContextMenu.tsx
│ └── Controls.tsx
├── xyflow/ # React Flow wrappers
│ ├── Canvas.tsx
│ ├── NodeRenderer.tsx
│ └── EdgeRenderer.tsx
├── ragflow-form/ # Dynamic form builder
│ ├── FormBuilder.tsx
│ ├── FieldRenderer.tsx
│ └── validators/
├── layout/ # App layout
│ ├── Sidebar.tsx
│ ├── Header.tsx
│ └── Modal.tsx
├── data/ # Tables & lists
│ ├── DataTable.tsx
│ ├── VirtualList.tsx
│ └── EmptyState.tsx
└── icons/ # Icon components (SVG wrapped)
🎨 Theming & Styling
Theme Key: All components use localStorage.neutra-ip-theme (values: "dark" or "light")
Tailwind CSS: Utility-first styling with custom theme configuration in tailwind.config.ts. CSS variables for colors injected at build time from src/styles/colors.less.
Dark/Light Toggle: Button in Header component; toggles data-theme attribute on <html>; CSS :root selector switches variable values.
:root {
--bg: #0d1117; /* Dark theme background */
--surface: #161b22;
--text: #c9d1d9;
--accent: #58a6ff;
}
[data-theme="light"] {
--bg: #ffffff;
--surface: #f6f8fa;
--text: #1f2328;
--accent: #0969da;
}
♿ Accessibility Standards
- WCAG 2.1 AA: Radix/Shadcn components inherit accessible defaults (ARIA roles, focus management)
- Keyboard navigation: Tab through buttons, dialogs, forms; Enter to activate
- Color contrast: Text meets 4.5:1 contrast ratio (checked with axe DevTools)
- Alt text: Images have descriptive alt= attributes
- Screen reader: Semantic HTML; aria-labels for icon-only buttons
Common Patterns
Form with Validation
// Use react-hook-form + zod
const { register, formState: { errors } } = useForm({
resolver: zodResolver(schema),
mode: 'onChange'
});
return (
<Input {...register('email')} />
{errors.email && <span>{errors.email.message}</span>}
);
Modal Dialog
const [open, setOpen] = useState(false);
return (
<>
<Button onClick={() => setOpen(true)}>Open</Button>
<Dialog open={open} onOpenChange={setOpen}>
<DialogContent>
<h2>Confirm</h2>
<Button onClick={() => setOpen(false)}>Close</Button>
</DialogContent>
</Dialog>
</>
);
Next Steps
- Browse Pages to see components in action
- Explore Services for data wiring patterns
- Deep-dive: API Data Layer for mutation/query integration
Components Module/{{SUBMOD_NAME}}/ — {{SUBMOD_TITLE}}
{{SUBMOD_PURPOSE}}
{{SUBMOD_DESC}}
📚 What is this & why does it exist?
{{SUBMOD_WHAT_WHY}} — Replace with 2-4 plain-English sentences explaining what this sub-module does and why it exists. No jargon. Target audience: someone who hasn't read the code.
💡 Real-world analogy
{{SUBMOD_ANALOGY}} — Replace with a vivid, concrete metaphor mapping this sub-module's core concept to everyday life (restaurant, airport, library, highway, etc.). 3-5 sentences.
🤔 Why Is It Designed This Way?
{{DESIGN_RATIONALE}} — 150+ words explaining the design choices: what pattern does this follow and why? What constraints shaped the implementation? What trade-offs were made and what was sacrificed?
| Design Choice | What Was Chosen | What Was Rejected | Why |
|---|---|---|---|
| Example: data layout | Array of structs | Struct of arrays | Random access pattern dominates; cache locality for single items matters more than SIMD sweeps |
Contents
Architecture
flowchart TD A["Component A"] --> B["Component B"] B --> C["Component C"] C --> D["Component D"]
Key Classes
| Class / Function | File | Purpose |
|---|---|---|
ClassName | file.h | Brief description |
Data Structures
| Type | Name | Description |
|---|---|---|
| enum | EnumName | Brief description |
Interactions
| Direction | Partner | Interface | Description |
|---|---|---|---|
| → | Other Module | methodName() | Brief description |
Configuration
| Knob / Parameter | Default | Description |
|---|---|---|
param_name | value | What it controls |
Directory Map
Source tree for {{SUBMOD_NAME}}
submod_name/
├── file_a.ext ← Role: brief annotation
├── file_b.ext ← Role: brief annotation
├── file_c.ext ← Role: brief annotation
└── index.ext ← Role: entry point
📑 Annotated Code Walkthrough
The most important code in this sub-module, annotated with WHY each piece exists:
{{KEY_FUNCTION_NAME}}
// Replace with actual code from the source
void key_function() {
// ← WHY: Explain the purpose of this line
// ← WHY: What constraint or requirement drives this?
}
Line-by-line:
- Line N: What this does and WHY — what would break if removed
- Line M: The design choice here — why this approach over the obvious alternative
⚠️ Edge Cases & Boundaries
| Edge Case | What Happens | Where in Code | Risk Level |
|---|---|---|---|
| Empty input | How it's handled | function_name:line | 🟢 Low |
| Concurrent access | How it's handled | function_name:line | 🔴 High |
Deep-Dive Highlights
Core mechanisms from this sub-module have been extracted into dedicated focus pages for in-depth exploration. Each page covers one algorithm, protocol, or subsystem with diagrams, code walks, and configuration details.
Deep-Dive Pages
Topic A Name Focus
Short description of what this focus page covers.
Topic B Name Focus
Short description of what this focus page covers.
Code Examples
Example: Typical Usage
// Replace with actual code example
void example() {
// ...
}