Programmatically create and append a div in TypeScript
Tests TypeScript DOM typing and safe element creation. Strong answers name HTMLDivElement and Document, use createElement plus classList.add and textContent, then append. Red flag: innerHTML for text or avoiding specific types.
What's really being asked
This question probes your fluency with the DOM API in a TypeScript context, specifically whether you know the concrete DOM interfaces involved rather than falling back on generic any types. It checks if you understand the type hierarchy, safe mutation patterns, and the difference between modern and legacy insertion methods.
The full answer
A strong answer walks through four steps in order. First, you reference an existing parent element, typically typed as HTMLElement or Element. Second, you call document.createElement with the tag name div, which TypeScripts lib.dom.d.ts overloads to return a specific HTMLDivElement rather than a generic Element. Third, you mutate the new node by adding a CSS class via classList.add or the className property, and you set its text using textContent instead of innerHTML to avoid XSS risks and unnecessary HTML parsing. Fourth, you insert the node into the tree using parent.append or parent.appendChild, noting that append accepts multiple arguments including strings while appendChild returns the appended node. Throughout, you explicitly name the DOM types: Document for the document object, HTMLDivElement for the created div, and HTMLElement or Element for the parent.
The mistakes people make
Red flags include using innerHTML to inject plain text, which is a security anti-pattern and slower than textContent. Another warning sign is typing the created element as any or generic Element instead of HTMLDivElement, showing a lack of familiarity with TypeScripts built-in DOM typings. Confusing the Node, Element, and HTMLElement hierarchy is also problematic, such as insisting the parent must be an HTMLElement when Element suffices. Finally, using innerText instead of textContent without understanding the performance and visibility differences, or suggesting jQuery-style HTML string insertion when the question asks for programmatic node creation.
What usually comes next
Expect the interviewer to ask why textContent is preferred over innerHTML or innerText. They may also ask about the difference between append and appendChild, including return values and whether strings can be passed. A deeper TypeScript question might be how createElement knows to return HTMLDivElement, which leads into discussing lib.dom.d.ts overloads. You might also be asked how to optimize creating many elements, which is a chance to mention DocumentFragment to minimize reflow.
A concrete example
Here is a concise TypeScript snippet. const parent = document.getElementById('container') as HTMLElement; const div = document.createElement('div'); div.classList.add('status'); div.textContent = 'Connected'; parent.append(div); In this block, document is typed as Document, div is HTMLDivElement, and parent is HTMLElement.
Interview question
When creating a div in TypeScript and setting its plain text, which approach combines the precise DOM interface with the safest property assignment?
- a.const div: HTMLDivElement = document.createElement('div'); div.textContent = 'Hello';Correct
- b.const div: HTMLDivElement = document.createElement('div'); div.innerText = 'Hello';
- c.const div: Element = document.createElement('div'); div.innerHTML = 'Hello';
- d.const div = document.createElement('div') as any; div.textContent = 'Hello';
Why? this is the answer
TypeScript overloads createElement('div') to return HTMLDivElement, and textContent is preferred over innerHTML for plain text to avoid XSS and unnecessary parsing. Option B is tempting because innerText looks equivalent, but it triggers style recalculation and differs in behavior, while Option D defeats TypeScript's type safety by using any.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #typescript
- #dom
- #web apis
- #html elements
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles