Loader Event on new Container resolve/request

[anthony-murphy]

i've actually been thinking we probably want an event on the loader for everytime a container is created, as i see hosts wanting to hook up logging, error handling, etc on every contianer loaded through their container

Originally posted by @anthony-murphy in #5112 (comment)

[curtisman]

I think the feature would be great to have. Need to consider the consequence of having this global information exposed to every one that has access to the loader. This should only be exposed to the creator/owner of the loader/host only, and probably need to have a way to restrict it when passing it around.

[anthony-murphy]

great point. i actually think we need to split the loader interface in two, one that get's passed down and only has resolve/request, and the other that has create, and such for the host

[vladsud]

I'd suggest accepting a "policy" object at Loader creation that controls certain aspects of each container in the loader and has visibility to new containers being created. This would simplify logistics around caching, for example. Today, we expose certain capabilities (like Container.forceReadonly, or pausing ops loading on boot) that have global impact (i.e. impact cached version of container that next user would get). And reverse - nested containers are not visible to host, and thus they can't apply same policy they are applying to external container. I'd make all these APIs only visible to this policy object, such that it could uniformly apply these policies to all containers (if it wants to), and leave it up to it decisions around caching and cashability of containers (possibly).

[ghost]

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!