I'm working on plugin-style Vanilla JS code for an existing project and have built a small signal implementation. For a tooltip-like feature, hovering a table row stores that row in a "current row" signal. A computed signal extracts the row's IP address, one effect fetches Whois metadata and writes it into a div, and another effect displays a popover associated with the row.
The whole flow seems about equally readable whether I use signals and effects or keep the core logic inside the hover handler. The signal-based version does require fewer local variables, but it also adds another layer of abstraction. In Vanilla JS, what factors would make you choose a reactive signal/effect approach over directly starting the side effect in the event handler?
5 Answers
Signals are most useful when the same state is consumed in multiple places. If the current row needs to update the popover, a loading indicator, and some other part of the page, keeping it as shared reactive state can make those relationships clear. If the hover only triggers one fetch and one UI update, putting that logic in the event handler is probably simpler and avoids adding an abstraction that does not buy you much.
Consider whether the data should be loaded on demand at all. A pointer moving across a table can trigger several unnecessary lookups, so a batch endpoint or loading the metadata alongside the table rows may be a better fit. If on-demand loading is important, debounce the hover, start the asynchronous work from the handler, and return immediately so the UI thread is never blocked.
Hover-only interaction has accessibility and touch-device limitations. I would use hover to prefetch when convenient, but provide an explicit click or keyboard action that opens a pre-created dialog or popover with a loading state. That also avoids relying on an element being created quickly enough after a pointer event.
The bigger issue here is request ordering rather than signals versus handlers. Moving quickly across rows can leave an older Whois request resolving after the newer one and replacing the current content with stale data. Cancel in-flight requests with an AbortController, or check that the response still belongs to the currently hovered row before rendering it. A cleanup function in an effect can work well for this, but the same protection is needed with a normal event handler.
The effect cleanup currently aborts the active request whenever the signal changes. I also keep a popover per row, so the response should not overwrite a different row, but the stale-request warning is definitely worth accounting for.
Be careful about treating a DOM cell as the source for a computed signal. DOM content can change for reasons outside your state model, which makes it a less stable dependency. If possible, keep the row data in JavaScript and derive the IP from that data instead of reading it back from the HTML.
That is how I tend to decide too: start with the handler when there is only one consumer, and promote the value to shared reactive state once multiple parts of the UI genuinely depend on it.