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
visitOrpahanedContainerorvisitChildContainer. 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
visitNewServicemethod, 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
visitContainermethod 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
visitContaineris 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.)