Build a Follow-ups:
An open-ended live-coding prompt — clarify the scope first (it likely means a follow-ups/comments/replies thread or a follow-up tasks list). Then model the data, build a recursive or flat-with-parentId structure, handle add/edit/delete, and cover loading/empty/error and accessibility.
"Build a Follow-ups" is an under-specified prompt — the first move is to clarify scope, because "follow-ups" could mean a few different things:
- A threaded comments / replies widget (follow-up messages on a post or ticket).
- A follow-up tasks / action items list (e.g. after a meeting or a support case).
- Follow-up questions in a Q&A or interview-prep context.
Ask which one. Below assumes the most common: a threaded follow-ups/comments component.
1. Data model
// Flat + parentId scales better than deep nesting:
comments = {
'c1': { id: 'c1', parentId: null, author, text, createdAt },
'c2': { id: 'c2', parentId: 'c1', author, text, createdAt },
}Flat-with-parentId (normalized) makes add/edit/delete O(1) and avoids deep-nesting headaches; build the tree for rendering.
2. Rendering
- A recursive
<FollowUp>component: render the item, then map its children recursively. - Cap visual nesting depth (indent only so far; deeper replies flatten) — real apps do this.
- Memoize items so editing one doesn't re-render the whole tree.
3. Interactions
- Add — a reply form per item + a top-level form. Optimistic insert, then persist.
- Edit — inline edit mode, optimistic update.
- Delete — confirm; decide what happens to children (delete subtree, or show "[deleted]" tombstone keeping replies).
- Collapse/expand threads.
4. The states + a11y
- Loading (skeleton), empty ("No follow-ups yet"), error.
- Accessible: semantic structure, form labels, focus management when entering edit/reply mode, keyboard support.
5. Scale concerns
- Pagination — long threads load more on demand.
- Virtualization if a thread can be huge.
- Real-time — new follow-ups arriving via WebSocket, applied as targeted patches.
How to answer
"First I'd clarify what 'follow-ups' means here — a replies/comments thread, a follow-up tasks list, or follow-up questions — since the prompt is open-ended. Assuming a threaded comments widget: normalized flat data with parentId, a recursive render component with a capped indent depth, add/edit/delete with optimistic updates, and the usual loading/empty/error states plus accessibility. At scale, pagination and possibly virtualization and real-time updates."
Follow-up questions
- •Why clarify the prompt before coding?
- •Why flat-with-parentId instead of a deeply nested structure?
- •What happens to child replies when a parent is deleted?
- •How would you handle a very long or real-time thread?
Common mistakes
- •Jumping into code without clarifying what 'follow-ups' means.
- •Deeply nested state that's painful to update.
- •Unbounded visual nesting depth.
- •Skipping empty/error states and accessibility.
- •Re-rendering the whole tree on every edit.
Performance considerations
- •Normalized data makes mutations O(1). Memoized recursive items contain re-render scope. Pagination and virtualization handle large threads. Capped nesting depth keeps the DOM and layout sane.
Edge cases
- •Deleting a parent with existing replies.
- •Very deep reply chains.
- •Long threads needing pagination/virtualization.
- •Real-time follow-ups arriving while the user is reading.
- •Optimistic add that fails server-side.
Real-world examples
- •Threaded comments (Reddit/HN/GitHub), follow-up action items on a support ticket.