1

I saw this answer about differences between es6 imports vs require.
But one of the answers there caught my eyes:

Thing is import() is actually async in nature.

Example : 

const module = await import('./module.js');

mdn says nothing about it.

I've been using imports for some time now but never knew that it can be awaited ??

I've also created an experiment (dummy angular test):

1.ts

export const a=3;

app.component.ts

import { Component } from '@angular/core'; //no await here

@Component({
 ...
})
export class AppComponent {


  constructor() {
    this.foo();
  }
  async foo() {
    const module =  await import('./1'); //<--- if I remove the await, it doesn't work
    alerqt(module.a)
  }
}

enter image description here

So it seems that import returns a promise ?

Question

What am I missing? I didn't have to await in the first two lines of where I imported Component: 

import { Component } from '@angular/core'; //no await

@Component({       
 ...
})

And where does it say that import returns a promise ?

Also , one of the webpack programmers : (or system.js) said :

If import was just an asynchronous function, then it would no longer be possible to statically analyze modules, as just like CommonJS require, I could have import within arbitrary conditions etc.

But from my testing it does require await , which makes it asynchronisly evaluated.

So what is going on here?

Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • 1
    Import has two sides: you can either use it in the beginning of a file (to import other components), or you can also use it in the code to load a javascript file dynamically (e.g. after the user changes the language of the application -> load the new language.json file). And this function is async, so you can resolve it using a promise. I don't really know where that's documented but already used that behaviour (for loading language files). – Larce Feb 05 '18 at 11:46
  • React loadable relies on import() async nature and it actually helps code splitting, as they well explain in the readme of the repo: https://github.com/thejameskyle/react-loadable – Mosè Raguzzini Feb 05 '18 at 11:47
  • @Larce Thank you. If i may ask - what is the boundry where it is considered "beginig of the file" vs "not begining of the file" ? do you mean in a function ? – Royi Namir Feb 05 '18 at 11:48
  • The way import works in module's, is different to how they work inside a function body. – Keith Feb 05 '18 at 11:48
  • 1
    It's a stage3 proposal https://github.com/tc39/proposal-dynamic-import – Thomas Feb 05 '18 at 11:51
  • Yeah exactly by "not the beginning of the file" I mean in any (function) body. – Larce Feb 05 '18 at 11:52
  • @Thomas Oh so it's a TS thing ? that's why it worked ? – Royi Namir Feb 05 '18 at 11:53
  • I knew that this is a future JS thing. But TS seems to already support it. – Thomas Feb 05 '18 at 12:01
  • It's not just a TS thing. Maybe you check [this](http://exploringjs.com/es6/ch_modules.html#sec_imports-as-views-on-exports) out, about how JS imports/modules (will) work. And then there's the mentioned proposal for the [dynamic imports](https://github.com/tc39/proposal-dynamic-import). Atm you can't use them in plain JS in production, but they are coming, and eventually TS will simply get rid of the polyfills. – Thomas Feb 05 '18 at 12:14

0 Answers0