🧕🏽 👰🏽 📆 Primer DI: primer DI en interfaces para aplicaciones mecanografiadas ⛷️ 🙌🏻 🤧

Comparto una de mis bibliotecas llamada First DI. Me ha ayudado durante muchos años a resolver el problema de la inyección de dependencia en aplicaciones de navegador para bibliotecas como React, Preact, Mithril y otras. Al escribir First DI, se tomó como base la ideología de las bibliotecas DI de C # y los lenguajes Java, como autofac, java spring autowired, ninject y otros. Y al igual que las bibliotecas de estos lenguajes, First DI funciona en base a interfaces de reflexión y mecanografiado.

¿Para qué sirve la DI?

En resumen, la inyección de dependencia (en adelante DI) es una de las partes principales para construir una arquitectura limpia. Lo que le permite reemplazar cualquier parte del programa con otra implementación de esta parte del programa. Y DI es una herramienta para implementar y reemplazar partes del programa.

En particular, le permite:

Reemplazar implementaciones lógicas individualmente para cada plataforma. Por ejemplo, en el navegador, muestre las notificaciones a través de la API de notificaciones y, al ensamblar aplicaciones móviles, reemplácelas por notificaciones a través de la API de la plataforma móvil.
Reemplazar la implementación de la lógica en varios entornos. Por ejemplo, se puede utilizar una pasarela de pago o un sistema de distribución de notificaciones inaccesible desde la máquina local del desarrollador en el circuito del producto. Por lo tanto, en lugar de pagos reales o correo en la etapa de desarrollo, la lógica se puede reemplazar con un talón.
Reemplazar fuente de datos. Por ejemplo, en lugar de una solicitud real al servidor, elimine los datos previamente preparados para probar la lógica de negocios o el diseño para cumplir con los diseños.
y muchos más usos útiles, pero no se trata de eso ahora ...

Para comenzar, prepare las herramientas para el trabajo.

Preparación para el uso

Para usar, debe hacer solo 3 cosas simples:

Conecte reflejo-metadatos polyfill .
En el archivo tsconfig, habilite las opciones emitDecoratorMetadata y experimentalDecorators. El primero le permite generar reflejos, el segundo incluye soporte para decoradores
Cree cualquier decorador vacío, por ejemplo, const reflection = (..._ params: Object []): void => {} o use uno listo de la biblioteca.

Ahora demostraré el uso en su forma más simple.

Uso simple

Por ejemplo, tome un programa escrito usando Pure Architecture:

import { autowired, override, reflection } from "first-di";

@reflection // typescript  
class ProdRepository { //   

    public async getData(): Promise<string> {
        return await Promise.resolve("production");
    }

}

@reflection
class MockRepository { //       

    public async getData(): Promise<string> {
        return await Promise.resolve("mock");
    }

}

@reflection
class ProdService {

    constructor(private readonly prodRepository: ProdRepository) { }

    public async getData(): Promise<string> {
        return await this.prodRepository.getData();
    }

}

class ProdController { //   React, Preact, Mithril  .

    @autowired() //  
    private readonly prodService!: ProdService;

    // constructor  ,   React, Preact, Mithril
    //      

    public async getData(): Promise<string> {
        return await this.prodService.getData();
    }

}

if (process.env.NODE_ENV === "test") { //    
    override(ProdRepository, MockRepository);
}

const controllerInstance = new ProdController(); //   
const data = await controllerInstance.getData();

if (process.env.NODE_ENV === "test") {
    assert.strictEqual(data, "mock"); //  
} else {
    assert.strictEqual(data, "production"); //  
}

En Pure Architecture, debe agregar solo 2 líneas de código, con cableado automático y anulación para que DI comience a funcionar. Y ahora el programa ya tiene una implementación para producción y una implementación para pruebas.

Dado que First DI se escribió principalmente para aplicaciones cliente, las dependencias predeterminadas se implementarán como Singleton. Para cambiar globalmente este comportamiento, hay opciones predeterminadas, así como parámetros para el decorador con cableado automático y el método override ().

Puede cambiar de la siguiente manera:

//  1 
import { DI, AutowiredLifetimes } from "first-di";
DI.defaultOptions.lifeTime = AutowiredLifetimes.PER_INSTANCE;

//  2  
import { autowired, AutowiredLifetimes } from "first-di";
@autowired({lifeTime: AutowiredLifetimes.PER_INSTANCE})
private readonly prodService!: ProdService;

