Role 4: Frontend Developer

The Excel Analogy

If you have designed a well-structured Excel workbook, you already understand the frontend concept intuitively. The role is building on that.

You have the raw data sheet (the database). You have the formulas and macros that process that data (the backend). Now you need the formatted, client-facing sheet — the one with the pivot table, the charts, the conditional formatting that turns negative numbers red, the clean layout with consistent headers that makes the data readable and actionable.

That sheet is the frontend.

The client-facing sheet does not store data permanently — it pulls from the raw sheet. It does not do heavy calculations — it displays the results of calculations done elsewhere. Its entire job is to present information clearly and let the right people interact with it in the right ways.

In software, the Frontend Developer builds the screens, forms, buttons, and visual elements that users interact with. Everything runs in the user's browser or phone — it is what they see and touch. It pulls data from the backend (the raw sheet) and displays it.

What This Role Builds

Pages and screens — every distinct view in the application:

• The home page
• The login screen
• The fee payment form
• The student's attendance history calendar
• The teacher's class roster showing all students and today's attendance status

Components — the reusable building blocks that make up those pages:

• A button (used everywhere — one definition, consistent behavior)
• A fee record card (shows fee name, due date, amount, status — used in the parent app fee list)
• A status badge (color-coded pill showing "Paid" or "Overdue")
• A loading skeleton (shown while data is fetching)

The frontend developer builds every state of every component. Loading (animated skeletons while the database responds), with data (real rows with color-coded status badges), and empty (a message that tells the user what to do next — not just a blank area). All three are the Frontend Developer's responsibility.

Interactions — what happens when users do things:

• Filling a form: validation feedback appears as they type
• Clicking "Book Now": button shows a loading state, then success or error
• Pulling to refresh on mobile: the list updates with new data
• Navigating between pages: the URL changes, the right content appears

Data fetching — getting information from the backend to display:

• Loading the list of available services when the page opens
• Fetching the user's fee payment history
• Showing the logged-in user's name in the header

The Technology Stack (Our Frontend)

You do not need to memorize these now. You will learn them by using them. What you need to understand is that these tools exist so you do not build everything from scratch — you compose existing building blocks into your specific application.

React: The Core Idea

React is built around one concept: components.

A component is a reusable piece of UI. Think of it as a named cell style in Excel — you define it once, you apply it everywhere, and if you change the definition, every instance updates.

You do not need to write this yet. You need to understand what it is: a reusable template for displaying one fee record. Once defined, you use <FeeCard feeRecord={someFeeRecord} /> anywhere in the app and it looks identical everywhere.

This is the power of components. Build it once, use it everywhere, change it in one place.

Concrete Examples — Frontend Decisions

When You Are in This Role

Put on the Frontend Developer hat:

• When you are writing React components
• When you are styling with Tailwind
• When you are wiring up a form to submit data
• When you are connecting a page to its data source (React Query)
• When you are handling what happens on success, error, and loading
• When you are making a page work on mobile and desktop

Common Mistakes When You Skip This Role Properly

Components that are too large. One component that does everything — it fetches data, processes it, renders the layout, handles the form, manages its own state, and shows error messages. When something breaks, you cannot tell where the problem is. When a similar screen needs building, you cannot reuse anything.

No loading states. The page shows nothing while data fetches — or worse, it crashes because it tried to display data before it arrived. Every data-dependent screen needs three states: loading, error, and success with data. The Frontend Developer handles all three.

No error handling on forms. The user fills a form incorrectly. The form submits. The backend rejects it. The user sees a blank screen or a raw error message. The Frontend Developer writes the error handling that shows human-readable feedback.

Hard-coded values in components. You build a status badge that says Confirmed in green. Hard-coded. Later, statuses change or expand. You have to find every place you wrote Confirmed and change it. Better: the component receives the status as a prop and the color mapping is defined once.

Ignoring mobile. You build the desktop layout beautifully. On a phone, text overflows, buttons are too small to tap, and the layout breaks. Always check on mobile.

How Claude Code Helps in This Role

The Frontend Developer role is where Claude Code is most powerful. It can write correct, production-quality React components from a clear description.

Generate a complete page:

"Create a React page for a parent's fee payment flow. Step 1: parent sees a list of their child's pending fee records. Step 2: they select one and see the full details. Step 3: confirmation screen showing the fee breakdown. Step 4: success screen after payment. Use shadcn/ui components, Tailwind CSS, and React Query for data fetching."

Build a specific component:

"Create a FeeCard component in TypeScript. It receives a fee record object with: id, fee_name, due_date, amount, status (pending | paid | overdue). Show all fields. Color-code the status badge: pending = yellow, paid = green, overdue = red. Show a 'Pay Now' button for pending and overdue records, and 'View Receipt' for paid ones."

Add loading and error states:

"This component fetches fee records for a student using React Query. Add: a skeleton loading state while data loads, an error message with retry button if the fetch fails, and an empty state if there are no fees due."

Fix a specific problem:

"My attendance calendar is not showing the correct month when I navigate back using the left arrow. Here is my current component code: [paste code]. What is wrong and how do I fix it?"

What to check in Claude's output:

• Does it handle loading, error, and empty states?
• Are TypeScript types correct?
• Does it work on mobile (responsive)?
• Are there any any types or useEffect for data fetching? (Both are problems)

How to Switch Into This Role

Before building any screen, say:

"The data design is done. The product scope is defined. Now I am building the layer that real users touch. My job is to make this clear, fast, and impossible to misuse."

Then for each screen, define before writing any code:

1. What data does this screen need? (React Query query)
2. What can the user do on this screen? (actions/mutations)
3. What does the screen look like in each state: loading / error / empty / with data?
4. What happens when each action succeeds? What happens when it fails?

Exercise

Open the Udyogaseva codebase at S:\Client Projects\012601 Udyogaseva. Navigate to any page in the candidate section (the screens a job seeker would see).

Look at one component file and answer:

Do not try to understand every line. Look for the structure: data → states → display → actions. That structure is in every well-built React component. Once you can see it, you can build it.