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
As part of #65, we have rearranged the internals of the loader, and its registry. As a result, we now have two separate entities with the following responsibilities:
Loader provides a public api to interact with modules (via their names and their referrers), and it will be reflective to what you can do with the local loader from within a module.
Registry provides low level api to interact with the registry of modules (via their keys), and it is bound to a loader instance.
But, there are two conflicting perspectives on the loader/registry responsibilities:
perspective 1: the loader provides the high level interface and the registry provides the low level interface
perspective 2: the loader provides loading pipeline and the registry stores the state
it almost works for both perspectives
Few more notes:
[[Registry]] internal slot is created and initialized in the constructor of the loader.
It is not allowed to have multiple loaders sharing the same registries.
a .registry getter in a loader instance will give you access to the corresponding registry (e.g.: let registry = System.loader.registry;)
the registry has a backpointer to its loader ([[Loader]] internal slot) in case of side effects during the interaction with the registry (e.g.: System.loader.registry.provide() or System.loader.registry.error())
As a result of this separation, we have to separate the loader API:
This is a follow up on the discussion related to PR #65
Participants: @dherman @caridy @guybedford
As part of #65, we have rearranged the internals of the loader, and its registry. As a result, we now have two separate entities with the following responsibilities:
But, there are two conflicting perspectives on the loader/registry responsibilities:
it almost works for both perspectives
Few more notes:
let registry = System.loader.registry;
)System.loader.registry.provide()
orSystem.loader.registry.error()
)As a result of this separation, we have to separate the loader API:
Loader:
note: load is now a primary use case to pre-fetch, and provision a module from a referrer.
Registry:
note: all these methods are low level, and driven by a key.
The text was updated successfully, but these errors were encountered: