Make Container hooks more useful for dynamic registration #274
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.
This is a (long-overdue) followup PR to our conversation related to integrating APM into a Dry-System app.
Also relates to hanami/hanami#1360
Use Case: I want to be able to dynamically decorate keys as they are added into the container system in order to perform APM metrics without having to touch every file.
Use Case: I want to audit the usage of particular namespaces in the Container using Dry-Monitor decoration, such as producing an audit log of Authorization checks.
In these use-cases, it's important that I want to react to container registration without having knowledge of precisely what keys are being registered. The decorate feature works well when keys are known in advance, but otherwise you have to enumerate the keys in the container after registration.
Enumeration is a problem, because
after_finalize
is called after the container is frozen, which is too late to decorate key values.This PR makes two changes:
after_register
hook that fires whenever a key is registeredafter_finalize
to happen prior to freezing the container.This allows us to either decorate keys dynamically as they are registered, and to enumerate the container keys before the container is frozen in case we want to make alterations.
Due to the complexity of Container value storage between memoization and callable, I opted not to expose the key value directly; the hook code may choose to call
resolve
if it needs that.