Destructuring a Default Export Object

Destructuring a default export object

Can I destructure a default export object on import?

No. You can only destructure an object after importing it into a variable.

Notice that imports/exports have syntax and semantics that are completely different from those of object literals / object patterns. The only common thing is that both use curly braces, and their shorthand representations (with only identifier names and commas) are indistinguishable.

Is the following import syntax valid JS?

import { foo, bar } from './export-file';

Yes. It does import two named exports from the module. It's a shorthand notation for

import { foo as foo, bar as bar } from './export-file';

which means "declare a binding foo and let it reference the variable that was exported under the name foo from export-file, and declare a binding bar and let it reference the variable that was exported under the name bar from export-file".

Given the following export syntax (export default)

export default { foo, bar };

does the above import work with this?

No. What it does is to declare an invisible variable, initialise it with the object { foo: foo, bar: bar }, and export it under the name default.

When this module is imported as export-file, the name default will not be used and the names foo and bar will not be found which leads to a SyntaxError.

To fix this, you either need to import the default-exported object:

import { default as obj } from './export-file';
const {foo: foo, bar: bar} = obj;
// or abbreviated:
import obj from './export-file';
const {foo, bar} = obj;

Or you keep your import syntax and instead use named exports:

export { foo as foo, bar as bar };
// or abbreviated:
export { foo, bar };
// or right in the respective declarations:
export const foo = …;
export function bar() { ... }

How to export constants defined using object destructuring

Is it possible to export these constants by prefixing the statement by
export?

export const {
    NODE_ENV,
    API_URL,
} = process.env;

Yes, this is totally valid according to the spec. You can use destructuring patterns in the declarations of exported consts.

This would seem natural, but
eslint-plugin-import
complains about a violation of the
import/named
rule: API_URL not found in '../constants'.

Sounds like that plugin is broken. In fact, your exact use case was reported as working before.

Javascript export destructuring default keyword

the export is defining a default export, or app has an export called default

That's the same thing. No, it's not an object, and there's no destructuring here. It's short for

export { default as default } from 'app';

and does re-export the default export of app as the default export of the current module. In two lines, spelled out explicitly and introducing a local app binding, it would be

import { default as app } from 'app';
export { app as default }

where the second line is similar (but not identical!) to the more prevalent export default app.

How to export a part of destructuring assignment?

To export it as default:

// data.js
const { a, ...rest } = { a: 1, b: 2, c: 3 };
export default rest;

// main.js
import rest from "./data";
console.log(rest);  // { b: 2, c: 3 }

To export as a named export:

// data.js
const { a, ...rest } = { a: 1, b: 2, c: 3 };
export { rest };

// main.js
import { rest } from "./data";
console.log( rest ); // { b: 2, c: 3 }

JavaScript - import/export & destructuring

What about:

export { reducer as default } from './reducer';
export * from './selectors';
export * from './actions';

Maybe not 100% what you want, but it's still one less line of code.

---

But you actually could do the destructuring with CJS. Something like this should work:

exports = {
  default: require('./reducer').reducer,
  selectors: require('./selectors'),
  ...require('./actions')
};

Destructuring in named export?

Although the syntax looks very similar to destructuring, and the operation being performed is somewhat similar to destructuring (in that it takes the my_object binding from the namespace and puts it into an identifier), it's something quite distinct. For a couple of examples...

With destructuring, you can destructure nested properties of an object. This is impossible to do (in one statement) with imports.

With destructuring, you can put the property into a different variable with a colon. With imports, as must be used instead.

const { prop: propIdentifier } = obj;
import { theName as theNameIdentifier } from './somefile';

using curly braces is just a requirement for importing named object?

Exactly.

There are things you can do with destructuring that you can't do when importing, and there are things you can do when importing that you can't do with destructuring.

Export and export default a variable

export exports is not valid syntax, it looks similar to something that TypeScript did support but that is deprecated in favour of modern syntax. Do not use it.

export default exports; and import everything from 'my_module'; would work together, but it's not recommended to default-export objects since it doesn't work with named imports.

Instead, use named exports:

export {
    Something,
    SomethingElse
}

(or put the export right on the declarations of Something and SomethingElse), then you can choose to do either

import {Something} from 'my_module';

or

import * as everything from 'my_module';

---

Related Topics