You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Middlewares should be created by http request scoped container.
Since by default they are not singleton it does make sense to create them using per-request container, which allows to inject request-scoped dependencies in constructor instead calling this.httpContext.container.get(...). For middlewares that are registered as singleton nothing will be changed, so it should add any performance difference.
Current Behavior
Right now middlewares in express-utils are always created using root container which does not allow to inject request scoped variables in constructor.
it("Should allow constructor injections from http-scope in middlewares",async()=>{constTYPES={Value: Symbol.for("Value"),ReadValue: Symbol.for("ReadValue"),HttpContextValueSetMiddleware: Symbol.for("HttpContextValueSetMiddleware"),HttpContextValueReadMiddleware: Symbol.for("HttpContextValueReadMiddleware"),};classHttpContextValueSetMiddlewareextendsBaseMiddleware{publichandler(req: express.Request,res: express.Response,next: express.NextFunction){this.bind<string>(TYPES.Value).toConstantValue(`MyValue`);next();}}classHttpContextValueReadMiddlewareextendsBaseMiddleware{constructor(@inject(TYPES.Value)privatevalue: string){super();}publichandler(req: express.Request,res: express.Response,next: express.NextFunction){this.bind(TYPES.ReadValue).toConstantValue(`${this.value} is read`);next();}}
@controller("/http-scope-middleware-injection-test")classMiddlewareInjectionTestControllerextendsBaseHttpController{constructor(@inject(TYPES.ReadValue) @optional()privatevalue: string){super();}
@httpGet("/get-value",TYPES.HttpContextValueSetMiddleware,TYPES.HttpContextValueReadMiddleware)publicgetValue(){returnthis.value;}}constcontainer=newContainer();container.bind<HttpContextValueReadMiddleware>(TYPES.HttpContextValueReadMiddleware).to(HttpContextValueReadMiddleware);container.bind<HttpContextValueSetMiddleware>(TYPES.HttpContextValueSetMiddleware).to(HttpContextValueSetMiddleware);container.bind<string>(TYPES.Value).toConstantValue("DefaultValue");constapp=newInversifyExpressServer(container).build();awaitsupertest(app).get("/http-scope-middleware-injection-test/get-value").expect(200,"MyValue is read");});
Context
In application I would like to register some values in middlewares at the beginning of the request and then use classes that abstract HTTP specific things for the consumers. Allowing to inject dependencies into middleware constructor simplifies unit testing of those middlewares.
Your Environment
NodeJS 12.x.x
Windows
The text was updated successfully, but these errors were encountered:
@PodaruDragos hey there, not really. The issue is when I do
this.bind(..).to...();
in middleware, I cannot inject it using constructor to middleware. I have to use httpContext.containter.get(). While it works as workaround, it is better from testability and cleanness to inject it via middleware constructor, even if it was bound to container on httpContext.
You might see that behavior in test that I have added.
Expected Behavior
Middlewares should be created by http request scoped container.
Since by default they are not singleton it does make sense to create them using per-request container, which allows to inject request-scoped dependencies in constructor instead calling
this.httpContext.container.get(...)
. For middlewares that are registered as singleton nothing will be changed, so it should add any performance difference.Current Behavior
Right now middlewares in express-utils are always created using root container which does not allow to inject request scoped variables in constructor.
Possible Solution
PR: https://github.com/inversify/inversify-express-utils/pull/325/files
Steps to Reproduce (for bugs)
Context
In application I would like to register some values in middlewares at the beginning of the request and then use classes that abstract HTTP specific things for the consumers. Allowing to inject dependencies into middleware constructor simplifies unit testing of those middlewares.
Your Environment
NodeJS 12.x.x
Windows
The text was updated successfully, but these errors were encountered: