Built by

leo3

Computer Science

Live Skill Radar: From Finance Data to a Production-Ready React App

You will turn your existing React full-stack work into a live radar dashboard that shows skill strengths across projects and changes whenever new work logs arrive. We will use the React and HTML foundations you already have, strengthen the weak spots that block you today, and build toward the kind of clear data flow, API design, validation, and deployment thinking expected in FAANG interviews and real products.

7 modules24 lessonsComputer Science

What you learn by building this

Build it yourself, get guided when you are stuck, and leave with proof you can actually show.

Learning Journey

Make the Existing App a Reliable Dashboard Shell

3 lessons

Stabilize the current React project before adding new complexity. The finished shell will already show project cards, a selected project, and a clear place for the radar chart and activity feed.

Model Skills, Projects, and Work Logs

4 lessons

Create the data model that makes the radar meaningful. The dashboard will stop depending on scattered UI values and will render from one explicit set of projects, skills, scores, and work-log records.

Render the Radar Chart from First Principles

3 lessons

Turn the calculated skill values into a readable radar chart without hiding the core geometry behind a charting abstraction. The project will now have its defining visual and will update immediately when the selected project or local data changes.

Create the Work-Log API

4 lessons

Cross the backend bridge gradually: first define the request and response shape, then add a small Express API, and only afterward replace the local source. The radar will be fed by real HTTP data while the learner gains the API and Express practice currently missing.

Make New Work Logs Safe and Useful

4 lessons

Turn the happy-path demo into a trustworthy application. Invalid logs will be rejected consistently, valid submissions will update the activity feed and radar, and the interface will explain what is happening instead of silently failing.

Persist Data and Separate Application Layers

3 lessons

Move beyond a reset-on-restart demo and make the data flow easier to maintain. The completed module will preserve work logs locally through the server’s database layer and keep route, validation, calculation, and presentation responsibilities separate.

Ship a Demonstrable Full-Stack Project

3 lessons

Prepare the radar app for a portfolio walkthrough and a reliable local build. The final result will have a repeatable build process, a polished end-to-end demo path, and documentation that makes the technical decisions visible to a hiring team.

Public lesson

Audit the Current React App and Map the User Flow

Audit the React App and Map the User Flow

You already know basic React pieces. This time, don’t build a new component yet. Treat the app like an unfamiliar codebase at work: find where it starts, follow the data, and connect the code to what appears on screen.

Your target flow is:

select a project → view its radar → add a work log

Predict

What will happen?

Before opening the source files, look at the running app.

Write down:

What screen appears first?
Where would a user select a project?
What do you think changes when a project is selected?
Where might the “add work log” action live?

Use this small note:

Initial screen:
Project selection appears in:
Selecting a project probably changes:
Adding a work log probably opens or reveals:

Initial screen:
Project selection appears in:
Selecting a project probably changes:
Adding a work log probably opens or reveals:

Tasks

Now start the app using the existing script from package.json.

First inspect the scripts:

cat package.json

cat package.json

Run the script that looks like the development command, usually something like:

npm run <dev-script>

npm run <dev-script>

Open the local URL in your browser and click through the app without changing anything.

Check: Your prediction should now have at least one answer you can confirm or correct from the browser.

2. Find the real entry point

A React app normally has a small file that creates the React root and renders the first component. Find it instead of guessing.

Tasks

Look at the project structure:

find src -maxdepth 3 -type f | sort

find src -maxdepth 3 -type f | sort

Also search for the root-rendering code:

grep -R "createRoot\|ReactDOM.render" src

grep -R "createRoot\|ReactDOM.render" src

Open the file containing that code. Record:

Entry file:
Component passed to createRoot/render:
Other providers or wrappers:

Entry file:
Component passed to createRoot/render:
Other providers or wrappers:

You may see a shape similar to this:

createRoot(document.getElementById("root")).render(
  <Something>
    <App />
  </Something>
);

createRoot(document.getElementById("root")).render(
  <Something>
    <App />
  </Something>
);

