Extrayendo código de un controlador a una directiva en Angular

Al final del post anterior de esta serie, habíamos eliminado bastante duplicación de un controlador de Angular usando eventos para que el controlador se comunicase con algunos de los widgets que colaboran con él. Este era el código en ese momento: [gist id="46df074acc3a9897e5ac"] A continuación, aprovechamos el desacoplamiento proporcionado por el uso de eventos para mover el resto del código relacionado con el rango de fechas a una directiva de Angular. En primer lugar creamos la directiva: [gist id="4b300eff502eb8f77dac"] a donde movimos el código que crea e inicializa el widget del rango de fechas. Luego movimos todo el html que usaba dicho widget en track-index.html al template date-range.html template: [gist id="cd9c0b7f614329d9bc90"] En track-index todo este código quedó sustituido por: [gist id="c2708dfb65ce89a5f9c3"] Tras este cambio dateRangeWidgetFactory ya no es inyectado en el controlador y desapareció todo el código de creación e inicialización del widget: [gist id="a40d9dd46c6bedb95414"] Probablemente este es el diseño que deberíamos haber usado desde un principio (con una directiva y un widget para el rango de fechas comunicándose por eventos con el controlador), pero no fue así porque teníamos mucha prisa y porque aún estabamos aprendiendo cómo se suponía que debía ser el diseño de la página. Otro motivo es que aún estabamos buscando formas de no repetir errores cometidos en el pasados en el desarrollo de otras aplicaciones Angular. Compara la versión actual del código con la versión a partir con la que comenzamos los refactorings descritos en estos últimos posts (el código era mucho más largo, aquí sólo estamos mostrando el código que tiene que ver con el rango de fechas) que no tenía ningún test y, cómo pudimos comprobar al testearla, contenía varios bugs: [gist id="f07c7f96f34b4475bdd7"] A partir de este código, extrajimos a un objeto JavaScript simple la lógica que gestionaba el rango de fechas y la testeamos (siguiendo el mismo procedimiento descrito para otro caso en este post). Luego, continuamos eliminando más duplicación del controlador usando eventos (descrito en este otro post). Y, finalmente, creamos una directiva para el rango de fechas. Personalmente, creo que hicimos algo muy similar a lo que describe Liz Keogh en su post If you can’t write tests first, at least write tests second:

• No sabíamos cómo desarrollar este código usando TDD porque nos encontrabamos en una situación de cambios continuos, mucha incertidumbre y mucha presión de tiempo. Así que escribimos un código desastroso que más o menos funcionaba y nos permitió aterrizar el aspecto y la funcionalidad. A partir de ahí, lo pusimos bajo tests y empezamos a mejorar su diseño.

La versión original de este post se encuentra en garajeando.blogspot.com.es.