React Hooks ¿Por donde empezar?
•Transferir como PPTX, PDF•
1 gostou•282 visualizações
Sesión impartida en el CanariasJS el 09 de Noviembre, una introducción de como empezar con los React Hooks y ver en que escenarios podemos usarlos.
Recomendados
Mais conteúdo relacionado
Semelhante a React Hooks ¿Por donde empezar?
Semelhante a React Hooks ¿Por donde empezar? (20)
Mais de Adrian Diaz Cervera
Mais de Adrian Diaz Cervera (20)
Último
Último (7)
React Hooks ¿Por donde empezar?
- 1. una consultora tecnológica que piensa en colores para organizaciones vivas React Hooks ¿Cómo empezar? Adrián Díaz Cervera - @AdrianDiaz81
- 2. Un servidor http://blogs.encamina.com/desarrollandosobresharepoint adiaz@encamina.com @AdrianDiaz81
- 3. Agenda • ¿Qué son los Hooks? • ¿Por qué utilizarlos? Motivación • Tipos de Hooks • Migración, actualización, uso • Q & A
- 4. #spsmad ¿ Que son los React Hooks?
- 5. Qué son los Hooks Nueva característica de React disponible desde la versión 16.8 Estos te permiten usar el estado y otras características de React sin escribir una clase. Hooks => son funciones que te permiten “enganchar” el estado de React y el ciclo de vida desde componentes funcionales
- 6. Aspectos que debemos de conocer No es obligatorio su uso 100 % Compatible con versiones anteriores de React No reemplaza a las clases No reemplazan el conocimiento previo sobre React => API directa mayor beneficio
- 8. Motivación Ciclo de vida muy complejo en aplicaciones “grandes” Difícil reutilizar la lógica del estado entre componentes Muchos métodos similares “DidUpdate, DidMount, DidUnmont” código duplicado=> Mal uso => Problema de rendimiento Componentes difíciles de entender => Cada método del ciclo de vida mezcla lógica no relacionada entre sí
- 9. • Mas fácil escribir y testear que en formato de clase • Código más legible => Menos líneas de código • Facilita la reutilización • Mejora el control de vida • Adaptado al paradigma funcional • Evita crear componentes extra en el DOM => Como los HOC ¿Que nos aportan?
- 10. TIPOS DE HOOKS
- 11. Tipos de Hooks Podemos distinguir tipos: • Hooks de “state”/estado => Cuando el componente funcional se tiene la necesidad de hacer uso del state • Hooks de “effect”/efecto => Agrega la capacidad de realizar efectos secundarios desde un componente funcional. Mismo propósito que componentDidMount, componentDidUpdate y componentWillUnmount en las clases React. • Hooks “custom”/Personalizado => Se utilizan cuando se quiere reutilizar alguna lógica de estado entre componentes.
- 12. es una clase funcional en la que tienen que hacer uso en algún momento del state Hooks “State”
- 13. es una clase funcional en la que tienen que hacer uso en algún momento del state Hooks “State”
- 14. Hooks “State” : usar múltiples variables de estado
- 15. Lanzarse una vez termina el render y realiza operaciones sobre ello. Hook “effect”
- 16. Lanzarse una vez termina el render y realiza operaciones sobre ello. Hook “effect”
- 17. El saneamiento lo podemos definir como la acción necesaria una vez el componente se va a destruir para evitar algún fallo Hook “effect”’“Saneamiento”
- 18. El saneamiento lo podemos definir como la acción necesaria una vez el componente se va a destruir para evitar algún fallo Hook “effect”“Saneamiento”
- 19. ¿Puedo tener más de uno en un componente funciona? Hook “Effect”
- 20. • Llama Hooks solo en el nivel superior Reglas de los Hooks
- 21. • Llama Hooks solo en funciones de React – Llama Hooks desde componentes funcionales de React. – Llama Hooks desde Hooks personalizados • Plugin de ESLint Reglas de los Hooks
- 22. Ofrecen la flexibilidad de compartir lógica que no era posible antes con los componentes de React. Casos de uso : podría ocultar la lógica compleja detrás de una interfaz simple, o ayudar a desenredar un componente desordenado. Hook “Custom”
- 23. Es una función de JavaScript cuyo nombre comienza con ”use” y que puede llamar a otros Hooks. Hook “Custom”
- 24. . Hook “Custom”
- 25. Show me the code, Talk is cheap !! => Linus Torvard
- 26. Como adoptarlo: actualización, migración ¿Qué hacemos?
- 27. El equipo de React indica que podemos usar Hooks de forma progresiva, pero … - Mantenimiento de la aplicación => Clases !== Funciones => Que criterio se sigue - Nos beneficiamos de las ventajas que tienen los Hooks? - Curva de aprendizaje Proyectos en curso, ¿qué hacemos?
- 28. Tener clara la estrategia de migración de versión - Compatibilidad de los desarrollos con versión anteriores - Refactor necesario - Solamente migrar partes en uso o nuevas - Tener claro Mantenimientos , ¿qué hacemos?
- 29. ASPECTO POSITIVOS Código más limpio Reutilización El uso del this Desarrollo funcional Adaptado al futuro de JS ASPECTO NEGATIVOS Curva de aprendizaje Adaptarse a los hooks UseEfect => bucles infinitos UseState => Forma diferente a lo que estabamos acostumbrados Nuevos desarrollos, aspectos a tener en cuenta
- 30. Resumen Hooks han venido para quedarse Código más reutilizable Paradigma Funcional Establecer plan de formación adopción NO es oro todo lo que reluce
- 32. Q & A … y lo que surja http://blogs.encamina.com/desarrollandosobresharepoint adiaz@encamina.com @AdrianDiaz81 https://github.com/AdrianDiaz81/canariasjs2019
Notas do Editor
- Hubo mucho hype en la comunidad con esta nueva funcionalidad… implica hacer ReactJS más orientado a una programación funcional… una de las grandes criticas que había en parte de la comunidad, pero porque esta fiebre… En la conferencia Rect Conf de 2018 Dan Abramov y Sophie Albert mostrarun ejemplo de como se podía empezar a refactorizar el código usando Hooks… la idea que llevan es que React lleva 5 años rompiendo moldes y quieren seguir rompiéndolos :) antes de explicar todo esto vamos atener unos puntos bastantes claros sobre los Hooks
- Se puede seguir programando de la misma forma que estamos haciendo… es decir por mucho que se diga NO hay obligación de usarlos, esto quiere decir que el equipo de React aconseja que los nuevos desarrollos se utilicen los Hooks aunque no es una imposición seguirán evolucionando la forma en la que hay ahora … pero recomendando su uso. Este cambio del uso de clases o funciones es un debate bastante largo en el mundo de JavaScript y más desde los últimos años donde han salido otros “transpiladores/lenguajes” como son TypeScript junto con las novedades que van saliendo en el propio JavaScript. El futuro ? Mi opinión es que tendremos un único lenguaje que este todo integrado … TypeScript no es más que un superconjunto de Javascript La forma de desarrollo haciendo uso de Hooks es un tanto diferente que la forma tradicional… aunque no se reemplaza el conocimiento sobre React esta basado en los mismos principios patrón FLUX evitar las modificaciones innecesarias del DOM mediante un DOM virtual
- Es difícil reutilizar la lógica de estado entre componentes => Los Hooks te permiten reutilizar lógica de estado sin cambiar la jerarquía de tu componente. Esto facilita el compartir Hooks entre muchos componentes o incluso con la comunidad. Los componentes complejos se vuelven difíciles de entender => Cada método del ciclo de vida a menudo contiene una mezcla de lógica no relacionada entre sí. Por ejemplo, los componentes pueden realizar alguna consulta de datos en el componentDidMount y componentDidUpdate. Sin embargo, el mismo método componentDidMount también puede contener lógica no relacionada que cree escuchadores de eventos, y los limpie en el componentWillUnmount. El código relacionado entre sí y que cambia a la vez es separado, pero el código que no tiene nada que ver termina combinado en un solo método. Esto hace que sea demasiado fácil introducir errores e inconsistencias => Hooks te permite dividir un componente en funciones más pequeñas basadas en las piezas relacionadas (como la configuración de una suscripción o la consulta de datos)
- https://medium.com/@mateuszroth/react-hooks-advantages-and-comparison-to-older-reusable-logic-approaches-in-short-f424c9899cb5 hooks are going to work better with future React optimizations (like ahead of time compilation and components folding) — components folding might be possible in future (https://github.com/facebook/react/issues/7323) — what means dead code elimination at compile time (less JS code to download, less to execute) even now, minification of functions in JavaScript is much better than minification of JavaScript classes. It’s not possible for example to minify method names of JS classes as every method can be either private or public, so we don’t know when it’s used outside the class. Less code to download, process and execute has positive impact for end user. Check comparison: Un HOC o High Order Component es una excelente forma de añadir nuevas capacidades a tu componente mediante composición, sin embargo: Necesitas refactorizar su interfaz para poder aplicarlo. Encadenar diversos HOC simultáneamente puede ser una pesadilla.
- Declarando variables de estado como un par [something, setSomething] también es útil porque nos permite dar diferentes nombres a diferentes variables de estados si queremos usar más de una En el componente de arriba tenemos age, fruit, y todos como variables locales y los podemos actualizar de forma individual: No tienes que usar obligatoriamente tantas variables de estado: las variables de estado pueden contener objetos y arrays para que puedas agrupar la información relacionada. Sin embargo, al contrario que en una clase, actualizar una variable de estado siempre la reemplaza en lugar de combinarla.
- Sin saneamiento => En ciertas ocasiones, queremos ejecutar código adicional después de que React haya actualizado el DOM. Peticiones de red, mutaciones manuales del DOM, y registros, son ejemplos comunes de efectos que no requieren una acción de saneamiento. Decimos esto porque podemos ejecutarlos y olvidarnos de ellos inmediatamente.
- Pongamos un ejemplo, estamos implementando un chat y en el momento de que el usuario abandone el mismo queremos saberlo para cambiarle su estado y de esta forma evitar un comportamiento incorrecto de la aplicación. Veamos un ejemplo utilizando clases:
- Como podéis ver en la función useEffect ahora nos devuelve una función tras ejecutar el código que se hace al montar. Este es un mecanismo opcional de los efectos. Todos los efectos pueden devolver una función que los sanea más tarde. Esto nos permite mantener la lógica de añadir/crear y eliminar suscripciones cerca la una de la otra, lo cual nos facilita mucho la legibilidad de este. ¿Cuándo se ejecuta la devolución del useEffect? Naturalmente cuando el componente se va "desmontar/destruir", pero si el useEffect se ejecuta cada vez que el componente se renderiza es posible que tengamos problemas de rendimiento, ¿no? Correcto si no controlamos que el useEffect se ejecute cuando se haya realizado alguna modificación nuestro componente se volverá a pintar cada vez.
- Consejo: Usa varios efectos para separar conceptos Uno de los problemas que esbozamos en la Motivación para crear los Hooks es que los métodos del ciclo de vida de las clases suelen contener lógica que no está relacionada, pero la que lo está, se fragmenta en varios métodos. Este es un componente que combina la lógica del contador y el indicador de estado del amigo de los ejemplos anteriores: Fíjate en como la lógica que asigna document.title se divide entre componentDidMount y componentDidUpdate. La lógica de la suscripción también se reparte entre componentDidMount y componentWillUnmount. Y componentDidMount contiene código de ambas tareas. Entonces, ¿cómo resuelven los Hooks este problema? Del mismo modo que puedes usar el Hook de estado más de una vez, puedes usar varios efectos. Esto nos permite separar la lógica que no está relacionada en diferentes efectos: Los Hooks nos permiten separar el código en función de lo que hace en vez de en función del nombre de un método de ciclo de vida. React aplicará cada efecto del componente en el orden en el que han sido especificados.
- No llames Hooks dentro de ciclos, condicionales o funciones anidadas. En vez de eso, usa siempre Hooks en el nivel superior de tu función en React. Siguiendo esta regla, te aseguras de que los hooks se llamen en el mismo orden cada vez que un componente se renderiza. Esto es lo que permite a React preservar correctamente el estado de los hooks entre multiples llamados a useState y useEffect
- No llames Hooks dentro de ciclos, condicionales o funciones anidadas. En vez de eso, usa siempre Hooks en el nivel superior de tu función en React. Siguiendo esta regla, te aseguras de que los hooks se llamen en el mismo orden cada vez que un componente se renderiza. Esto es lo que permite a React preservar correctamente el estado de los hooks entre multiples llamados a useState y useEffect
- Tradicionalmente en React, hemos tenido dos formas populares para compartir lógica de estados entre componentes: renderizar props y componentes de orden mas alto. Ahora veremos como los Hooks resuelven muchos de los mismos problemas sin forzarte a añadir más componentes al árbol.
- ¿Es este código equivalente a los ejemplos originales? Sí, funciona exactamente de la misma forma. Si miras de cerca, notarás que no hicimos cambios en el comportamiento. Todo lo que hicimos fue extraer código común entre dos funciones en una función separada. Los Hooks personalizados son una convención que surge naturalmente del diseño de los Hooks, en lugar de una característica de React. ¿Tengo que nombrar mis Hooks personalizados comenzando con ”use“? Por favor, hazlo. Esta convención es muy importante. Sin esta, no podríamos comprobar automáticamente violaciones de las reglas de los Hooks porque no podríamos decir si una cierta función contiene llamados a Hooks dentro de la misma. ¿Dos componentes usando el mismo Hook comparten estado? No. Los Hooks personalizados son un mecanismo para reutilizar lógica de estado (como configurar una suscripción y recordar el valor actual), pero cada vez que usas un Hook personalizado, todo estado y efecto dentro de este son aislados completamente. ¿Cómo un Hook personalizado obtiene un estado aislado? Cada llamada al Hook obtiene un estado aislado. Debido a que llamamos useFriendStatus directamente, desde el punto de vista de React nuestro componente llama a useState y useEffect. Y como aprendimos anteriormente podemos llamar a useState y a useEffect muchas veces en un componente y ellos van a ser completamente independientes.
- Por último, pero no menos importante, en un proyecto de dimensiones considerables, una aproximación mixta donde componentes funcionales y de clase tengan que convivir juntos podría traer diversos inconvenientes de mantenibilidad: Inconsistencia en nuestra base de código. Dificultad añadida para que nuevos desarrolladores se inicien en el proyecto, teniendo que aprender ambas formas y decidir cuando es más conveniente una u otra, o cuando deben refactorizar un componente existente en uno u otro sentido. La refactorización de componentes, ya sea en un sentido u otro, es una tarea propensa a errores, por ejemplo: se nos olvida eliminar el this, nos equivocamos en la sintaxis de clase vs función, errores con la función de render, etc.