Q426: Implementation Drill Shipping TypeScript Feedback Panel

What Interviewers Want To Evaluate

This drill tests whether you can ship a focused TypeScript learning improvement without turning the practice ground into a full IDE.

The practice console already runs TypeScript by transpiling it before execution.

The missing piece is learner clarity.

Users need to know whether TypeScript accepted the code before they interpret runtime output.

Short Interview Answer

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

The panel should show ready, checking, compiled, and error states.

Compile or transpile failures should stop execution and appear in this panel.

Runtime logs should stay in the console.

The first slice should focus on classification and copyable feedback, not inline diagnostics or a full editor engine.

Why This Is The Right Slice

The previous console safety work made runtime output more reliable.

Now the TypeScript path needs a clearer pre-runtime step.

TypeScript practice has two phases:

source is checked or transpiled
generated JavaScript is executed

Learners should not have to infer which phase failed.

The UI should make the phase explicit.

Panel Scope

Include:

ready state
checking state
success state
error state
copy feedback action
TypeScript-only rendering
dark-mode readable styling

Skip:

inline squiggles
hover tooltips
multi-file type context
compiler option editor
diagnostic grouping
language server integration

The scope is intentionally narrow.

It improves learning clarity without creating a maintenance sink.

State Model

Use an explicit state:

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

This avoids ambiguous booleans such as hasError and isReady.

The renderer can map each state to a clear label.

The copy button can copy exactly the current message.

Execution Behavior

Flow:

user clicks run
set feedback to checking
transpile TypeScript
if transpile succeeds, set feedback to compiled
run JavaScript in worker
if transpile fails, set feedback to error and stop

The console should not show stale runtime output after a compile failure.

The system run line can explain that execution stopped before runtime.

Copy Behavior

The feedback panel should have its own copy action.

Copy targets remain separate:

copy code
copy TypeScript feedback
copy runtime console

This is useful because a learner may paste a type feedback message into notes or ask for help without including runtime logs.

Clear copy targets are small, but they reduce friction.

Visual Design

Use a compact status strip.

The panel should be visible without pushing the editor too far down.

It should use the existing design language:

8px radius
token-based panel background
accent border for status
muted explanatory text
compact button
no card inside card

The panel should feel like part of the workspace, not a marketing callout.

QA Plan

Verify:

TypeScript page shows feedback panel
JavaScript page does not show feedback panel
valid TypeScript moves from checking to compiled
invalid TypeScript moves to needs attention
copy feedback works
runtime output stays in console
dark mode contrast is readable
mobile layout does not crowd the editor

These checks prove the first slice.

Common Mistakes

• Rendering an empty TypeScript panel on JavaScript pages.
• Mixing compile feedback into runtime logs.
• Making the panel too large.
• Using color without text labels.
• Forgetting copy support.
• Marking runtime errors as TypeScript errors.

Final Mental Model

The feedback panel should answer:

did TypeScript accept this code
what should the learner inspect next
can this feedback be copied
is runtime output separate

That is enough for a strong first implementation.