-
Notifications
You must be signed in to change notification settings - Fork 3
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 a (better) way to notify services of container disposal #4
Comments
Oh, interesting. I was wizzing about yesterday and must have missed this in typedi/src/container-instance.class.ts Lines 723 to 741 in d970fdc
This seems like a major hack. The service might not be expecting the DI container |
One possible implementation of this could be as follows: import { Service, OnDispose } from '@typed-inject/injector';
@Service([OnDispose()])
export class MyService {
constructor (private onDispose: OnDispose) { }
bootstrap () {
this.onDispose(() => console.log('being disposed'));
}
} |
A much simpler implementation would be the usage of |
Currently, containers are just dropped from the service with no warning:
typedi/src/container-instance.class.ts
Lines 556 to 572 in ee8a84e
This seems quite strange. Services would surely want some form of notification
as to when their container is disposed of.
While a seemingly simple concept, the notion of how individual services are meant
to respond to such a notification is ambiguous. For instance, in the case of a database
service, is it meant to close down its database connection(s) when the container is disposed?
Furthermore, in such a case, should we provide a way for the caller of
.dispose
or.reset
toknow when all such asynchronous events have been concluded?
One further challenge is how you would provide an API for such a notification.
It would be awkward to make services conform to a standard interface for notification,
and any runtime type-checking of notification handler methods could incur runtime errors.
This somewhat ties into typestack/typedi#230:
Proposed APIs
Addition of
@DisposeService
decoratorThe decorator allows a list of dependencies to be passed.
The dependencies are guaranteed not to be disposed before
the returned
dispose
promise is settled.For example, in the case of
RootService
, it may want toperform further operations on the database (flushing caches, etc.)
before the database is disposed of (which would close the connection).
In this case, it can declare that it requires
DatabaseService
to dispose ofthe application correctly. As such, it can return a Promise that, until settled,
will have an undisposed reference to
DatabaseService
available.Use
HostContainer
This is already a no-go, but for posterity...
Using this API would mean that tests would have to pass in a container instance for potentially nothing.
Also, we'd have to expose an
addDisposeListener
or the likes onto the class, which feels awkward.Definitely needs further investigation.
The text was updated successfully, but these errors were encountered: