Tangy is building your next step
Shaping the lesson around what you want to make.
Tangy is building your next step
Shaping the lesson around what you want to make.
Computer Science
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.
Build it yourself, get guided when you are stuck, and leave with proof you can actually show.
Make the Existing App a Reliable Dashboard Shell
3 lessonsStabilize 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 lessonsCreate 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 lessonsTurn 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 lessonsCross 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 lessonsTurn 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 lessonsMove 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 lessonsPrepare 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
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:
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.
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:
Tasks
Check: You should be able to name the first component rendered by React and the file where that happens.
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 projectProjectCard receives an onSelectTasks
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.
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:
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:
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.
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:
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:
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
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
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:
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.