Do not copy it. Identify what each wrapper is doing:

Is it adding routing?
Is it adding global state?
Is it adding a theme or styling system?
Is it only a fragment around the app?

Tasks

Check: You should be able to name the first component rendered by React and the file where that happens.

3. Trace the first render

Open the first component from the entry file. Follow its imports one level at a time.

Tasks

For each imported component that appears in the returned JSX, write one row:

Component	File	Why it is rendered	Props passed

Use the browser to confirm what each component corresponds to. A component name such as Dashboard, ProjectList, or RadarView is only a clue; the rendered UI is the evidence.

When you see JSX like this:

<ProjectCard
  project={/* value */}
  onSelect={/* function */}
/>

<ProjectCard
  project={/* value */}
  onSelect={/* function */}
/>

record:

ProjectCard receives a project
ProjectCard receives an onSelect
the parent is responsible for deciding what happens after selection

Tasks

When a prop is unclear, trace where it came from rather than guessing. For example, find the variable definition and then its source:

project
  came from:
  changed by:
  passed to:

project
  came from:
  changed by:
  passed to:

Check: Pick one visible project card or project selector and explain its parent-to-child path, for example:

Entry → App → ______ → ______

Entry → App → ______ → ______

Your path should match both the import tree and the browser.

4. Find the state that controls project selection

Search the source for likely state and event code:

Tasks

grep -R "useState\|useReducer\|selectedProject\|projectId\|onSelect" src

grep -R "useState\|useReducer\|selectedProject\|projectId\|onSelect" src

You are looking for two separate things:

Where the selected project is stored
Where a user action changes it

Fill this in from the actual code:

Selected-project state lives in:
State variable:
Initial value:
Setter/action:
User event that triggers it:
Component receiving the selected project:

Selected-project state lives in:
State variable:
Initial value:
Setter/action:
User event that triggers it:
Component receiving the selected project:

Pay attention to whether the app stores:

the entire project object, or
only a project ID

That distinction matters because it tells you where the app looks up the remaining project data.

Tasks

Now click a different project in the browser and observe what changes.

Check: Refresh the page. Does the selected project remain selected?

After refresh: remains / resets
Evidence:

After refresh: remains / resets
Evidence:

This tells you whether the selection is probably local React state, URL state, or persisted somewhere else. You do not need to change it.

5. Trace the radar screen

Find the component responsible for the radar. Search using visible text from the browser as well as likely names:

Tasks

grep -R -i "radar\|score\|skill\|axis\|chart" src

grep -R -i "radar\|score\|skill\|axis\|chart" src

Open the relevant component and answer:

Radar component:
Parent component:
Data prop name:
Shape of one radar data item:
What happens when there is no selected project:

Radar component:
Parent component:
Data prop name:
Shape of one radar data item:
What happens when there is no selected project:

Tasks

Look at the data before it reaches the chart or visualization component. Write a small example based on the real shape:

{
  label: "...",
  value: "...",
  // other actual fields:
}

{
  label: "...",
  value: "...",
  // other actual fields:
}

Do not invent field names. Copy the names from the code into your notes.

Then trace backward:

Radar chart receives data from:
That data is created or selected in:
The project data originally comes from:

Radar chart receives data from:
That data is created or selected in:
The project data originally comes from:

If the radar is rendered through a library, you do not need to understand the library internals. Your job is to identify the boundary:

application data → radar component → chart library

Tasks

Check: In the browser, select two different projects. Record whether the radar changes:

Project A:
Project B:
What changed:
Which prop or state value probably caused it:

Project A:
Project B:
What changed:
Which prop or state value probably caused it:

6. Trace the “add work log” action

Find the visible button, link, or form action for adding a work log. Search for text from the UI:

Tasks

grep -R -i "work log\|log work\|add log\|submit" src

grep -R -i "work log\|log work\|add log\|submit" src

Follow the action from the button to the result.

Record this chain:

Visible control:
Component containing it:
Click/submit handler:
State updated or function called:
Form fields:
Where the new log appears afterward:

