fix(vocal): stabilize the event handlers to prevent listener leaks on re-render

[Muneebkhnnn]

Problem

Event handlers in Vocal.jsx were recreated on every render.
Since subscribe/unsubscribe rely on reference equality, this caused
mismatches when a re-render occurred during an active recognition session,
leading to potential listener leaks.

Solution

• Memoized all event handlers using useCallback
• Stabilized the handler map using useMemo
• Added refs to stabilize unstable values from useVocal, useTimeout
  and useCommands hooks (stop, triggerCommand, on* prop callbacks)

Testing

• Verified all subscribe/unsubscribe pairs use identical references
• Tested re-renders during active sessions — no duplicate listeners observed

[untemps]

Hi @Muneebkhnnn, thanks for the thorough analysis — the problem you identified is real.

A quick heads-up though: main is being superseded by v2.0.0, currently in pre-release on the beta branch. That branch already includes a significant rewrite of Vocal.js (React 19 migration, propTypes removal, simplified event handling), so this patch doesn't apply cleanly there.

The stale prop callback issue still exists in beta. Two options:

• Merge on main → fast, ships as v1.7.x, but v2.0.0 will need a separate fix anyway
• Target beta → the fix lands in v2.0.0, adapted to the new code structure, but takes longer

What's your preference? Does the urgency justify a v1.x patch?

[untemps]

PR #112 covers the full scope of yours, targeting beta (the upcoming v2.0.0) rather than main. It applies the same core approach — useCallback on all handlers, useMemo on HANDLERS, propsRef for stable prop callbacks, onEndRef/stableTimerCb to break the circular dep — with two corrections over your implementation: unsubscribeAllRef is assigned inline during render instead of in a useEffect (avoids a first-mount timing gap), and
stopRecognition uses finally to guarantee cleanup even when stop() throws.

[Muneebkhnnn]

Thanks! So should I keep #111 open for the v1.7.x patch on main, or would you prefer to close it?

[untemps]

Thanks @Muneebkhnnn! I'll close this in favour of the work already underway on the upcoming major release — the fix will ship as part of v2.0.0.