Q424: Implementation Drill TypeScript Feedback Panel Design Spec

What Interviewers Want To Evaluate

This drill tests whether you can design the next TypeScript practice slice before writing it.

The console now has stronger runtime behavior.

The next improvement is separating TypeScript feedback from runtime output.

A good spec keeps the implementation small and reviewable.

Short Interview Answer

I would add a compact TypeScript feedback panel only on the TypeScript practice page.

It should show idle, transpiling, success, and error states.

Compile or transpile errors should stop runtime execution and appear in that panel.

Runtime logs and runtime errors should stay in the console.

The first version should avoid complex compiler exploration and focus on clear classification.

Product Problem

TypeScript learners need to answer two questions:

Did TypeScript accept this code?
What did the resulting JavaScript do?

If both answers are mixed into the console, debugging becomes harder.

The learner may fix runtime logic when the problem is actually type feedback.

Or they may chase type feedback when the runtime behavior is wrong.

The UI should separate the two.

First Version Scope

Include:

feedback panel on TypeScript page
idle state
transpiling state
success state
error state
copy feedback text later
clear or replace feedback on next run

Skip:

full Monaco editor
inline squiggles
language server
multi-file projects
type hover cards
advanced diagnostics table

This is a learning studio, not a complete IDE.

State Shape

Use an explicit state:

type TypeScriptFeedback =
  | { status: "idle"; message: string }
  | { status: "transpiling"; message: string }
  | { status: "success"; message: string }
  | { status: "error"; message: string };

This shape avoids scattered booleans.

It also makes rendering readable.

Execution Rules

For TypeScript:

set feedback to transpiling
call transpile endpoint
if it fails, set feedback error and stop
if it succeeds, set feedback success and run output
console receives only runtime output

For JavaScript:

do not render TypeScript feedback panel
run code directly
console receives runtime output

The pages share runtime safety, but not compile feedback.

Visual Design

The panel should be compact.

It can sit between editor shortcuts and the editor grid or inside the TypeScript editor panel.

It should use the same card radius, tokens, and typography as the rest of the app.

States can be indicated with text and color:

Ready
Checking TypeScript
TypeScript compiled
TypeScript needs attention

Do not rely only on color.

Error Copy

A later first follow-up can add:

copy TypeScript feedback
copy console output
copy code

Keep targets separate.

This matters because a learner asking for help with a type problem should not paste unrelated runtime logs.

QA Script

Check:

valid TypeScript shows success
invalid TypeScript shows feedback error
invalid TypeScript does not run old JavaScript
runtime error still appears in console
JavaScript page has no TypeScript panel
dark mode status cards are readable
mobile layout remains compact

This is enough for the first version.

Common Mistakes

• Building a full IDE before the learning workflow needs it.
• Showing TypeScript errors inside runtime console only.
• Running stale JavaScript after transpile failure.
• Forgetting JavaScript page should stay simpler.
• Using color-only status.
• Making the feedback panel larger than the editor.

Final Mental Model

The TypeScript feedback panel should provide:

classification
compact guidance
runtime separation
copy-ready artifacts
small scope

Build the boundary first.

Depth can come after the workflow is clear.