Discuss
  • System as a SystemLoader class

System as a SystemLoader class

# Guy Bedford (11 years ago)

Currently if I want to subclass the System loader I need to do something like -

var newLoader = new Loader(System);
newLoader.fetch = function() {
  // ...
}

Effectively we're monkey-patching, which isn't pretty.

It would be nice to be able to do:

class newLoader extends System.constructor {
  constructor(loaderConfig) {
    this.baseURL = loaderConfig.baseURL;
    // ...
  }
  fetch: function() {
    super.fetch
  }
}

In order to allow this, we would need to first define a SystemLoader class, and make System an instance of it.

# John Barton (11 years ago)

Why not something more like:

class RemappingLoader extends Reflect.Loader {
  constructor(hooks, baseURL, paths) {
    super(hooks);
  //...
  }
  fetch(load) {
  // ..
  }
}
Reflect.global.System = new RemappingLoader(Reflect.global.System,
   process.cwd() + '/', {'*': '*.js' });

The main differences here are:

  1. This already works,
  2. Use std Loader not System.constructor,
  3. Don't attach baseURL to loaderConfig, since the loaderConfig is documented in the std.

(System is already an instance of Reflect.Loader so I'm unclear on why we need the change you suggest).

The biggest hole I see in my example is the use of Reflect.global.System as the value for the loader hooks. What I want to say here is "This platform's built in loader hooks", not "The loader hooks some random other package wrote onto System".

# Matthew Robb (11 years ago)

Because it seems likely that people will want to use the System Loader but also augment it with their own customizations. STILL benefiting from the environment specific implementation details.

# Guy Bedford (11 years ago)

I suppose a system class effectively creates a store of the environment loader hooks that can be trusted.

# John Barton (11 years ago)

Matthew Robb wrote:

Because it seems likely that people will want to use the System Loader but also augment it with their own customizations.

Yes, that is what I did below.

STILL benefiting from the environment specific implementation details.

Yes, we need ways for custom loaders to define which implementation they extend. Some may choose to extend "whatever random System was loaded last"; the rest of us would like to choose to extend definite testable Loader instance.

I suppose we can have LoadMeFirst code and all that but really this is ES6: can't we do better?