//  3  
import { override, AutowiredLifetimes } from "first-di";
override(ProdRepository, MockRepository, {lifeTime: AutowiredLifetimes.PER_INSTANCE});

Esta es la forma más fácil de usar DI. Pero en la empresa, en lugar de implementaciones específicas, se utilizan interfaces, que son un contrato para implementaciones que se implementarán. Hay un segundo modo de operación para esto.

Uso profesional

Para uso profesional, reemplazamos implementaciones específicas con interfaces. Pero typecript no genera código para ejecutar interfaces en tiempo de ejecución. Afortunadamente, hay una solución simple, para comprender es necesario recordar la teoría ... ¿qué es una interfaz? ¡Esta es una clase completamente abstracta!

Afortunadamente, typecript admite clases completamente abstractas, genera código de tiempo de ejecución y permite el uso de clases abstractas para describir tipos.

Utilizaremos esta información y escribiremos un programa empresarial:

import { autowired, override, reflection } from "first-di";

abstract class AbstractRepository { //    

    abstract getData(): Promise<string>;

}

@reflection
class ProdRepository implements AbstractRepository {

    public async getData(): Promise<string> {
        return await Promise.resolve("production");
    }

}

@reflection
class MockRepository implements AbstractRepository {

    public async getData(): Promise<string> {
        return await Promise.resolve("mock");
    }

}

abstract class AbstractService { //    

    abstract getData(): Promise<string>;

}

@reflection
class ProdService implements AbstractService {

    private readonly prodRepository: AbstractRepository;

    constructor(prodRepository: AbstractRepository) {
        this.prodRepository = prodRepository;
    }

    public async getData(): Promise<string> {
        return await this.prodRepository.getData();
    }

}

class ProdController { //   React, Preact, Mithril  .

    @autowired()
    private readonly prodService!: AbstractService;

    // constructor  ,   React, Preact, Mithril
    //      

    public async getData(): Promise<string> {
        return await this.prodService.getData();
    }

}

override(AbstractService, ProdService);

if (process.env.NODE_ENV === "test") {
    override(AbstractRepository, MockRepository);
} else {
    override(AbstractRepository, ProdRepository);
}

const controllerInstance = new ProdController();
const data = await controllerInstance.getData();

if (process.env.NODE_ENV === "test") {
    assert.strictEqual(data, "mock");
} else {
    assert.strictEqual(data, "production");
}

Ahora tenemos un programa profesional listo que no tiene una implementación predeterminada, y todos los contratos se reemplazan por implementaciones que ya están en la etapa de ensamblaje de la aplicación.

Es así de simple incrustar DI en su aplicación. Y aquellos que escribieron en C # y Java podrán usar la experiencia existente en desarrollo web.

Otras características

Usando múltiples copias de DI:

import { DI } from "first-di";
import { ProductionService } from "../services/ProductionService";

const scopeA = new DI();
const scopeB = new DI();

export class Controller {

    @scopeA.autowired()
    private readonly serviceScopeA!: ProductionService;

    @scopeB.autowired()
    private readonly serviceScopeB!: ProductionService;

    // constructor  ,   React, Preact, Mithril
    //      

    public async getDataScopeA(): Promise<string> {
        return await this.serviceScopeA.getData();
    }

    public async getDataScopeB(): Promise<string> {
        return await this.serviceScopeB.getData();
    }

}

Extensibilidad, puede escribir su propia DI:

import { DI } from "first-di";

class MyDI extends DI {
    // extended method
    public getAllSingletons(): IterableIterator<object> {
        return this.singletonsList.values();
    }
}

Y muchas más características interesantes se describen en el repositorio en GitHub .

¿Por qué el tuyo está escrito y no se usa?

La razón es simple: cuando se escribió este DI no había alternativas. Este fue un momento en que el angular 1 ya no era relevante, y el angular 2 no iba a salir. Las clases acaban de aparecer en Javascript y la reflexión en mecanografiado. Por cierto, la aparición de la reflexión se ha convertido en el ímpetu principal para la acción.

InversifyJS: incluso en su forma actual no me conviene. Demasiado repetitivo. Además, el registro por línea o carácter en el otro lado mata la posibilidad de refactorizar dependencias.

¿Gustó?

Si le gustó este DI, ayúdelo a hacerlo más popular. Experimente con él, envíe solicitudes, ponga estrellas. Repositorio de GitHub .

Primer DI: primer DI en interfaces para aplicaciones mecanografiadas