frontend-code-review

# Frontend Code Review ## When to use this skill Use this skill whenever the user asks to **review, analyze, or improve** frontend code (`.tsx`, `.ts`, `.js` files) under the `src/frontend/` directory. Supports the following review modes: 1. **Pending-change review** -- inspect staged or working-tree files slated for commit and flag checklist violations before submission. 2. **File-targeted review** -- review the specific file(s) the user names and report the relevant checklist findings. Do NOT use this skill when: - The request is about backend code (`.py` files under `src/backend/`). - The user is not asking for a review/analysis/improvement of frontend code. - The scope is outside `src/frontend/` (unless the user explicitly asks to review frontend-related changes elsewhere). ## How to use this skill Follow these steps when using this skill: 1. **Identify the review mode** (pending-change vs file-targeted) based on the user's input. Keep the scope tight: review only what the user provided or explicitly referenced. 2. Follow the rules defined in the **Checklist** to perform the review. If no checklist rule matches, apply **General Review Rules** as a fallback. 3. Compose the final output strictly following the **Required Output Format**. 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](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](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](references/business-logic.md) to check for Langflow-specific correctness. - **i18n**: If the diff adds or changes user-facing text (labels, buttons, tooltips, modals, toasts, errors, placeholders, aria-labels), follow the [frontend-i18n skill](../frontend-i18n/SKILL.md): no hardcoded UI strings — everything through `t(...)` — and every new key present in **all** locale files (`src/frontend/src/locales/*.json`). ## 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) ```markdown # 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) ```markdown ## Code Review No issues found. ```