Three mistakes the compiler finds before the browser does
The program still runs: types are erased, so the console prints a number and then NaN (the typo gave undefined). The Types panel is where the mistakes show up. Rows [0] is DayRow | undefined because the panel's compiler settings include noUncheckedIndexedAccess.
Type the rows a chart reads, the scales it builds and the props it takes. The compiler then catches a misspelt field, a missing value and the wrong kind of scale before the page ever runs, at the price of a few annotations.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a generic Dots<T> props type for a scatter chart: rows T[], accessors x and y returning numbers, and id returning a string. Then call it with { minutes: number; km: number; id: string } rows.
Write extentOr(values: number[], fallback: [number, number]): [number, number] and say why it helps a scale.
Explain it without notes
Why is the row type the most useful type in chart code?
What does d3.max(rows, (d) => d.rides) return for an empty list, and how does strict mode make you handle it?
Why can a ScaleLinear not be passed where a ScaleTime is expected?
What does a type assertion (as) do, and why is it dangerous for data from a CSV?
Preview
Console
Nothing logged yet.Expected console output
25.525000000000006
NaN