I'm working on plugin-style VanillaJS code for an existing project and built a small signal system. For a tooltip-like feature, hovering a table row stores that row in a currentRow signal. A computed signal extracts the IP address, one effect fetches Whois metadata and writes it into a div, and another effect displays the popover associated with the row. The signal-based version feels about as readable as putting the logic directly in the mouseover handler, although it requires fewer local variables. In plain JavaScript, what factors would make you choose signals and effects over handling the side effects directly in the event callback?
5 Answers
Hover is not a reliable interaction on touch devices, and dynamically creating the popover may also be fragile if the user moves quickly. A more accessible design would use a button or dialog for the explicit interaction, with a loading state. Hover can still be used as an optional prefetch, while the actual details load when the user opens the control.
Consider whether loading on hover is the best interaction. Pointer movement can trigger several unnecessary requests, so debouncing the hover or preloading the table data in batches may be more efficient. Also, the event handler should start the asynchronous work and return rather than blocking rendering.
The main issue here is handling stale asynchronous requests. If the pointer moves across rows quickly, an older Whois request might finish after the newer one and overwrite the current UI. Cancel requests with an AbortController or check that the response still belongs to the active row before rendering it. An effect cleanup mechanism can handle this well, but the same protection is needed with a regular event handler.
Avoid making a computed signal read values directly from table cells if you can. DOM content is a relatively unstable source of state; keeping the underlying row data in JavaScript makes the dependency clearer and easier to update. For more isolation, each row could own its loading state and request, which also reduces the chance that one row’s lookup interferes with another’s.
Signals become more useful when the same state is consumed in multiple places. If currentRow drives the popover, another display, caching, or some other piece of UI, keeping it as shared reactive state can keep everything synchronized. If the event only triggers one fetch and one UI update, signals may just add an abstraction layer without much benefit.
That makes sense. In this case the state is mostly tied to the hovered row, so I’ll keep an eye on whether more consumers appear before adding more reactive layers.
The effect cleanup currently aborts an in-flight request when the signal changes, and each row has its own popover, so the UI should not be overwritten by an outdated response. Still, the stale-request case is definitely something to test carefully.