Build a Runtime String Interpolation Function in TypeScript and Choose Its Error Policy

Design and implement, in TypeScript or JavaScript, a small library function that performs string interpolation at run time, in the spirit of JavaScript template literals. A template literal substitutes expressions from the surrounding code; the library instead receives an ordinary string containing `${name}` placeholders together with an object of values, and returns the string with each placeholder replaced. The report does not give the exact signature, so assume ```ts function interpolate(template: string, values: Record<string, unknown>): string; ``` so that `interpolate("Hello, ${name}!", { name: "Ada" })` returns `"Hello, Ada!"`. The implementation itself is of moderate difficulty; most of the discussion is about edge cases, and the interviewer asks you to decide, case by case, whether the function should throw an error or handle the input in some other way. ### Clarifying Questions - Which placeholder syntax must be supported: only `${name}`, dotted paths such as `${user.name}`, or arbitrary expressions? - Do the values always come from an object passed with the template, or from somewhere else? - How should a template express a literal `${` that must not be interpolated? - Who calls the library: trusted application code with templates written by developers, or end users supplying their own templates? That affects whether failures should be loud or lenient. ### Part 1 — Implement the core Implement the function so that each well-formed placeholder is replaced by the text of its value and all other characters are copied unchanged. ```hint Values that look like templates Consider what happens if a substituted value itself contains `${...}`, and whether your approach would expand it again. ``` #### What This Part Should Cover - A single left-to-right pass, or a carefully written regular expression, that finds placeholders - How a value is turned into text for strings, numbers and other types - No re-expansion of substituted values, no use of `eval`, and linear time in the template length ### Part 2 — Decide the edge-case policy For each malformed or unusual input, decide whether the function throws an error or does something else, and justify the design. ```hint List the inputs first Before choosing any policy, enumerate the ways the placeholder name, the braces and the value found for a name can be wrong or surprising. ``` ```hint Callers differ Ask whether one fixed behaviour suits every caller, or whether the caller should be able to choose. ``` #### What This Part Should Cover - An enumeration of edge cases: missing keys, `null` and `undefined` values, unterminated or empty placeholders, escapes, non-string values - A consistent, documented decision for each, with the reason for throwing or for a fallback - An API that lets callers choose strict or lenient behaviour, and error messages that locate the problem - Tests that pin each decision ### What a Strong Answer Covers - Agrees on the placeholder syntax and the source of values before coding - A correct single-pass implementation with no re-expansion and no `eval` - Deliberate, consistent decisions on missing values, malformed placeholders and escaping, explained in terms of who calls the library - Lookup of own properties only, so that names such as `constructor` or `__proto__` do not resolve to inherited members - Type definitions and tests that document the chosen behaviour ### Follow-up Questions - How would you support dotted paths such as `${user.address.city}` and array indexes? - How would you add formatting, for example `${price:currency}`, without changing how existing templates behave? - The same templates are rendered millions of times. How would you make repeated rendering faster? - How could TypeScript report a missing key at compile time when the template is a string literal?