@wybacz: Np. wtedy gdy komponent rodzica musi przekazać jakąś funkcje potomkowi który jest memoizowany (np. tylko dla tego callbacka) i z jakiegoś powodu komponent rodzica często jest rerenderowany

https://dmitripavlutin.com/dont-overuse-react-usecallback/

@lobo: znam ten artykuł i generalnie się z nim zgadzam ponieważ wszystko co w nim jest to prawda za którą stoją sensowne argumenty (a ciężko się z czymś takim nie zgadzać), ale i tak lekko wkurza mnie fakt że istnieje swobodne przyzwolenie na to żeby narzędzie przez nas używane powodowało potencjalne problemy z wydajnością którym nie można zapobiec z wyprzedzeniem i które należy naprawić dopiero gdy wystąpi i jakoś zostaniePokaż całość

@Marmite: sa tylko 2 (az) sensowne powody do uzywania useCallback:
1. To co napisal @lobo
2. Gdy funkcja jest uzywana jako dependency w np useEffect, useMemo itd

@Sheppard28: ale ja to wiem przecież

@Marmite: mialo byc do
@wybacz

@Sheppard28: a, no to @wybacz w takim razie ( ͡° ͜ʖ ͡°)

@wybacz: Dodatkowo:
Zależnie od implementacji, callbacki do customowych hooków mogą funkcję przekazywać do depów w useCallback/useMemo/useEffect, wtedy dobrze owinąć callback w useCallback, zwłaszcza jeśli hook wywołuje wiele rerenderów, np. useWindowScroll(useCallback(() => { /* Close popup */ }, []));
Ponadto ref callbacki powinny używać useCallback
Poniższe co rerender będzie wywoływało callback z element jako null, i potem z faktycznym elementem, bo identity funkcji się zmienia

{ /*Pokaż całość