21–30 of 76 posts
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.
I'd ban default exports if and only if JS had a Java-like import syntax declaration. import {x,y,z} from 'module' ^ this is an abomination
from 'module' import {x,y,z}
My problem with this article is the advice is far too broad "ban all default exports" without being considerate of how others code.
For example, I prefer to keep my modules small, with only one export. I may export helper or unwrapped versions of higher order components for easier testing, but generally I want my modules small and single purpose.
Default exports are helpful constructs. Disagree with this article overall.
I use TypeScript and VSCode and recognise the easier refactoring, but almost all external dependencies will use default exports, so you just end up with an inconsistent code base.
which makes me cry :D
I'll preface this by saying I'm not a huge fan of ES2015 modules. Everything ES2015 provides (syntactical sugar) could be achieved with CommonJS exports. If you don't want to export an object and only a single thing, you can enforce those restrictions via code reviews, linting tools, etc. rather than bloating the language spec. And the backwards compatibility is very poor with older CommonJS (the weird __default stuf…
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 a project for a short time? Wouldn't it be nice if the experience was good regardless?
The author makes a good suggestion for consideration. Anytime we find a principle which is likely to lead to an overall improvement at scale it's worth considering, especially when it comes without much if any a downside. I'm not necessarily agreeing that this is the case here, but just don't think your comments add much.
Semantic difference between default and named exports is that as a user of the module you are forced to choose a name for the default export, and these names will likely be different across different usages of the module. For linking units within one project, this is a bad thing, because you should be consistent in naming your things. But for modules that are published to the global NPM, maybe why not.
Both tools are useful; both are necessary; most modules should have a single default export.
I dislike when I use some external module and I have to look up whether the module is the value or not...
Edit: as an additional annoyance, when mixing CommonJS and ES6, the value may be in an element called "default". In some cases. I'm still unsure when.