Open Leafgard opened 3 years ago
Hi!
This is the expected behavior. Since TypeDI 0.9.0 it won't create instances for unknown classes, so you need to decorate your classes. This needs to be documented and also I believe a fix is possible as routing-controller can auto-register them in its own decrator.
Hey
Thanks for the answer, I'll make a pull request tonight to add some documentation about this !
I hate to ask, but: how does something like this sound when the developer says it out loud?
A meme for the ages.
Services everywhere.
Still no solution yet for not having to put @Service() on all classes?
Hi, I have the same problem now, how do I solve it?
/Users/yacovets/Documents/GitHub/Chat-react-socket.io-nodejs/node_modules/src/container-instance.class.ts:75
throw new ServiceNotFoundError(identifier);
^
ServiceNotFoundError: Service with "MaybeConstructable<ErrorHandlerMiddleware>" identifier was not found in the container. Register it before usage via explicitly calling the "Container.set" function or using the "@Service()" decorator.
at ContainerInstance.get (/Users/yacovets/Documents/GitHub/Chat-react-socket.io-nodejs/node_modules/src/container-instance.class.ts:75:11)
NodeJs: 16.0.0 "typedi": "^0.10.0" "reflect-metadata": "^0.1.13" "routing-controllers": "^0.9.0"
index.ts
import 'reflect-metadata'
import { useExpressServer, useContainer } from 'routing-controllers'
import { Container } from 'typedi'
import './util/env'
import Server from './core'
import socket from './socket'
import * as controller from './controller'
import { ErrorHandlerMiddleware, ErrorNotFoundMiddleware } from './middleware'
import './service'
useContainer(Container)
const server: Server = new Server()
socket(server.getIo())
useExpressServer(server.getApp(), {
routePrefix: '/v1',
controllers: controller.v1,
defaultErrorHandler: false,
middlewares: [
ErrorHandlerMiddleware,
ErrorNotFoundMiddleware
]
})
server.listen()
export default server
controller.ts
import { Response } from 'express'
import { JsonController, Post, Req, Res, UseBefore } from 'routing-controllers'
import ModifiedRequest from '../../interface/ModifiedRequest'
import { CheckAuthorizationMiddleware } from '../../middleware/CheckAuthorizationMiddleware'
import {UserService} from "../../service/UserService";
import {Service} from "typedi";
@JsonController()
@Service()
@UseBefore(CheckAuthorizationMiddleware)
export default class User {
constructor(private userService: UserService) {}
@Post('/profile')
getProfile(@Req() request: ModifiedRequest, @Res() response: Response) {
return this.userService.getProfile()
}
}
service.ts
import { Service } from 'typedi'
@Service()
export class UserService {
getProfile() {
return {
ok: true
}
}
}
@jenya-yacovets Please take some time to investigate before asking someone to do your job. π
It seems like your ErrorHandlerMiddleware "Service" isn't found in Container, but since you didn't provide any part of this code, I can just guess that you forgot adding the @Service()
decorator in front of your middleware !
@jenya-yacovets Please take some time to investigate before asking someone to do your job. π
It seems like your ErrorHandlerMiddleware "Service" isn't found in Container, but since you didn't provide any part of this code, I can just guess that you forgot adding the
@Service()
decorator in front of your middleware !
Thanks! I thought that only in controllers you need to specify @Service()
This is what I'm using to save me from writing more code than necessary π :
export function ServiceController(...args: Parameters<typeof Controller>) {
return <TFunction extends Function>(target: TFunction) => {
Service()(target);
Controller(...args)(target);
};
}
export function ServiceJsonController(...args: Parameters<typeof Controller>) {
return <TFunction extends Function>(target: TFunction) => {
Service()(target);
JsonController(...args)(target);
};
}
I had to update ~60 classes to add @Service
everywhere. This is just crazy. Couldn't @Controller
decorator automatically register controller/middleware classes with the provided DIC? I guess, this should be just a couple of lines of code in the library.
it is also odd how semver is handled in the related libs - breaking changes like this require a major bump or a graceful behavior as stated in the comment https://github.com/typestack/routing-controllers/issues/642#issuecomment-777145245
@aaarichter In SemVer, going from version 0.x.y to 0.x+1.0 is considered a major bump. NPM also handles it as such, e.g. depending on typedi@^0.8.0
would install the latest 0.8.x version, not 0.9.x.
@NoNameProvided I believe this has been solved. Package is working as expected. I agree that controllers should maybe register themselves in the DI without the explicit @Service decorator but that's a feature request at this point.
Let's keep this open for tracking. I think we may auto-register services, but we need to discuss this further.
@Service()
everywhere βSymbol
everywhere βUpdate: they are the same... even TSyringe still require us to apply @autoInjectable()
on the controller level...
Any update on this? Has there been a decision on whether to support auto registering services? What would be the potential downsides?
The issue with auto registering is that we have to commit to one di lib, otherwise we cannot really register the controllers because each lib instantiates the services differently. One solution could be to provide a configurable function in the factories where you can set how you want your controllers instantiated, but we would have to resolve the dependencies ourselves then.
Description
Cannot use TypeDI as explained on the README for basic services.
Obviously, it is written that it only requires the
@Service
on service side (seems legit), but this actually doesn't work without telling@Service
before the controller as well.Minimal code-snippet showcasing the problem
Controller snippet
Actual service snippet
Expected behavior
I've imported everything and created the DI Container before the app, the Controller should be working without the
@Service
decorator declaration.Actual behavior
It doesn't, if I try to run the code without the
@Service
decorator on top of the Controller, I'll get the following error:I don't know if this is an upstream issue or not.