Frontend Code Review

Notes when using this skill:

• Always include actionable fixes or suggestions (including possible code snippets).
• Use File:Line references when a file path and line numbers are available; otherwise, use the most specific identifier you can.
• The Langflow frontend uses React 19, TypeScript 5.4, Vite 7 with SWC, Zustand for state management, TanStack React Query for server state, @xyflow/react v12 for graph visualization, Radix UI + shadcn-ui components, Tailwind CSS v3, and Biome for linting/formatting.

Checklist

• Code quality: For any reviewed file, follow references/code-quality.md to check styling conventions, TypeScript usage, Biome compliance, and component patterns.
• Performance: If the review scope involves React components, hooks, Zustand stores, React Query usage, or @xyflow/react node rendering, follow references/performance.md to check for re-render issues, memoization, and data flow patterns.
• Business logic: If the review scope involves custom nodes (GenericNode), flow state, API calls, the component system, global variables, or the inspection panel, follow references/business-logic.md to check for Langflow-specific correctness.

General Review Rules

1. Security Review

Check for:

• XSS vulnerabilities (dangerouslySetInnerHTML, unescaped user input)
• Sensitive data exposure in client-side code
• Insecure direct object references in API calls
• Hardcoded secrets, tokens, or API keys

2. Accessibility Review

Check for:

• Missing aria labels on interactive elements
• Keyboard navigation support
• Proper use of semantic HTML elements
• Color contrast issues in custom styling

3. Code Quality Review

Check for:

• Code duplication (DRY violations — extract at 3+ identical usages)
• Functions/components doing too much (SRP violations — if you need "and" to describe it, split it)
• Deep nesting or complex conditionals (prefer early returns and guard clauses)
• Magic numbers/strings without named constants
• Poor naming: generic names (data, result, temp), missing verb prefixes on functions, missing is/has/can/should prefixes on booleans
• Missing error handling or error boundaries
• Incomplete TypeScript type coverage (no any, no as any casts)
• Comments that explain WHAT instead of WHY
• Commented-out code (use version control)
• Boolean parameters that switch component behavior (use two components instead)
• Mutable patterns where const or immutable alternatives exist
• Production files exceeding ~500 lines (red flag at 600+)
• console.log in production code (Biome flags this)

4. Testing Impact Review

Check for:

• Changes to data-testid attributes that may break E2E tests
• Modified component interfaces that require test updates
• New interactive elements missing data-testid attributes

5. Pre-Commit Verification

For pending-change reviews, verify:

• npm run format (Biome formatter) — zero diffs
• npm run lint (Biome linter) — zero errors
• npm test (Jest) — zero failures

Required Output Format

When this skill is invoked, the response must exactly follow one of the two templates:

Template A (any findings)

# Code Review

Found <N> urgent issues that need to be fixed:

## 1. <brief description of issue>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each urgent issue) ...

Found <M> suggestions for improvement:

## 1. <brief description of suggestion>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each suggestion) ...

• If there are no urgent issues, omit that section. If there are no suggestions, omit that section.
• If the issue count exceeds 10, summarize as "10+ urgent issues" or "10+ suggestions" and output only the first 10 items.
• Do not compress the blank lines between sections; keep them as-is for readability.
• If Template A is used (there are issues to fix) and at least one issue requires code changes, append a brief follow-up question after the structured output asking whether the user wants the suggested fixes applied. For example: "Would you like me to apply the suggested fixes to address these issues?"

Template B (no issues)

## Code Review

No issues found.