Los tiempos en el desarrollo de Spfx cambian muy rápido y vemos cómo se añaden cambios a una velocidad relativamente rápida. Éste era uno de los principales handicaps que ya preveíamos que podía ocurrir con Spfx: que no fueran capaces de seguir un ritmo de evolución acorde a los cambios que se están llevando a cabo en todo el ecosistema en el que esta implementado.
Por ejemplo, mucha gente dirá que se ha tardado cerca de un año en soportar la última versión de React, sin embargo, pensad cuánto tiempo llevamos esperando que CSOM se pueda utilizar con .NET Core y todavía no lo tenemos…El hecho de tener una actualización de todas estas herramientas capaz de incluir todos esos cambios es algo que, dado que ya se esta ejecutando en entornos productivos, no es ni mucho menos trivial y conlleva mucho riesgo y muchas pruebas. No es algo que se pueda abordar fácilmente. En ocasiones, este ansia por tener una versión con todos los cambios, provoca errores. Esta última versión estuvo dos meses congelada porque cuando se anuncio la versión 1.9.1 se produjeron una serie de fallos que obligaron a dar marcha atrás. En este artículo vamos a ver la gran cantidad de novedades que trae la nueva versión y la importancia de la misma.
En la documentación oficial podemos ver todo las novedades que trae. Ahora bien, vamos a ver la importancia de alguno de estos cambios.
Uno de los puntos en los que los equipos de desarrollo pierden mucho tiempo es en el proceso de compilación y de integración continua.
Independientemente de la tecnología vemos cómo estos procesos se alargan mucho en el tiempo y se van incrementando a medida que aumenta el número de lineas de código. Ahora bien, en el desarrollo del Front es esencial el proceso de generar la ejecución del bundle y con la finalidad de mejorar el tiempo de la generación del fichero, muchos equipos de desarrollo se encargan de tunear ese proceso. Dentro de Spfx este proceso se puede «tunear», pero siempre siguiendo unas reglas. Eso sí, el tiempo de compilación no mejora, sino que se incrementa.
La salida de webpack 4 trajo como principales cambios mejoras masivas de rendimiento, cero configuraciones para pequeñas aplicaciones y valores predeterminados. Estas mejoras de rendimiento en algunas aplicaciones implican una reducción de hasta el 75% en el tiempo de generación del bundle. Ahora bien, muchos diréis: ¡si yo no utilizo el webpack en Spfx!¡yo lo que hago es un comando de gulp para lanzar la compilación! Bueno, puede que no sepáis que desde gulp lo que se hace es llamar a Webpack para la propia generación del bundle y el package de la aplicación 😉
Aunque Spfx es agnóstico al Framework de desarrollo y podemos utilizar el que decida el propio desarrollador, su implementación está hecha con ReactJS. De esta forma, en caso de que se opte por el desarrollo en React, no se puede poner cualquier versión si queremos garantizar su funcionamiento.
Ahora bien, ¿por qué motivo es importante la versión 16.8? Esta versión de React trae una importante novedad: los React Hooks. Ésta es una de las novedades más comentadas dentro de la comunidad de desarrollo. Los Hooks podemos decir que han nacido para hacer más «funcional» el desarrollo en React pero siguiendo la filosofía con la que React se creo. Uno de los principales problemas en los desarrollos, es que añadimos mucho código duplicado debido a que hay que ponerlo en cada uno de los elemento del ciclo de vida: DidMount, DidUpdate,.. El uso de los Hooks dentro de Spfx, vienen como anillo al dedo…al menos así lo veo yo. Ya entraremos en detalle en futuros artículos y en el siguiente número de la Revista CompartiMOSS saldrá publicado un artículo de introducción, pero si tenéis la inquietud y no podéis esperar, os invito a que veáis el detalle en el siguiente PR que he solicitado al repositorio oficial.
Para mi está nueva característica no es precísamente una de mis favoritas.
Pongámonos en contexto. Esta funcionalidad lo que hace es que, dentro de una Aplicación de Spfx podamos tener una serie de librerías donde tener los componentes o utilidades de nuestro día a día. Esto, para los equipos de desarrollo que estén acostumbrados a Azure DevOps es algo que ya nos proporciona un Repositorio Nuget, npm para poder ser transversal al resto de proyectos de la propia organización.
¿Cuál es el beneficio entonces de las Library Components? Lo mejor que tiene es que, si esta librería la utilizamos en más de un webpart de la página, solo se carga una vez, de manera que ahorramos un pequeño tiempo en la carga de la página.
Por el contrario si lo hacemos como si fuera un paquete npm, estará incluido en el bundle de la solución en cada uno de los webparts que vamos a utilizar. Ahora bien, al ponerlo en Azure Devops nuestro desarrollo se puede reutilizar en otros desarrollos que no sean propios de Spfx.
Spfx lleva más de tres años y cada versión está más viva que la anterior. Lo que parecía otro intento de Microsoft de buscar un modelo de desarrollo, parece que ya es una realidad y que tendremos Spfx para rato.
Por este motivo hay que estar al tanto de todas las novedades que hay versión tras versión, para añadir mucho más valor a nuestros desarrollos: tanto en la utilización de las novedades que traen los nuevos framewoks, como las últimas novedades que vienen con la herramienta.
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)