-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow routes to have a unique IoC container per request #779
Comments
I assume this would break other DI containers, don't think we can do that without a proper strategy. |
I don't think it would. From the tsoa side, the container would just be loaded out of the request (if it's available). Nothing has really changed, except for the source of the container. {{#if ../../iocModule}}
let container: any = iocContainer;
if (Reflect.hasOwnProperty('getMetadata')) {
let meta = Reflect.getMetadata('tsoa:request-meta', request);
if (meta.container) {
container = meta.container;
}
}
const controller: any = container.get<{{../name}}>({{../name}});
if (typeof controller['setStatus'] === 'function') {
controller.setStatus(undefined);
}
{{else}} And then, from the user side, documentation would need to be added to show that adding some metadata will enable this functionality.
|
I also have a use case that needs to take request object into consideration when resolving controllers from the iocContainer, but I propose an opt-in option that would add the request object as a second parameter to |
@celebro I like that better. I removes all implementation details away from tsoa. |
Hi @WoH, I've just seen you've labelled this. I will look at putting something together. |
I'm submitting a ...
I confirm that I
Description
I'm currently working on a project where I am migrating from inversify-express-utils to tsoa, and I'm looking to replicate some functionality.
In inversify-express-utils, each request gets it's own IoC container. This allows data (in my case an ID) to be bound to the container and then injected into services.
With tsoa, there is only one IoC container which is loaded from the user-defined IoC module and used in the routes:
With inversify-express-utils, the Express app is built with middleware that adds a child container to each request using Reflect and reflect-metadata.
https://github.com/inversify/inversify-express-utils/blob/bc40bb7671e0d4d8183266b3b3d563bb62056618/src/server.ts#L102
This is then extracted when handling the request and used to load the controller.
https://github.com/inversify/inversify-express-utils/blob/bc40bb7671e0d4d8183266b3b3d563bb62056618/src/server.ts#L248
Currently, I've implemented the middleware that adds the container to the request and I'm using a modified template to load that container out of the request so it can be used as the IoC container.
Is this something tsoa would support?
If so I'm happy to get a pull request started. Below is the minimal change in my project in order to support this, but more work would need to be done for tsoa.
The text was updated successfully, but these errors were encountered: