Why would I want to combine named exports with default exports?


Why would I want to combine named exports with default exports?


We combine named exports and default exports when we want to give a module the ability to define the default export of the module and other, potentially useful, pieces of a module (the named exports).

For example, these other pieces may be the internals of a private variable where we have access to part of a private variable, but not the entire private variable.


const uppercaseName = function (name) {
  return name.toUpperCase();

const myDefaultExport = {

class Animal {
    this._name = name;
  get name () {
    return uppercaseName(this._name);

export default myDefaultExport; //default export is the `myDefaultExport` object
export {Animal}; //named export `Animal` class, not exporting the `uppercaseName` function


import myDefaultExport from './moduleToExport.js'; //importing default module `myDefaultExport`
import {Animal} from './moduleToExport.js'; //importing a named module, `Animal`

const animal = new Animal('test');
console.log(animal.name); //logs `TEST` to the console, uses the private `uppercaseName` function even though we don't have access to `uppercaseName` through our imported `Animal` module and cannot call it explicitly

I am using this one in my own projects on classes.
export default MyClass;
import MyClass from './moduleToExport.js';

I am wondering. Is there realy a diffrence between these 2 ways of exporting/importing ?

export {MyClass};
import {MyClass} from './moduleToExport.js';
export default MyClass;
import MyClass from './moduleToExport.js';
seem completely the same in my experiences.


I did not understand the default exports.If someone can help me here.

1 Like

The way I understand it, the default export is to send only one statement. Also from the documentation, the default export can be imported with ANY name.
“There are two different types of export, named and default. You can have multiple named exports per module but only one default export[…]Named exports are useful to export several values. During the import, it is mandatory to use the same name of the corresponding object.But a default export can be imported with any name”


I got confused after reading that. In THIS post you said that we would not have access to variables that were not imported.

What is the difference between these situations?


If I understand it correctly, there is no difference between the cases. Note the distinction between ‘we have access’, and 'the object has access.

In the case addressed in this thread, we don’t have access to anything that wasn’t imported, namely - uppercaseName. However, we do have access to the Animal class, which in turn does have access and uses the uppercaseName. If you’d try calling uppercaseName in main.js you’d get an error, same as is explained in the other case you’ve referred to.

In a practical way, I believe that means whatever object you want to directly call in your file, must be imported, but you don’t need to worry about importing each method, function or variable that object uses (assuming, of course, they are properly defined within the same scope).


Thanks! That was helpful!

Yeh - I second that thanks! I was confused like @edgarmolas about this same thing. But your explanation has made things much clearer.

I’m still confused about why we would want to use export default myObject at all, instead of just adding it along with our other named exports e.g.
export { variable1, variable2, myObject }
I can’t see any real benefit of the default export, other than being able to import it using a different name, as @jellotimez explains in his post above:

However, we can still change the names of named exports/imports by using aliases with as:thinking:

Also, doesn’t the restriction of only sending one object with the default export become irrelevant if we just export everything as separate named exports?

I think this is also similar to what @biirra was getting at in her post above:

Can anyone shed any light on this?
@aubsrey? @mtf?


Well, it’s nice to have multiple options and a complete overview about exporting / importing but I don’t see any benefit by combining different exports methods. At least in terms of ease.

Ok then I guess this means aubsrey wasn’t really on point with her example. It didn’t answer the question right. So the fact still remains that there’s really no moving reason to use default export with named exports other than for geeking out? Whichever option (default, or named) that the object was imported, it will still have the same access to the function only found in the other file. The same is true with other functions, primitive data types (even they’re objects too).

1 Like