Strategies to type querySelector results as HTMLInputElement

WHAT THIS TESTS: Whether you understand that TypeScript's lib.dom.d.ts defines querySelector as returning Element or null, and that HTMLInputElement is a more specific interface extending HTMLElement. It checks if you can reconcile static types with runtime DOM reality, balancing convenience against safety.

A GOOD ANSWER COVERS: Two main strategies. First, a type assertion such as writing const el = document.querySelector('.my-element') as HTMLInputElement. The pro is that it is explicit and works with any selector string; the con is that it tells the compiler to trust you, so if the class is on a div or the element is missing, your code may crash at runtime. Second, using a generic type argument such as document.querySelector<HTMLInputElement>('.my-element'). The pro is that it avoids the as keyword and reads as a typed query; the con is that it still does not perform any runtime validation, and with class selectors the compiler cannot verify the relationship between the selector and the type parameter. A great candidate then adds that both approaches must be combined with a null check, for example if (!el) return, because querySelector can always return null if the element is absent. Some candidates also mention a third defensive strategy: using instanceof HTMLInputElement as a runtime type guard. This is the safest but most verbose approach, and it narrows the type inside the if-block without any casting.

COMMON WRONG ANSWERS: Claiming that the generic querySelector approach provides runtime type safety. It does not; it is purely a compile-time contract. Another red flag is asserting the type without first checking for null, leading to potential runtime errors on missing elements. Also, suggesting that getElementById returns HTMLInputElement directly is wrong; per lib.dom.d.ts it returns HTMLElement or null, so the same problem exists there.

LIKELY FOLLOW-UPS: How would you write a reusable helper that queries and validates an element type? When is it acceptable to use a non-null assertion operator instead of as? How do strictNullChecks change the ergonomics of DOM manipulation?

ONE CONCRETE EXAMPLE: Suppose you need to read the value of a search input. Using the generic approach: const input = document.querySelector<HTMLInputElement>('.search'); if (!input) throw new Error('Search input missing'); console.log(input.value);. Using the assertion approach: const input = document.querySelector('.search') as HTMLInputElement; console.log(input.value);. If the markup accidentally uses a div with class search, the generic code compiles but still fails at runtime when accessing .value; the assertion code does the same. The only truly safe version adds if (!(input instanceof HTMLInputElement)) throw new Error('Not an input');.