Experimental
Whether the object has already been disposed.
Dispose the object.
Either void, or a promise which settles upon completion of the disposal process.
Error This exception may be thrown in the case of an error encountered during the process of disposing the object. The type of error thrown is unknown.
Optional
visitExperimental
Visit a child container of the current service.
The newly-created child container of the current instance.
Optional
visitExperimental
Visit the given container.
This is called as a result of Container.acceptTreeVisitor(...)
.
The container to visit.
Whether the visitor can be attached to the container.
If false
is returned, no notifications are sent from the provided container.
Otherwise, all notifications from the passed are sent to the visitor.
Optional
visitExperimental
Visit a new service being added to the container.
This is called when a new service is added via Container.set(...)
.
The options of the new service.
Optional
visitExperimental
Visit a container with no parent. This is only called if the visitor was attached to the default container.
The newly-created container.
Optional
visitExperimental
Visit a request for a container to retrieve a service.
This is similar to the visitUnavailableService
handler, but it
is always called in the event of service retrieval.
If the identifier can not be found, visitUnavailableService
is then called.
The identifier of the requested service.
A set of options passed to the listener. Documented in VisitRetrievalOptions.
Generated using TypeDoc
A visitor for Container objects, which allows for extension of container functionality. This API is still being developed. It will probably change.
To aid usage of this API, some noteworthy points can be found below.
Visitors are Singletons (sort of)
By design, the visitor API is designed in such a manner that each visitor can only be feasibly attached to a single container.
This applies to child containers too: any notifications from child containers will not bubble up and trigger notifications on parent containers.
The API does not prevent attaching a new visitor to any containers passed to the visitor through either
visitOrpahanedContainer
orvisitChildContainer
. This is the recommended approach.Recursive Calls
The API does not protect against recursion. If, for example, the consumer adds a new service to the container in the
visitNewService
method, there will be an infinite loop. This can be remedied by guarding against any further recursive calls for services added by the visitor; the implementation of that is left to the consumer.Container Reference
When a visitor is attached to a container, its
visitContainer
method is called. This allows the visitor to then hold a persistent reference to said container, allowing it to interact with the container as a regular consumer. Therefore, the container the visitor is bound to is not passed for each function call. It is up to the consumer to store the container and then perform operations on it later.One important point which relates to the singleton aspect of the API design is that, as a recommended approach, if the visitor's
visitContainer
is called more than once, the later values should be ignored -- this was most likely caused due to the visitor being added to more than one container.Example
A simple example of the visitor API is as follows:
(This is a very simplified example and use-case.)