Skip to content
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

Add multiple services under the same type and getMany? #8

Open
justinmchase opened this issue Jul 14, 2021 · 1 comment
Open

Add multiple services under the same type and getMany? #8

justinmchase opened this issue Jul 14, 2021 · 1 comment

Comments

@justinmchase
Copy link

justinmchase commented Jul 14, 2021

For example:

const types = {
  IA: Symbol("IA")
};

// Interfaces
interface IA {
  foo(): void;
}

// Implementations
@Service()
class A implements IA {
  public foo(): void {
    console.log("A");
  }
}

@Service()
class B implements IA {
  public foo(): void {
    console.log("B");
  }
}

// Service collection setup.
const serviceCollection = new ServiceCollection();
serviceCollection.pushTransient<IA>(types.IA, A);
serviceCollection.pushTransient<IA>(types.IA, B);

const services = serviceCollection.getMany(types.IA);
@luvies
Copy link
Owner

luvies commented Jul 18, 2021

I've seen other DI libraries with this and I do quite like it, it's just not been added before since I've not been sure on the best way to go about it. I do quite like using push[Lifetime] instead of just overloading add[Lifetime] (along with getMany instead of just an overloaded get), since it prevents any sort of misuse between single service and multi-service bindings.

I would also like for multi-service bindings to be supported with constructor and property injection. Following the separation between push and add, I think adding @InjectMany instead of overloading @Inject would be ideal. The new decorator could also be the canonical way of using multi-service injection in the constructor, so any parameters that don't have any decorator always use the single-injection mechanism (again, to prevent overloading).

If this seems reasonable I can look at adding this feature soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants