Code Review Checklist for Reactjs

Standard Operating Procedure: Code Review Checklist for ReactJS

Document Identifier: SOP-ENG-RCT-402
Classification: Enterprise Engineering Standards

1. Document Control & Revision History

2. Executive Summary & Scope

2.1 Clinical Statement of Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory governance, verification sequence, and structural requirements for all ReactJS code reviews across enterprise software deployments. The operational boundaries of this SOP apply universally to all frontend repositories utilizing React 16.8+ (Functional Components and Hooks architecture), TypeScript, state management libraries (Redux Toolkit, Zustand, React Query), and component styling systems (Tailwind CSS, Styled Components).

2.2 Regulatory Standards & Compliance

Adherence to this SOP ensures compliance with:

• WCAG 2.1 AA (Web Content Accessibility Guidelines) for digital accessibility.
• OWASP Top 10 (specifically XSS, broken authentication, and insecure deserialization safeguards).
• SOC 2 Type II requirements for traceability, change management, and secure software development life cycles (SDLC).

3. Prerequisites & Tool Requirements

Engineers performing code reviews must possess active provisioning for and proficiency with the following toolchain:

• Integrated Development Environment (IDE): VS Code with strict ESLint, Prettier, and TypeScript language server integrations.
• Version Control: GitHub Enterprise / GitLab Ultimate with branch protection rules enforced (minimum 2 peer approvals, status checks passing).
• Static Application Security Testing (SAST): SonarQube, Snyk, or Semgrep integrated into the CI/CD pipeline.
• Browser DevTools: React Developer Tools (Profilers enabled) and Lighthouse CLI for performance auditing.
• Access & Certifications: Internal Enterprise React Architecture Certification (ERC-L2) or equivalent peer-review authorization.

4. Roles & Responsibilities (RACI Matrix Table)

• Responsible (R): The role that performs the activity (authoring or conducting the line-by-line review).
• Accountable (A): The role with final approval authority and sign-off accountability.
• Consulted (C): Subject matter experts providing input on security, performance, or testing.
• Informed (I): Stakeholders kept up to date on deployment status.

5. Step-by-Step Operational Procedure

Execution requires sequential completion of the following four operational phases. Each step must be verified using the interactive checklist checkboxes.

Phase 1: Architectural & State Management Audit

• 1.1 Component Granularity: Verify that components do not exceed 250 lines of execution logic. Monolithic components are decomposed into pure presentation and smart container layers.
• 1.2 Hook Isolation & Rules: Ensure all custom hooks follow the use naming convention and strictly adhere to the Rules of Hooks (no conditional hook execution).
• 1.3 State Minimization: Confirm local component state (useState) is strictly limited to UI-local concerns; global or server state is delegated to React Query / Zustand / Redux.
• 1.4 Prop Drilling Elimination: Verify that prop drilling does not exceed a depth of 2 levels; Context API or state selectors are utilized appropriately.

Phase 2: Performance & Rendering Optimization

• 2.1 Referential Equality: Verify that objects, arrays, and inline functions passed as props to memoized child components (React.memo) are wrapped in useMemo or useCallback to prevent spurious re-renders.
• 2.2 Effect Dependency Arrays: Audit all useEffect and useCallback/useMemo dependency arrays. Ensure zero missing variables and no unnecessary mutations causing infinite loops.
• 2.3 Code Splitting & Lazy Loading: Confirm route-level and heavy modal components implement React.lazy() coupled with <Suspense fallback={...}>.
• 2.4 Virtualization: Ensure lists exceeding 50 items utilize virtualization libraries (@tanstack/react-virtual or react-window) to maintain 60 FPS scrolling performance.

Phase 3: Security & Data Sanitization

