Multiple instances of Loader

[sheerun]

Just heads up, it's important for some developers to be able to instantiate Loader multiple times:

systemjs/systemjs#60 (comment)

Please don't make System a singleton, but only a default instance. Also class-based approach is desired.

[matthewp]

👍 Agreed, multiple loaders is very important.

[dead-claudia]

Maybe bringing back the Reflect.Loader constructor and System being only an instance, like how the API was at first in ES6 before getting pulled out into its own spec, would be the easiest way to resolve this.

[dherman]

Multiple loaders could mean a few different things. Having separated out the Realm API from the Loader API makes it less clear to me how much of the functionality of multiple loaders should be achievable via new Realm and how much should be achievable via a Loader constructor.

For your use cases, do you only want different loading policies, but a shared registry between the two loaders? Or do you want to completely distinct registries? It seems reasonable to me to achieve distinct registries by creating new Realms, although maybe that's too hard to polyfill.

[guybedford]

The main use case for multiple loaders comes up when doing a build in Node. It is nice to not tie the build itself to the global environment it is running in, and be able to easily create and dispose loaders during the process. Being able to spin up a loading context without worry of clashes among other dependencies is very useful here. @matthewp can probably describe these use cases better as well.

[matthewp]

What @guybedford said, but also Loaders are useful whenever you need to load stuff that's not modules. For example Less.js has it's own loading pipeline which could be implemented as a custom Loader. This would make it more easily hackable. Eventually it would be interesting if HTML tags used custom Loaders to do the work. For example if all s went through window.imageLoader I could implement a translate hook that make them all greyscale.

[caridy]

I haven't seen a good use-case that requires sharing the registry. I think spinning up a new instance in a new realm could keep things easy and simple. We have a pretty basic (and small) Realm polyfills that we can probably adjust to support this today.

[matthewp]

This seems like it's going to make creating custom loaders much more difficult. If I'm a module loader author I now have to tell my users to create a new Realm? The class-based approach as @sheerun suggested seems natural in this case. It makes extending far more elegant than writing wrappers around a singleton. But I admittedly missed the conversations, why would a Loader be tied to a Realm anyways?

[johnjbarton]

Another reason for multiple loaders is testing. The test driver code needs to use a solid Loader while allowing mocks and fakes to be loaded for code being tested. Forcing test drivers to work through Realms would be a big barrier.

[dherman]

After sleeping on it I don't really see why I was confused. While in the olden days the Loader constructor would give you a separate registry and a separate realm, it makes sense to think of a loader as encapsulating a registry but simply being tied to a realm. IOW the Realm constructor lets you create a realm and the Loader constructor lets you create a registry. This all seems like a pretty natural separation of concerns.

It also seems clear that fresh loaders should have distinct registries that start out empty. If you want to share between registries you can manually copy entries from one registry into another. (I guess one question would be whether there'd be use cases for actually keeping two registries in sync... maybe you could express that via the hooks?)

To sum up:

• new realm: new Reflect.Realm
• new registry: new Reflect.Loader
• new realm and new registry: new (new Reflect.Realm).global.Reflect.Loader

Seem good?

Dave

[guybedford]

👍

[matthewp]

Sounds good! Will have to look it over when you update the spec. Being able to extend the default loader (whatever System is becoming) would be important as well. Assuming it's an instance of Reflect.Loader and we're not setting the hooks the old way I think it should work.

[caridy]

To sum up:

• new realm: new Reflect.Realm
• new registry: new Reflect.Loader
• new realm and new registry: new (new Reflect.Realm).global.Reflect.Loader

👍

[matthewp]

@dherman I do have a use case in mind for keeping separate registries in sync. Doing this would require a way to iterate over the registry which I don't think is currently specced. I'll create a new issue to discuss this.