¿Cuándo debo usar el gancho useImperativeHandle ?
Quiero decir, creo que hay varias formas de usarlo, y que es útil para acceder al estado secundario o métodos secundarios desde un componente principal...
Entonces... imagina esta situación:
Tengo una pantalla "Perfil", que implementa un pull-to-refresh para actualizar los datos y las publicaciones del usuario. Las publicaciones se representan en un componente secundario "UserPosts", donde busco las publicaciones respectivas de un usuario (paginación, oyentes, ...).
Si la pantalla Perfil es la responsable de obtener los datos del usuario y mostrar el <RefreshControl /> , ¿debo pasar una referencia a mi hijo para hacer userPostsRef.current.fetchNewPosts() desde el padre?
Algo como:
function Profile({ userId }) { const { userData, fetchUserData } = useFetchUserData(userId); const [isRefreshing, setIsRefreshing] = useState(false); const userPostsRef = useRef(null); const handleOnRefresh = async () => { // simplified, no mutex, no error catching setIsRefreshing(true); const promises = [ fetchUserData(), userPostsRef.current.fetchNewPosts() ]; await Promise.all(promises); setIsRefreshing(false); } ... const renderFooter = () => <UserPosts ref={userPostsRef} userId={userId} /> return ( <FlatList refreshing={isRefreshing} onRefresh={handleOnRefresh} ListHeaderComponent={renderHeader()} ListFooterComponent={renderFooter()} /> ); } const UserPosts = forwardRef({ userId }, ref) => { const { posts, isLoading, fetchNewPosts, fetchMoreOldPosts } = useFetchUserPosts(userId); useImperativeHandle(ref, { fetchNewPosts, }); return <CardList data={posts} isLoading={isLoading} ... />; }No está claro si está preguntando si este es el caso de uso correcto o simplemente cuándo es un buen momento para usar useImperativeHandle y luego da un ejemplo.
Para saber cuándo usar useImperativeHandle, le indicaría esta respuesta
Y en respuesta al ejemplo que diste, no intentaría usar useImperativeHandle. En su lugar, movería la lógica para obtener publicaciones al componente principal y luego pasaría los datos al componente secundario.
Lo he usado en un par de escenarios que parecían tener sentido para mí. Una era activar un controlador dentro de un componente reutilizable fuera de ese componente: un botón de reinicio. Toda la lógica relacionada con el restablecimiento y la obtención de datos se mantuvo dentro del componente y no tenía sentido tener esa lógica y datos ya sea (a) en la tienda (b) en las páginas que necesitaban usar el componente (c) en un proveedor de contexto que agregó más bloqueo.
La segunda razón fue obtener información desde el interior del componente (¡te escucho jadear!), pero en este caso el contenido (editor de texto enriquecido RTE) se activó desde un botón "guardar", pero quería que fuera parte de un enviar todo el formulario. Debido a la naturaleza del componente (y probablemente debido a mi comprensión limitada de la forma en que funcionan las cosas), no pude conectarlo al marco de formulario que estaba usando, y el método para analizar el RTE en html sin formato para guardar en el servidor era demasiado costoso para los cambios de pulsación de teclas (nuevamente, esto podría haberse mitigado con más conocimiento sobre cómo se conectan las cosas).
De todos modos, tengo una demostración que muestra un par de ejemplos que muestran cómo desencadenar una acción dentro de un componente (más o menos lo que publicó el operador) y también cómo recuperar información del componente cuando el contenido interno puede ser de naturaleza asíncrona.
https://codesandbox.io/s/useimperitivehandle-double-example-71oxwm?file=/src/App.tsx