Experimento con Ionic 2 y Arquitectura Hexagonal
En este post, Dani Latorre nos contó el experimento de extraer gran parte del comportamiento de Mosica a un módulo JS. La gran ventaja de tener este core agnóstico es que debería poder integrarse con cualquier otro framework sin mucho dolor. Dani explicó cómo lo había integrado en una app Ionic 1 y ahora es el turno de Ionic 2.
Ionic 2 está basado en Angular2/4/whatever y la manera de trabajar y las herramientas que propone no tienen nada que ver con las de su predecesor. En este post vamos a ver como también es posible la integración, a pesar de esas diferencias.
Implementación del cliente Http
Recordemos que el punto de entrada a nuestro módulo core era una clase GigService que recibía la implementación de dos colaboradores (httpclient y matcher) a través de su constructor. Para el colaborador matcher vamos a reutilizar la implementación que ya teníamos en el core, pero para httpclient, igual que ocurría en Ionic 1, vamos a necesitar una implementación que tire de JSONP.
Angular2 ya incluye un módulo JsonpModule con un cliente Jsonp, lo único que devuelve un observable RxJs y nuestro objeto core GigService espera una promesa. Por eso vamos a transformar de Observable a Promesa con el método toPromise:
Podemos hacer un test de integración para ver que estamos consumiendo bien la API.
Con este nuevo servicio HttpClient ya tenemos todo lo necesario para crear una nueva instancia de GigService con algo del estilo a:
new GigService(new HttpClient(jsonP), new Matcher())
Vamos a ver como hacer para que Angular sea quien se encargue de esta construcción.
Peleando con el framework de Inyección de dependencias
Uno de los puntos clave a la hora de usar Angular es aprender a trabajar con su sistema de DI. Normalmente definimos módulos @NgModule en los que declaramos nuestras dependencias para que el framework se encargue de inyectarlas automáticamente a nuestros componentes. Nuestro caso es algo particular porque nuestro servicio y algunas de sus dependencias son completamente independientes de angular2. Vamos a ver un ejemplo.
Queremos crear un componente para mostrar una lista de conciertos que reciba una instancia de GigService entre sus dependencias:
Ahora nos toca indicarle a Angular cómo construir la instancia de gigService que recibirá ListPage o cualquier otro componente con esa dependencia en su constructor. Tenemos este escenario:
- Clase GigService que importamos del exterior (independiente de angular) y que recibe dos colaboradores
- Colaborador HttpClient (servicio angular)
- Colaborador Matcher que también importamos del exterior (independiente de angular)
La clave está en usar como provider una función factoría que se encarga de construir nuestra instancia y que, a su vez, recibe una instancia del servicio HttpClient declarada con la propiedad “deps”:
Como veis no es trivial porque requiere conocer bien las opciones que nos da el framework de DI de angular.
¿Vale la pena el esfuerzo?
Tanto Angular 1 como Angular 2 son frameworks muy opinados y pesados pero eso no tiene porque impedirnos trabajar, al menos en la parte core, con un flow similar al del backend. En estos ejemplos, estamos llevando las cosas al extremo sacando un módulo fuera de nuestro repo pero de normal se pueden aplicar las mismas prácticas sin necesidad de tanto jaleo.
Aunque tenemos nuestras preferencias a la hora de elegir frameworks/librerías para un proyecto greenfield, este tipo de experimentos nos ayuda a recordar las buenas prácticas compatibles con todo tipo de proyectos y contextos. Próximamente estaremos en Software Craftsmanship Barcelona y Codemotion Madrid compartiendo aproximaciones como ésta.
En los Coding Stones ayudamos a compañías desarrollando software, además de impartir formación y mentoring a equipos. Si crees que podemos ayudarte en la implantación del uso o mejora de este tipo de prácticas, péganos un toque y vemos si podemos tocar juntos.
