I came across this distinction which wasn't explained well in ExploringJS
Qualified and unqualified imports work the same way (they are both indirections)
What is the distinction and therefore what does this statement mean?
Asked
Active
Viewed 1,651 times
7
Arijit Bhattacharya
- 1,265
- 12
- 12
-
4See [this answer](https://stackoverflow.com/questions/11274864/what-does-qualified-mean-in-import-qualified-data-list-statement), which explains the concept of qualified vs. unqualified imports in Haskell (this concept carries over to ES6). TL;DR, qualified imports require that you specify the name of the module containing a function when you call an imported function. – Jules Jan 22 '16 at 18:33
-
1I searched Stack Overflow with "unqualified javascript" because of exactly the same sentence in the same book which, as Arijit states, is not well explained. I appreciate the comment from @Jules that re-directs to another answer, but I don't want to have mentally parse Haskell or any other language to understand these concepts in JavaScript. Having read that other answer, I _think_ it has something to do with named vs default exports leading to qualified vs unqualified imports, but any clarification/correction/expansion would be helpful. – Andrew Willems May 24 '16 at 16:49
1 Answers
4
Strictly speaking, there's no such thing as qualified/unqualified imports in JavaScrpit. Those terms were used in the book 'Exploring ES6' by Dr. Axel Rauschmayer in the context of cyclic dependencies, and roughly mean:
Unqualified imports (directly import a part of a module):
CommonJS:
var foo = require('a').foo // doesn't work with cyclic dependencies
ES2015:
import {foo} from 'a' // can work with cyclic dependencies*
Qualified imports (import the whole module as a namespace):
CommonJS:
var a = require('a')
function bar() {
a.foo() // can work with cyclic dependencies*
}
exports.bar = bar
ES2015:
import * as a from 'a'
export function bar() {
a.foo() // can work with cyclic dependencies*
}
In ES2015 default imports can also be qualified imports (although some people disagree) if they serve as a namespace:
export default {
fn1,
fn2
}
with cyclic dependencies, you can't access imports in the body of a module:
import {foo} from 'a' // 'a' is a cyclic dependency
foo() // doesn't work