Visible control:
Component containing it:
Click/submit handler:
State updated or function called:
Form fields:
Where the new log appears afterward:

Tasks

If the handler is passed as a prop, follow it to the parent:

<LogForm onSubmit={/* something */} />

<LogForm onSubmit={/* something */} />

Your notes should identify both sides:

Child component:
Prop used to send the new log upward:
Parent handler:
What the parent changes:

Child component:
Prop used to send the new log upward:
Parent handler:
What the parent changes:

Tasks

Look for whether the new log is:

added to local state,
sent to an API,
stored in context,
or only displayed temporarily

You can search for request code if necessary:

grep -R "fetch\|axios\|POST\|mutation" src

grep -R "fetch\|axios\|POST\|mutation" src

Do not repair missing behavior in this lesson. If the action fails, record where the flow stops.

Tasks

Check: Add one harmless test work log in the running app, if the form works. Then verify where it appears. If it fails, write the first visible error or the last handler you reached.

Explain it back

Put it in your own words

7. Write the current render flow

Now combine your findings into a short explanation. Use actual component and variable names from the project.

Fill in this structure:

The app starts in __________, where React renders __________.

__________ renders the main project screen. It gets project data from
__________ and passes __________ to __________.

When the user selects a project, __________ runs. It changes
__________, which causes __________ to render/update.

The radar is rendered by __________. It receives __________ from
__________, and the radar data has the fields __________.

To add a work log, the user interacts with __________. The action
calls __________, which changes/sends __________. The updated log
appears in __________.

The app starts in __________, where React renders __________.

__________ renders the main project screen. It gets project data from
__________ and passes __________ to __________.

When the user selects a project, __________ runs. It changes
__________, which causes __________ to render/update.

The radar is rendered by __________. It receives __________ from
__________, and the radar data has the fields __________.

To add a work log, the user interacts with __________. The action
calls __________, which changes/sends __________. The updated log
appears in __________.

Keep it to one or two paragraphs. If you cannot fill a blank, return to the source and trace one more level.

Check: Read your explanation while looking only at the browser. You should be able to point to the screen element corresponding to each major component.

20 more characters

Challenge

Think first, then write

8. Create the screen map

A screen map describes user-visible movement, not file structure. Make one for the target flow.

Use this format:

[Project selection screen]
  User action:
  Visible result:
  Important data:

        ↓

[Project radar screen]
  User action:
  Visible result:
  Important data:

        ↓

[Add work log screen/form]
  User action:
  Visible result:
  Important data:

[Project selection screen]
  User action:
  Visible result:
  Important data:

        ↓

[Project radar screen]
  User action:
  Visible result:
  Important data:

        ↓

[Add work log screen/form]
  User action:
  Visible result:
  Important data:

Tasks

Add the actual screen names used by this app. Include alternate states if they exist:

No project selected:
Loading:
Empty radar:
Submit success:
Submit failure:

No project selected:
Loading:
Empty radar:
Submit success:
Submit failure:

Tasks

Then create a second, code-oriented map underneath:

User action              Component              State/prop/API change
Select project           __________              __________
View radar               __________              __________
Submit work log          __________              __________

User action              Component              State/prop/API change
Select project           __________              __________
View radar               __________              __________
Submit work log          __________              __________

The first map explains the product flow. The second explains how the React code produces it.

Tasks

Final check: Your finished notes should answer these five questions without reopening the code:

Where does rendering begin?
Which component owns the selected project?
Which props carry project data into the radar?
How does the work-log form communicate its submission?
What does the user see after each of the three main actions?

Course Outline

7 modules · 24 lessons

Make the Existing App a Reliable Dashboard Shell

Model Skills, Projects, and Work Logs

Render the Radar Chart from First Principles

Create the Work-Log API

Make New Work Logs Safe and Useful

Persist Data and Separate Application Layers

Ship a Demonstrable Full-Stack Project

Learn by building your own version.

Remix this public project to open the workspace, follow the guided build, and let the AI mentor teach you through the work instead of doing it for you.