Skip to content

_template.md

Latest commit

 

History

History
100 lines (77 loc) · 3.73 KB

_template.md

File metadata and controls

100 lines (77 loc) · 3.73 KB
Raw
sidebar_position 1
description One line for section cards and search results
tags
middle

Term or Question as It Is Asked in an Interview

The model answer: 2–4 sentences or a short list that can be read at a glance and said out loud. Key terms are in bold. Everything between the title and the first ## heading is the short answer. Keep it under about 100 words or one table.

Applies to: React 19.3.

Applies to names the library version the page was checked against; pages that do not depend on a version leave it out.

Every page has level tags, one or two of:

  • junior — asked at the first screening; expected of anyone who has worked with the technology;
  • middle — expected of any working developer who uses it daily;
  • senior — design trade-offs and internals; usually only the follow-ups go this deep.

Browser support and release dates ("since Safari 26") age quickly: at most one line in Details, never in the short answer or the follow-up questions.

Library bugs, behavior that differs from the library's docs and "fixed in version X" change with the next release, and the page would not. A page names them only in general terms, with the advice that works ("not every core component passes every aria-* prop on; if one has no effect, use its accessibility* form"): no versions, no upstream issues or PRs. The details belong in an upstream issue, not on the site: a post about a current bug goes stale with the fix, so Field Notes takes no new ones.

The "checked on a device" marks on keyboard and accessibility link to the Field Notes posts of 27 October. With no new posts, a new mark needs a decision on what it links to first. The existing ones look like this:

<CheckedOnDevice
  platform="Android"
  version="16"
  date="2026-10-21"
  note="/field-notes/keyboard-avoiding-view-android-edge-to-edge"
/>

Details

What stands behind the short answer: how it works, edge cases, comparison tables. Lists instead of paragraphs. One topic per page — if a second topic appears, it is a separate page and a link.

Example

// One minimal example that has actually been run.
// The language of the code block matches its content.

Mark lines in code blocks wherever it applies:

  • // error-next-line or // error-start … // error-end — a red line: code that throws, does not compile, or compiles but is the wrong way. Keep the error message, copied from the compiler or the console, in a comment next to it; if the code compiles, say in the comment why it is wrong.
  • // correct-next-line or // correct-start … // correct-end — a green line: the right way, only as the counterpart of a red line in the same block.
  • // highlight-next-line, // highlight-start … // highlight-end or {1,3-4} after the language — the key line or lines of an example, usually one per example.
  • title="path/to/file.ts" after the language — for a block that is a whole file or a config (tsconfig.json, app/page.tsx).
  • The comment style follows the language: {/* error-next-line */} inside JSX, /* … */ in CSS, # in bash. Magic comments are removed from the output.
  • A wrong line is not commented out: it is marked and left as code, even if it would throw and stop the rest of the example when run.
let score = 100;
// error-next-line
score = 'high'; // Error: Type 'string' is not assignable to type 'number'.

Follow-up Questions

  • What does an interviewer ask next? The question and a one-line answer in one item, or a link to the page that answers it.
  • Follow-ups add something new; they don't restate Details.

Common Mistakes

  • Typical wrong or incomplete answers and why they are wrong.

See Also