• 3.1 XSS Prevention: Verify that dangerouslySetInnerHTML is strictly avoided; if mandatory, ensure explicit DOMPurify sanitization is applied.
• 3.2 Input Sanitization & Validation: Confirm all user inputs handled by controlled components undergo schema validation via Zod or Yup prior to API submission.
• 3.3 Dependency Vulnerabilities: Review package lock files (package-lock.json / pnpm-lock.yaml) to ensure no high-severity vulnerabilities are introduced by new third-party dependencies.
• 3.4 Token Management: Ensure sensitive tokens (JWT, API keys) are never stored in localStorage or sessionStorage; memory-only storage or HTTP-only cookies are enforced.

Phase 4: TypeScript, Testing, & Accessibility (A11y)

• 4.1 Strict Typing: Verify complete absence of any or unknown type assertions without an explicit, documented inline justification override.
• 4.2 Test Coverage: Ensure unit and integration tests are written using Jest and React Testing Library, maintaining a minimum statement coverage threshold of 85%.
• 4.3 Accessibility Attributes: Confirm interactive elements possess explicit ARIA labels, semantic HTML tags (<button>, <nav>, <main>), and correct keyboard navigation handlers (tabIndex, onKeyDown).
• 4.4 Error Boundaries: Verify that data-fetching components and route boundaries are wrapped in robust React Error Boundaries to prevent full-tree unmounting crashes.

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist & Tolerance Thresholds

A pull request (PR) is rejected and returned to the author if it violates any of the following mandatory acceptance benchmarks:

• Zero ESLint/TypeScript Errors: Zero warnings or errors allowed from the build pipeline.
• Bundle Size Delta: New feature additions must not increase the initial JavaScript bundle chunk size by > 25KB uncompressed without architectural exception sign-off.
• Render Count Metric: React DevTools Profiler must show zero redundant renders on state updates outside the targeted component subtree.
• Lighthouse Performance Score: Frontend views modified must maintain a minimum score of 90 across Performance, Accessibility, and Best Practices.

6.2 Sign-off Requirements

Final merge authorization requires:

1. Automated CI/CD pipeline green status (SAST, Unit Tests, E2E Cypress/Playwright suites).
2. Explicit GitHub approval from at least one designated Code Owner (Accountable Role).

7. Practical Troubleshooting Scenarios

Scenario 1: Infinite Render Loop Causing Browser Hang

• Symptom: Application freezes or throws a maximum update depth exceeded error (RangeError: Maximum call stack size exceeded) immediately upon mounting a specific component.
• Root Cause: An useEffect hook modifies a state variable that is simultaneously included in its dependency array without a conditional execution guard.
• Immediate Corrective Action Protocol:
  1. Revert or patch the offending useEffect block immediately.
  2. Extract the state setter updater function (e.g., setCount(prev => prev + 1)) to remove the dependency variable from the dependency array, OR restructure the logic to separate data-fetching triggers from state updates.
  3. Run local unit tests verifying render counts via @testing-library/react.

Scenario 2: Memory Leak on Unmounted Component Async Operations

• Symptom: Console warning in development: "Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak."
• Root Cause: An asynchronous fetch request or timer resolves after the user has navigated away or closed the component, attempting to call setState.
• Immediate Corrective Action Protocol:
  1. Implement an active cancellation token (e.g., AbortController for fetch/Axios requests) inside a useEffect cleanup return function.
  2. Alternatively, introduce a local boolean flag (let isMounted = true; set to false in cleanup) to guard state setters.
  3. Verify cleanup execution by unmounting the component during an active network request in Network Throttling mode.

Scenario 3: Stale Closures in Custom Data-Fetching Hooks

• Symptom: A callback function inside a custom hook consistently reads outdated state values despite subsequent updates across user interactions.
• Root Cause: The function closes over variables from an initial render scope and lacks updates due to omitted dependencies in useCallback.
• Immediate Corrective Action Protocol:
  1. Audit the useCallback or useEffect dependency array and include all referenced reactive values.
  2. If capturing changing state values without triggering re-execution is intentional, refactor to utilize the useRef hook to maintain a mutable current reference of the value.
  3. Run integration tests validating asynchronous state consistency.