Solution

This hook provides a small, stable React wrapper around an optional browser capability.

The problem, in plain English

A mobile interface may use a short pulse to acknowledge a successful action. The page cannot assume every browser has vibration support, and an accepted request does not prove that physical hardware moved. Your hook must expose the platform's result without inventing extra state.

The mental model

Treat support detection and each command as separate checkpoints. The effect updates the displayed capability after mount, while every action checks the live API again before it calls.

A first attempt

function useVibrate() {
  const isSupported = typeof navigator.vibrate === 'function';
  const vibrate = (pattern) => navigator.vibrate(pattern);
  const cancel = () => navigator.vibrate(0);
  return { isSupported, vibrate, cancel };
}

This reads navigator during render, so rendering outside a browser can throw. It also creates new function objects on every render and calls a method that may disappear. A saved isSupported value is useful for rendering controls, but it is not a safe authorization for a later command.

The working solution

const { useCallback, useEffect, useState } = require('react');

function browserSupportsVibration() {
  return (
    typeof navigator !== 'undefined' &&
    typeof navigator.vibrate === 'function'
  );
}

function useVibrate() {
  const [isSupported, setIsSupported] = useState(false);

  useEffect(() => {
    setIsSupported(browserSupportsVibration());
  }, []);

  const vibrate = useCallback((pattern) => {
    // Capability can change after mount, so guard the actual call too.
    if (!browserSupportsVibration()) return false;
    return Boolean(navigator.vibrate(pattern));
  }, []);

  const cancel = useCallback(() => {
    if (!browserSupportsVibration()) return false;
    return Boolean(navigator.vibrate(0));
  }, []);

  return { isSupported, vibrate, cancel };
}

module.exports = { useVibrate };

browserSupportsVibration guards both the global object and the current property. The state begins with the same safe answer in every rendering environment, then the effect reconciles it in the browser. useCallback keeps each action's identity stable, while its empty dependency list is safe because the action reads navigator.vibrate only when invoked.

Walking through one call

Suppose a button calls vibrate([80, 40, 160]). The callback first confirms that the current navigator.vibrate property is a function. It passes the same array object to the browser, which interprets it as 80 ms of vibration, a 40 ms pause, and 160 ms of vibration. If the browser returns true, your callback returns true; it does not claim that hardware or system settings allowed a physical pulse.

Calling cancel() later forwards 0. The platform stops the current pattern, and a newly accepted non-zero pattern would also replace one already in progress.

Gotchas

• Calling without prior interaction — browsers require sticky user activation, so call vibrate from a click, key, or another user-initiated path.
• Treating true as proof of motion — limited browser support, missing hardware, Silent mode, Do Not Disturb, or user settings can prevent feedback even after a request is accepted.
• Normalizing inside the hook — the browser owns pattern rules and limits. Forward the caller's number or array unchanged.
• Tracking an active flag — the API exposes no completion event, and a later call replaces the current pattern. Do not claim state you cannot observe.
• Cancelling during cleanup — unmount does not imply that the caller wants to stop device feedback. Expose cancel and let product behavior decide when to call it.

Going further

• Respect an application-level reduced-motion or haptics preference before calling this low-level hook.
• Build named feedback presets such as success or warning above vibrate, while keeping this wrapper policy-free.
• Accept an AbortSignal in a higher-level sequence helper if your product schedules repeated feedback; this hook intentionally creates no timers.