Skip to content

The container should support forward resolution #120

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

Closed
MeltingMosaic opened this issue Jul 31, 2020 · 2 comments
Closed

The container should support forward resolution #120

MeltingMosaic opened this issue Jul 31, 2020 · 2 comments
Assignees

Comments

@MeltingMosaic
Copy link
Collaborator

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.

@Xapphire13
Copy link
Collaborator

Are you thinking something like container.resolve(..., { allowDelayed: true }) which would return a Promise?

@MeltingMosaic
Copy link
Collaborator Author

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.

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

No branches or pull requests

2 participants