En algún momento del ciclo de vida del software, una solución implementada en AngularJS se deberá migrar a Angular buscando un sistema que nos permita llevarla a cabo minimizando los riesgos. Ante esta situación siempre nos surge la misma pregunta: ¿Cómo migrar de AngularJS a Angular?

¿Por qué se necesita migrar de AngularJS a Angular?

La mejora contínua es un proceso iterativo para lograr que una solución sea de calidad. Este proceso lo ligaremos en este artículo en la absorción de una nueva versión del framework. Seguramente si se realiza una búsqueda sobre las diferencias que hay entre AngularJS y Angular aparecerán decenas de entradas indicando básicamente sus beneficios.

En el caso que nos va a ocupar veremos una estrategia de migración desde una versión de angular versión 1.4 (AngularJS) a una versión 2 ó superior (Angular) utilizando una librería de terceros  llamada “ng-metadata” como paso intermedio.

¿Qué conseguimos?

Los beneficios de esta migración son obvios:

  1. Nuestro software no se quedará obsoleto.
  2. Aumento rendimiento: Tanto a nivel de desarrollo como de ejecución.
  3. Minimizar bugs: problemas de seguridad, etc.
  4. Ofrece nuevas posibilidades de desarrollo.

Riesgos:

  1. Incompatibilidades entre librerías.
  2. Nuevos bugs.

Objetivo

El objetivo de este artículo no es ver como se hace una migración con dicha librería, sino más bien una posible alternativa de migración teniendo en cuenta los pasos que deberíamos seguir para su consecución, sus logros así como sus riesgos siguiendo las siguientes premisas:

  1. Migración de angularJS a Angular.
  2. Desarrollar nuevas funcionalidades a la vez.

Antes de empezar

Como primera acción debe crearse una planificación o calendario con sus hitos, proyecciones, etc. teniendo en cuenta las dos premisas haciendo las estimaciones pertinentes y asignando los recursos necesarios (y como muchas veces, no suele cumplirse).

Situación inicial

Tenemos un proyecto de una gran envergadura con múltiples servicios, controladores, directivas, … en AngularJS versión 1.4.

Después de buscar por Internet y valorar las diferentes alternativas, existe una librería llamada “ng-metadata” que puede ayudarnos.

ng-metadata

¿Qué es? En resumen y tal como reza su web:  “Angular 2 decorators and utils for Angular 1.x”.

Esto es que a la hora de programar podemos poner los decoradores de Angular 2 (@Component, @Injectable, …) trabajando sobre un archivo en TypeScript.

Podemos dejar de programar en JavaScript para empezar a hacerlo en TypeScript

Al compilar el TypeScript (.ts) se generarán los archivos .map y .js necesarios que no dejan de ser por ello servicios, controladores en AngularJS ya que es el framework que subyace.

Las ventajas:

  1. Usar TypeScript.
  2. Se trabaja como si fuera Angular 2.

Riesgos:

  1. Mantenimiento de la librería: Si observamos algún bug, anomalía, etc. la espera a su resolución puede hacer demorar el calendario.

Preparación del proyecto

Situación inicial

Llegar a tener esta situación inicial es un trabajo realmente arduo, dado que hay varias puntos que hacer en el proyecto entre las que destacan:

  1. Actualizar AngularJS a su máxima versión 1.5
    1. Comprobar que todas las librerías pueden ejecutarse en esa versión.
  2. Incorporar TypeScript al proyecto.
  3. Incorporar ng-metadata.
  4. Actualizar si se puede otras librerías
  5. Y mientras tanto, configurar el proyecto para que todo siga funcionando:
    1. Crear entorno para los nuevos desarrollos y las migraciones que se vayan haciendo.

Esta situación inicial, la puede llevar a cabo un equipo mientras otros siguen su día a día, solo que al final se tendrá que actualizar el proyecto inicial con las novedades entregadas.

Migración y nuevos desarrollos

Una vez se tiene el proyecto sobre el cual empezar, se pueden dedicar esfuerzos tanto a la migración como al nuevo desarrollo. Para la migración, habrá que hacer una relación de controllers, services, … que están en versión 1.x para poder saber lo que hay así como adoptar una estrategia de modularización.

En esta estrategia, hay que separar  los servicios comunes a toda la aplicación, así como los más específicos para una tarea, pensando sobre todo en que un componente o funcionalidad sea lo más autocontenida posible (encapsulación) dando lugar al “Separation of Concerns”.

Se pueden crear lo que podríamos llamar microcomponentes (aquellos que realizan una tarea muy simple y definida), como por ejemplo:

  • Componente de rangos: fechas desde y hasta, …
  • Componente de lista desplegable que cargue los ítems específicos. Pueden ser años, colores, entidades del dominio, …
  • Etc.

O componentes más complejos como por ejemplo:

  • Componente de criterios de selección que incorpora a su vez otros componentes o microcomponentes.
  • Componente de formulario de entrada de datos.
  • Etc.

Así pues, para la migración habrá que escoger un controlador/servicio, … y hacer su migración (y sus tests unitarios) teniendo en cuenta que:

  1. El código moverlo de javascript a typescript
  2. Utilizar decoradores de ng-metadata

Hay mucho que saber y decidir cómo:

  1. Identificar las entidades, crear interfaces, crear la clase.
  2. Identificar controladores y crear los componentes.
  3. Identificar los diferentes tipos de servicios (servicio, factoría, …) y crear el servicio.
  4. Identificar las directivas y crearlas.

Finalizando

Para acabar, una vez realizada toda la migración habrá que:

  • Deshacerse tanto de AngularJS (y adoptar Angular 2.x ó superior) como de la librería ng-metadata.
  • Se tendrán que modificar todos los “imports” realizados del “ng-metadata” por su “@angular/core” u otros imports, pero esta es una tarea de sustitución solamente que no debería dar complicaciones.
  • Importar todas las librerías de terceros para la versión específica de Angular.
  • Obviamente, ejecutar los tests unitarios, probar la aplicación, pasar los tests E2E, etc.

Conclusiones

Dependiendo de la complejidad del proyecto puede ser un trabajo fácil y rápido o difícil y lento, pero es una posible estrategia para migrar y hay que planificarla y ejecutarla ordenadamente.

No obstante puede suceder (y sucede) que a mitad del trabajo se decida pasar directamente a Angular sin utilizar ninguna librería intermedia, lo que significa parar todo nuevo evolutivo y crear un proyecto paralelo en Angular para estar todos dedicados a la migración directa. Bueno, todo depende de las circunstancias estratégicas de la empresa.

Después de todo esto, ¿todavía te surgen dudas para migrar de AngularJS a Angular? ¡Al menos ya tienes una estrategia más a considerar!