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
Would it be possible to add something like Guice's ProvisionListeners 1?
Context: I use one injector per test. I want to clean up resources used by injected instances after the test completes.
Prior art: I have seen some notions like AutoDispose by other Dart-land injectors but they didn't look appealing to me. I am familar with and use Guice's ProvisionListener API for the same purpose in Java - via a Junit rule that creates the injector, listens to provisions and triggers Closeable.close() upon teardown. This is particularly handy for Singleton instances (like say ConnectionPools) which don't typically expect their close() to be triggered during the application's lifetime, but will need to be closed during tests.
I also did not consider any specific solution just to close resources. A general solution like a ProvisionListener seems easier to maintain than a specific solution that imposes a certain convention on users.
The text was updated successfully, but these errors were encountered:
Would it be possible to add something like Guice's ProvisionListeners 1?
Context: I use one injector per test. I want to clean up resources used by injected instances after the test completes.
Prior art: I have seen some notions like AutoDispose by other Dart-land injectors but they didn't look appealing to me. I am familar with and use Guice's ProvisionListener API for the same purpose in Java - via a Junit rule that creates the injector, listens to provisions and triggers
Closeable.close()
upon teardown. This is particularly handy for Singleton instances (like say ConnectionPools) which don't typically expect theirclose()
to be triggered during the application's lifetime, but will need to be closed during tests.I also did not consider any specific solution just to close resources. A general solution like a ProvisionListener seems easier to maintain than a specific solution that imposes a certain convention on users.
The text was updated successfully, but these errors were encountered: