allow parametrized resolution of services through getParametrized method #79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi Thiago,
Thank you for working on typescript-ioc.
The package is great! To me it looks like the "proper" implementation of IoC container, with regards that information about interfaces is not propagated to runtime.
This PR is a suggestion about supporting the design pattern I am using a lot while working in MVVM approach. It comes from classic WPF's MVVM but the same looks handy while working with typescript UI using MVVM-ish architecture.
The UI is commonly represented with components(controls) tree. In MVVM approach, component is driven by the data, gathered and persisted within the viewmodel, dedicated to this component or to components subtree.
ViewModels essentially have a dependencies on the domain/infrastructural services. This is where IoC container comes to play.
However, viewmodel might by instantiated within the components subtree so it might rely on the instance-specific parameters.
Consider an example: we have a list of accounts with a complex and comprehensive UI.
We may want to build a viewmodel-per-account which would have the following dependencies: accountId, accountsDao.
AccountsDao can be injected by IoC container, however accountId is specific to particular viewmodel instance.
Below is an ugly solution I am using at the moment for my actual projects:
But this solution prevents from using single resolution context while calling
new AccountVM(accountId)
. Scope.Request is effectively bypassed while working with this approach.This PR contains the new public function
getParametrized<T>(source: Function & { prototype: T }, ...contextParams: Array<any>)
For the example above, it is supposed to be called this way:
Container.getParametrized(AccountVM, 1)
The function replaces first X arguments of constructor with the X values, provided as rest parameters of Container.getParametrized function.
I've added some test coverage to illustrate the usage and the way instance-specific parameters interferes with injected parameters.
Note, that I've also modified the way @Inject decorator for constructor arguments works.
Previously, if developer does this:
instance of type Cccc, would have been injected in the constructor argument having 1st position. So in runtime, one would have variable
b
of typeCccc
. Even though such usage of decorators is highly questionable, it still doesn't looks as a correct behavior.Same change is applied to @InjectValue decorator.
Let me know your thoughts about this PR.
I know that adding new methods to the public API should be done with a huge caution so consider this PR as a starting point for conversation, rather than an actual pull request.