-
Notifications
You must be signed in to change notification settings - Fork 169
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
Factory aware of target class that resolves the factory's type. #56
base: master
Are you sure you want to change the base?
Conversation
src/types/dependency-container.ts
Outdated
@@ -39,7 +39,9 @@ export default interface DependencyContainer { | |||
instance: T | |||
): DependencyContainer; | |||
resolve<T>(token: InjectionToken<T>): T; | |||
resolve<T>(token: InjectionToken<T>, parent?: constructor<any>): T; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can remove the optionality of the parent
param since we have the above overload. (same with resolveAll(...)
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the optionality, and updated predicateAwareClassFactory
to match.
Is there anything a non-committer like me can do to help get this merged? |
@asciidisco, hang tight; I will give this another look over this week. Thanks for your patients =] |
I think that passing a |
I don't own neither the PR nor would I consider myself a domain expert in DI/IoC topics nor Typescript, so I don't know how much weight you should put on my thoughts. Back in the day when I started as a developer in the web sphere, things like you mentioned with Summed up, I'd be happy with the approach of passing just the metadata that @MeltingMosaic proposed, as it would enable the use cases I have. I'd even go that far & say that the metadata approach would not limit the proposed functionality to be used in I'm thinking of something like this: import { autoInjectable, SomeMagicMetadataInterface } from 'tsyringe'
@autoInjectable()
export class Logger {
private name: string
constructor({ name }: SomeMagicMetadataInterface) {
this.name = name
}
public info(message: string) {
console.log(`[${this.name}] ${message}`);
}
}
@autoInjectable()
export class TestClass {
constructor(private logger: Logger) {
logger.info('test') // [TestClass] test
}
} Don't know if this is a bit far fetched, but it could potentially reduce boilerplate code a bit further. |
I'm still a little torn on which approach is best for this; I can see on one hand that a metadata object is just the right amount of context that the problem needs, but on the other do see how passing the target itself could enable some pretty cool stuff in the right hands. I'm thinking maybe for now to go the route of the metadata object, starting with what we need (the targetName). And if in the future we need more (such as targetConstructor), then we can add as needed as a non-breaking change. With regards to your idea of allowing the metadata object be injected into a class, I'm not so sure I would want to allow this; I can see this leading to code that's written in a super tight-coupled way to the DI framework, when the whole point of DI is to promote loose-coupling. |
@perf2711, are you still working on this? |
@Xapphire13 sorry, no, not at the moment. |
This pull request enables factory for resolving dependencies to see which class is using the factory to resolve the dependency.
For example, when you use factory to resolve
Logger
class, which contains parametername
in its constructor, you can provide parent's class name to automatically name the logger.Example of final usage: