Cuando no se pasa una devolución de llamada a un elemento secundario y solo se usa en el componente actual, ¿hay algún beneficio en envolver la devolución de llamada en un useCallback ? Este:
const Foo = ( const [count, setCount] = useState(500); const onChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => { setCount(Number(e.target.value)); }, [setCount]); return ( <> <div> Delay: <input value={count} onChange={onChange} type="number" /> </div> </> );verso esto:
const Foo = ( const [count, setCount] = useState(500); const onChange =(e: React.ChangeEvent<HTMLInputElement>) => { setCount(Number(e.target.value)); }; return ( <> <div> Delay: <input value={count} onChange={onChange} type="number" /> </div> </> );Códigos y caja: https://codesandbox.io/s/loving-stonebraker-48xhs?file=/src/Counter.tsx
No veo ningún beneficio allí cuando se usa internamente, ya que cada actualización de estado ( setCount(Number(e.target.value)); ) necesariamente vuelve a representar el componente de todos modos y todo lo que hace la devolución de llamada es poner en cola una actualización de estado.
Puede haber una pequeña ( muy insignificante ) mejora en el uso de la memoria si se usa una sola función declarada y memorizada durante la vida útil del componente.
Si la devolución de llamada se usó en un useEffect , podría proporcionarse como una referencia estable y eliminarse de las matrices de dependencia, pero normalmente aquí simplemente movería la función a la devolución de llamada del efecto. Esto no se ajusta al caso de uso sobre el que está preguntando, pero es un caso de uso válido que no pasa las devoluciones de llamada a los niños.