4 ms·

while i agree that everything mentioned in the article is useful, i think ES6's import is horrible. why do i have to look at (potentially outdated, esp. in js w

while i agree that everything mentioned in the article is useful, i think ES6's import is horrible. why do i have to look at (potentially outdated, esp. in js world) documentation or look at the code to know whether or not to do import Foo from 'bar'; or import { Foo } from 'bar';

lewisl9029 11y ago
I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.
- arrakeen 11y ago
  and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use
  - lewisl9029 11y ago
    For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports. In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.
nostrademons 11y ago
I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar. Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.

lewisl9029 11y ago

I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.

arrakeen 11y ago
and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use
- lewisl9029 11y ago
  For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports. In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.

nostrademons 11y ago

I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar. Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.