How would you create a parameterized Svelte tooltip Action?
It tests your grasp of the Svelte Action lifecycle for reactive parameters. Answer: action takes node and parameter, returns update and destroy, bound as use:tooltip={text}. Using component events instead of the Action API, or omitting update, is a red flag.
WHAT THIS TESTS: This question probes whether you know the difference between a raw DOM utility and a first-class Svelte Action. The interviewer cares if you understand the contract: the function runs once on mount, can read the initial parameter, and must return an object with update and destroy to handle reactivity and teardown. They also want to see if you type the action correctly using Action<HTMLElement, string> and if you know that the use: directive is the idiomatic way to attach behavior to an element without wrapper components.
A GOOD ANSWER COVERS: A good answer hits four things in order. First, the signature: a function named tooltip that takes node and parameter, typed as Action<HTMLElement, string>. Second, setup inside the function body: create a tooltip element, append it to the body or position it absolutely near the host node, and add mouseenter and mouseleave listeners to the node that toggle visibility or text. Third, the update method on the returned object: it receives the new parameter value and mutates the tooltip content or position without destroying the host node or recreating the action. Fourth, the destroy method: remove the event listeners from the host node and remove the tooltip element from the DOM to prevent memory leaks when the component unmounts.
COMMON WRONG ANSWERS: Common wrong answers include suggesting a Svelte store to manage tooltip state globally, which misses the point of co-locating behavior with the element. Another red flag is using on:mouseenter inside the component markup instead of the use:tooltip directive; that works but shows you do not know the Action API. Some candidates forget the update method and say the action reruns whenever the text changes, which is false because Svelte only calls the action once and relies on update for subsequent changes. Others forget cleanup in destroy, leaving orphaned tooltip nodes in the document body.
LIKELY FOLLOW-UPS: Interviewers often follow up by asking how you would type an action that dispatches custom events, which requires the third generic parameter on Action. They might ask how to make the tooltip position intelligently near the viewport edge, which tests your DOM geometry skills. Another variant is asking how to pass an object with multiple options like text, color, and delay, which simply changes the Parameter generic from string to an options interface. You might also be asked how to test an action in isolation, where the expected answer is to mount a component in a test framework and assert on the tooltip element in the document body.
ONE CONCRETE EXAMPLE: Imagine a button that shows a tooltip. In the component script, you import type { Action } from svelte/action and define const tooltip: Action<HTMLElement, string> = (node, text) => { let el = document.createElement('div'); el.className = 'tooltip'; el.textContent = text; document.body.appendChild(el); const show = () => el.style.display = 'block'; const hide = () => el.style.display = 'none'; node.addEventListener('mouseenter', show); node.addEventListener('mouseleave', hide); return { update(newText) { text = newText; el.textContent = newText; }, destroy() { node.removeEventListener('mouseenter', show); node.removeEventListener('mouseleave', hide); el.remove(); } }; }; Then in markup you write <button use:tooltip={helpText}>Help</button>. When helpText changes, Svelte calls update, and when the button is destroyed, Svelte calls destroy.
Source: v4.svelte.dev
Read the original → v4.svelte.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.