You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
In our codebase, the current dependency container can accept resolution requests for types not yet registered in the container. In our code it returns a "future", but I think to be more correct, we'd return a Promise from the container that would be fulfilled in the future either 1) when the type is registered or 2) on first non-forward resolution (the user should be able to choose between policies)
Alternate solutions
I worked around this by using a separate service within the container to track outstanding resolution requests and resolve them per policy when the types are registered with the container.
The text was updated successfully, but these errors were encountered:
That might work - I started looking at this as resolvePromise(...) : Promise, but I got hung up on my idea that we could make it so that when that registration is actually resolvable, the promise would get resolved(i.e., if you try to resolvePromise<Foo>() but Foo's dependencies are not yet registered, nothing happens until eventually they are registered, then the promise completes). I'm not sure that is actually possible. What we have today in my codebase is resolveFuture which returns a Promise that gets resolved when someone calls resolve on the type, allowing the user to take an action before the resolved type is returned to the caller of resolve.
So, I was starting to think more broadly about adding an interception API to TSyringe that would allow for this, though I could simply write it as it works today in resolveFuture. My fear about that is that I'm unsure if it's a generally useful thing, or if it's application specific.
Description
In our codebase, the current dependency container can accept resolution requests for types not yet registered in the container. In our code it returns a "future", but I think to be more correct, we'd return a
Promise
from the container that would be fulfilled in the future either 1) when the type is registered or 2) on first non-forward resolution (the user should be able to choose between policies)Alternate solutions
I worked around this by using a separate service within the container to track outstanding resolution requests and resolve them per policy when the types are registered with the container.
The text was updated successfully, but these errors were encountered: