Discuss
  • Import Expressions

Import Expressions

# Calvin Metcalf (11 years ago)

if import statements could function as AssignmentExpression, they would be a lot more useful, something like

var foo = import 'ModuleSpecifier';
someFunc(import('somethingElse'));

It could still be statically linked regardless of whether the code was run, but instead of creating a binding, the modules loaded in this way could be stored in a Map, calls to import would resolve to the entry for the module. If the module has a default export it would be returned, otherwise it would return the module object.

This would not effect the loading semantics as the modules would still be loaded once at the top of the scope, and the always loading even if the code never runs has not proven to be an issue in AMD modules (when they are used as define(function(require, exports, module){}).

You guys have been doing heroic work and I (and others I'd assume) are very grateful and something for imports along these lines would help with patterns that a lot of experience in node and AMD has shown to be common, much like the default exports helped make exports feel a lot saner when coming in from CommonJS/AMD.

Thanks for all your work guys.

# Domenic Denicola (11 years ago)

Just to be clear: this is for an ask such that

var foo = Math.random() > 0.5 ? import 'bar' : import 'baz';

loads both 'bar' and a'baz' every time.

# Calvin Metcalf (11 years ago)

Yes

# Brendan Eich (11 years ago)

The smell of expressions which evaluate depending on control flow not matching both branches preloading is enough that TC39 defers this and sticks to the ES6 grammar as proposed. We need to see enough clear use-cases where it wins to have import expressions, and there's no blow-back from both loading.

# Calvin Metcalf (11 years ago)

what I'm talking about would be sugar for something functionally equivalent to:

import 'bar' as ___temp1;
import 'baz' as ___temp2;
var foo = Math.random() > 0.5 ? ___temp1 :___temp2;

but if import statements that conditionally run is such an issue than make it an error for them to be not in the top level scope or to be in ternary expressions.

use cases would include:

  • importing functions that serve as methods
obj.method = import 'something';
  • or maybe you want to inherit from something in another module
class foo extends import 'bar' {

}
  • importing things into an array
var thing = [import 'a', import 'b'];
  • you want to import into a WeakMap
wm.set(something, import 'somethingelse');

all of these can be rewritten in a more verbose manner to work with the current syntax, but it's just awkwardly obtuse syntax.

# Kevin Smith (11 years ago)

all of these can be rewritten in a more verbose manner to work with the current syntax, but it's just awkwardly obtuse syntax.

That's an overstatement. I appreciate the effort you're applying, but you would probably be better served applying that effort in other areas. The ES6 module syntax isn't going to change at this point.

# Juan Ignacio Dopazo (11 years ago)

I think it's good that imports are not expressions. It makes it a lot easier to analyze them statically.

These use cases are probably better solved at the Loader level. If I understood the spec correctly, If you have modules that you want to load conditionally you can set up a normalize hook that changes which module is actually loaded.

System.normalize = function (name) {
  if (name === 'bar' && Math.random() > 0.5') {
    return 'baz'
  }
  return name;
};