Solution

Keep rendering safe, then cross the browser boundary only from an effect or an explicit callback.

The problem, in plain English

A page can read notification permission, ask the user for it, and create a system notification. React may also render where window does not exist, though, and browsers restrict when a permission prompt may open. Your hook therefore needs a safe initial snapshot and caller-controlled operations.

The mental model

Treat the browser API as a guarded boundary. The render starts with an environment-safe result, the mount effect reads the real browser state, and later method calls check the API again instead of trusting an old render.

A first attempt

The tempting version reads the global immediately and asks for permission as soon as the component mounts.

function useNotification() {
  const [permission, setPermission] = useState(Notification.permission);

  useEffect(() => {
    Notification.requestPermission().then(setPermission);
  }, []);

  return { permission };
}

This crashes in an unsupported or server-rendered environment. It also opens a permission prompt without a user interaction, which browsers may block and users do not expect. Finally, it offers no guarded way to construct a notification.

The working solution

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

function getNotificationApi() {
  if (typeof window === 'undefined' || typeof window.Notification !== 'function') {
    return undefined;
  }
  return window.Notification;
}

function useNotification() {
  const [state, setState] = useState({
    isSupported: false,
    permission: 'unsupported',
  });

  useEffect(() => {
    const NotificationApi = getNotificationApi();
    if (!NotificationApi) return;

    setState({
      isSupported: true,
      permission: NotificationApi.permission,
    });
  }, []);

  const requestPermission = useCallback(async () => {
    const NotificationApi = getNotificationApi();
    if (!NotificationApi) {
      throw new Error('Notifications are not supported in this environment.');
    }
    if (typeof NotificationApi.requestPermission !== 'function') {
      throw new Error(
        'Notification permission requests are not supported in this environment.'
      );
    }

    const nextPermission = await NotificationApi.requestPermission();
    setState({ isSupported: true, permission: nextPermission });
    return nextPermission;
  }, []);

  const showNotification = useCallback((title, options) => {
    const NotificationApi = getNotificationApi();
    if (!NotificationApi) {
      throw new Error('Notifications are not supported in this environment.');
    }
    if (NotificationApi.permission !== 'granted') {
      throw new Error('Notification permission has not been granted.');
    }

    return new NotificationApi(title, options);
  }, []);

  return {
    ...state,
    requestPermission,
    showNotification,
  };
}

module.exports = { useNotification };

getNotificationApi centralizes the environment check, so every browser access has the same guard. The state begins with the safe unsupported snapshot and is reconciled in useEffect, which only runs after mounting. Both callbacks use empty dependency arrays because they read the live browser API when called; they do not close over React's permission snapshot.

Permission requests have three ordinary outcomes, and a browser rejection remains a rejection:

Displaying has a separate call-time gate. Even if the last React render said granted, a user can change site settings before the next call.

The await occurs before setState, so a rejected permission promise cannot invent a new permission. Returning the constructor result gives callers the real Notification instance, including its events and close() method. Constructor failures also propagate without being replaced by a generic hook error.

Walking through one call

Suppose the browser supports notifications and its current permission is 'default'. The first render returns { isSupported: false, permission: 'unsupported' } without reading window; after mount, the effect reads the API and updates that to { isSupported: true, permission: 'default' }. The user clicks an Enable button, and the click handler awaits requestPermission(). If the browser resolves 'granted', the hook stores and returns 'granted'. A later call to showNotification('Build complete', { body: 'Version 2.4 is ready.' }) checks the live static permission, constructs the notification with those exact arguments, and returns that instance.

Gotchas

• Prompting on mount — browsers expect permission requests to follow a user gesture, so expose a method and let a click handler call it.
• Checking captured state before display — site permission can change outside React; read Notification.permission at call time.
• Swallowing a rejection — converting a browser policy error into 'denied' hides the real failure; update state only after the promise resolves.
• Assuming the constructor is universal — MDN notes that new Notification() is suitable for desktop but throws on most mobile browsers; mobile persistent notifications use ServiceWorkerRegistration.showNotification().
• Recreating callbacks — inline functions change identity on every render; useCallback keeps both public operations stable.

Going further

• Add a service-worker path that uses persistent notifications on mobile and remains usable after the page closes.
• Subscribe to the Permissions API where supported so settings changed outside the page can refresh the displayed permission.
• Add lifecycle helpers for notification click, show, error, and close events without changing the permission boundary.