Frontend Standard Operating Procedure (SOP)

1. Task Onboarding & Requirement Analysis

• Assignment: Tasks are officially initiated once assigned by the Project Manager (PM) or the Lead.
• Initial Audit: Before writing code, you must understand the task requirements in full.
• Communication Loop:
  • Business Logic: If the "why" or the requirement is unclear, reach out to the PM.
  • Technical Implementation: If you need help with "how" to implement a feature, reach out to the Lead.
• Open Door Policy: Communication is key. Never hesitate to ping the Lead or PM on public channels or via DM. We are always ready to help.

2. Technical Stack & Development Standards

Our core stack is Next.js and TypeScript.

A. Rendering & Data Fetching

• SSR Priority: Always prioritize Server-Side Rendering (SSR) and Server Components.
• Client-Side Fetching: Use client-side API fetching only when absolutely necessary (e.g., highly interactive real-time UI).
• Prop Drilling vs. Fetching: If a Client Component requires API data, fetch it in a Server Parent Component and pass the data down as props.

B. Component & Code Architecture

• Strict Reusability: Components should be as reusable as possible. Do not repeat logic or UI patterns.
• De-bloating: Do not bloat code into a single file. Break large components into smaller, manageable sub-components.
• Naming Conventions:
  • Files & Folders: Use kebab-case (e.g., user-profile-header.tsx).
  • Components: Use PascalCase for the component definition inside the file (e.g., export const UserProfileHeader = ...).
• Existing Patterns: Always follow the existing folder structure. If in doubt, look at established patterns in the /app directory.

C. TypeScript Implementation

• Strict Typing: Always use TypeScript. JavaScript is not allowed unless there is a strictly unavoidable technical reason.
• No 'any': Do not use any to bypass errors.
• Type Imports: Import types from GraphQL schemas or use the Utility functions provided by our GraphQL library. Reference existing implementations for examples or ask the Lead.

3. Git Workflow & Branching

• Branch Naming: Follow the format type/what-is-being-done.
  • Example: feature/user-authentication or fix/navigation-bar-padding.
  • Note: Do not include ticket information or IDs in branch names.
• Pull Requests (PR):
  1. Open a PR once your feature or fix is ready.
  2. Request a Review from the Lead.
  3. The Lead will review the code and either merge it or request specific changes.

4. Deployment & Production Support

• Deployment: Only the Lead is authorized to deploy code to production environments.
• Production Issues: If you notice an issue in production, notify the Lead ASAP.
• Incident Response: * Depending on severity, the Lead will either take direct action or assign you the fix.
  • RCA (Root Cause Analysis): If the issue originated from a feature you worked on, you must perform an RCA. Provide the cause to the Lead, who will report to higher management if necessary.