useEffect и ref в React 19: как StrictMode подставляет в production и как это починить
useEffect и ref в React 19: как StrictMode подставляет в production и как это починить StrictMode в React 19 стал строже — двойной mount-unmount в dev ловит утечки, но порождает новую ловушку: код, который работает локально, ломается на проде. Чаще всего страдают хуки, где ref.current используется в cleanup без защиты от null. Типичная ошибка: полагаться на ref.current в return-функции useEffect. В dev второй mount может дать null, а в production — рейс-кондишн, который не воспроизвести локально. Паттерн: защита через проверку node Храни ссылку на DOM-узел на момент монтирования и проверяй её перед использованием: const ref = useRef(null); useEffect(() => { const node = ref.current; if (!node) return; const observer = new IntersectionObserver(() => { /* ... */ }); observer.observe(node); return () => { observer.unobserve(node); }; }, [ref]); Здесь node захватывается на момент первого mount, а cleanup отвязывается от того же узла. Проблема двойного вызова устраняется. Идемпотентность cleanup Любой cleanup должен быть безопасен при многократном вызове — например, через флаги: useEffect(() => { let cleanupCalled = false; const handler = () => { /* ... */ }; addEventListener('scroll', handler); return () => { if (cleanupCalled) return; cleanupCalled = true; removeEventListener('scroll', handler); }; }, []); Так даже если StrictMode вызовет cleanup несколько раз, ничего не сломается. Типичная ошибка: таймеры и subscriptions setInterval без сохранения id или addEventListener, который не отписан — самые частые виновники. В production они создают дубли, которые не воспроизводятся в dev без ручной проверки. Перед релизом пройдись по всем useEffect: - каждый cleanup явно отписывается - нет доступа к ref.current без проверки на null - cleanup без побочных эффектов при повторном вызове Вывод: StrictMode в React 19 — не баг, а фича: если cleanup выдерживает двойной mount, production не удивит тебя утечками в самый неподходящий момент.