61–70 of 76 posts
As someone who only occasionally uses JavaScript, module imports are really confusing. Often, I want to do import * as mymodule from './mymodule' Namely, treat the whole module as one thing, and give it a name. It would be great if you could do that without specifying the name manually, e.g. like "import mymodule" in Python. The other times, I do: import SingleClass from './singleclass' # or import {SingleClass} from…
import function from 'function';
import * as module from 'module';
Wildcards preserve context. `ReactDOM.render` means more than `render`. Using wildcards avoids collisions - lodash, http, https each have a named export `get` [0]. Wildcards still supports tree shaking! Try it in webpack or rollup - only the named exports that you access will be included in the shooken bundle [1].
[0]: Yeah, I know you can import { get as httpsGet }, but why would I want to?
[1]: Unless you treat the binding as an object. `Object.keys(module)` will break tree-shaking.
Sometimes you don't care what the importing module names your thing, and it's the only thing your module does. Think of a super simple React component... I'm `export default function(props) { ... }`ing that every time. Is that bad?
AFAIK it's bad practise to export components like that, as they won't have a displayable name in devtools etc.
export default function MyComponent(props) { };Earlier quoted context omitted.
Your comments don't scale well. Projects have dependencies from teams with various skill levels and external dependencies over most of which you have little or no control. For this and many others reasons "refactoring to simplify" often isn't an option. Similarly, tree shaking doesn't just apply to the code from your project. Also, what about the time when you first start on a project? Or maybe you're only working on…
If the source of the problems are external dependencies, which, as you stated, you lack control, how would you go about banning default exports in those libraries? The correct and pragmatic course of action to address problems in code quality is to address them by refactoring, one file at a time. If you want to see the effects of explicit imports, go ahead and look at any large java code base. What ends up happening…
Also your point about tree-shaking is incorrect as it endeavors to apply to dependencies as well.
Finally, even without default exports one can still import the entire package with import *, so I don't see how it would lead to the same "problem" of a huge import declaration in Java.
In any case I _do_ agree that the authors suggestion should not be taken as a substitute for refactoring, but discussing this as a possible best practice is NOT mutually exclusive to this belief.
A default export is what a module is ; a named export is what a module has . Both tools are useful; both are necessary; most modules should have a single default export.
> Both tools are useful; both are necessary Maybe a nitpick, but given that most other programming languages don't distinguish named vs default, it's probably not necessary. You can do all your programming where every module is something (like in Java) or where every module only has things (like in Python), but there's certainly value in being able to express one or the other in the same language. The downside is tha…
Not sure that how other languages do things really plays a part in how JS does things?
I think his point is that having them available is necessary, because they both have strong use cases.
As someone who only occasionally uses JavaScript, module imports are really confusing. Often, I want to do import * as mymodule from './mymodule' Namely, treat the whole module as one thing, and give it a name. It would be great if you could do that without specifying the name manually, e.g. like "import mymodule" in Python. The other times, I do: import SingleClass from './singleclass' # or import {SingleClass} from…
There is no reason to import what you don't need. This is why wildcard imports are generally frowned upon in most development teams. (I say most, thats unqualified, of course, but from my experience, its always been a part of the code standards)
Your code is much more readable and clear when you are explicit about what you are importing.
Two of the three reasons listed involve refactoring and autocomplete quirks of Visual Studio Code, specifically. For instance, Webstorm has no such issues with default exports. It is smart enough to find all uses of a module and to track them down. The third reason is not all that common in my experience. Tree shaking is an optimization and often a premature one. It's also a technique primarily used for third party l…
In webstorm/intellij say you have a react component, one export per module as you say. The import statements are a tie imo to write by hand: import MyThing from "../../components/editors/MyThing"; import {MyThing} from "../../components/editors/MyThing"; But if it's named, you don't need to stop what you're doing, scroll to the top of the file, type out the import statement by hand, and look over at your code tree an…
As someone who only occasionally uses JavaScript, module imports are really confusing. Often, I want to do import * as mymodule from './mymodule' Namely, treat the whole module as one thing, and give it a name. It would be great if you could do that without specifying the name manually, e.g. like "import mymodule" in Python. The other times, I do: import SingleClass from './singleclass' # or import {SingleClass} from…
There is a reason for that, though. There is no reason to import what you don't need. This is why wildcard imports are generally frowned upon in most development teams. (I say most, thats unqualified, of course, but from my experience, its always been a part of the code standards) Your code is much more readable and clear when you are explicit about what you are importing.
Two of the three reasons listed involve refactoring and autocomplete quirks of Visual Studio Code, specifically. For instance, Webstorm has no such issues with default exports. It is smart enough to find all uses of a module and to track them down. The third reason is not all that common in my experience. Tree shaking is an optimization and often a premature one. It's also a technique primarily used for third party l…
In webstorm/intellij say you have a react component, one export per module as you say. The import statements are a tie imo to write by hand: import MyThing from "../../components/editors/MyThing"; import {MyThing} from "../../components/editors/MyThing"; But if it's named, you don't need to stop what you're doing, scroll to the top of the file, type out the import statement by hand, and look over at your code tree an…
Sometimes you don't care what the importing module names your thing, and it's the only thing your module does. Think of a super simple React component... I'm `export default function(props) { ... }`ing that every time. Is that bad?
export default class C extends React.Component { ... }