I would like to import a default exported store with an alias using the syntax import XXX as A from YYY.
I know it works with this set up:
class XXX extends Reflux.Store{...}
export XXX;
//In another class you import:
import {XXX as ABC} from YYY;
That works great, but using that syntax with export default no longer works.
export default class XXX extends Reflux.Store{...}
//In another class you import:
import {XXX as ABC} from YYY;
But I know that if you export default you can't use {} syntax. Problem is that to use import as you need {}.
Any ideas?
All you need to do is import it with the name you want to use it with. There is no need to use the same name that was given to the module exported by default, you can use any name to import it
import ABC from 'YYY'; // syntax for default import
which is the short for
import { default as ABC } from 'YYY'
Related
There are multiple way to import modules. What is the difference between import {House} and import House?
There are two way to import in ES6 module, based on the export option.
Named Import
//filename - simple.js
export function Simple() {}
import {Simple} from "./simple.js"
Default Import
//filename - simple.js
export default Class Simple {}
import Simple from "./simple.js"
For more, refer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
UPDATE
You can also export both from a single file and import them. Important caveat here is there can be only one default export in a module.
//filename - simple.js
export function Simple1() {}
export default function Simple2() { }
import Simple2, { Simple1 } from "./simple.js"
The syntax import {House} is used to import specific, named imports like import {foo, bar} from '/modules/my-module.js';
while the syntax import House is used to import default exports like import myDefault from '/modules/my-module.js';
As one can see that we can mix these two. For example, this is also a valid import
import myDefault, {foo, bar} from '/modules/my-module.js';
to read more checkout Mozilla developer guide.
What is the difference in TypeScript between export and default export?
In all the tutorials, I see people exporting their classes and I cannot compile my code if I don't add the default keyword before exporting.
Also, I couldn't find any trace of the default export keyword in the official TypeScript documentation.
export class MyClass {
collection = [1,2,3];
}
Does not compile. But:
export default class MyClass {
collection = [1,2,3];
}
Does.
The error is:
error TS1192: Module '"src/app/MyClass"' has no default export.
Default Export (export default)
// MyClass.ts -- using default export
export default class MyClass { /* ... */ }
The main difference is that you can only have one default export per file and you import it like so:
import MyClass from "./MyClass";
You can give it any name you like. For example this works fine:
import MyClassAlias from "./MyClass";
Named Export (export)
// MyClass.ts -- using named exports
export class MyClass { /* ... */ }
export class MyOtherClass { /* ... */ }
When you use a named export, you can have multiple exports per file and you need to import the exports surrounded in braces:
import { MyClass } from "./MyClass";
Note: Adding the braces will fix the error you're describing in your question and the name specified in the braces needs to match the name of the export.
Or say your file exported multiple classes, then you could import both like so:
import { MyClass, MyOtherClass } from "./MyClass";
// use MyClass and MyOtherClass
Or you could give either of them a different name in this file:
import { MyClass, MyOtherClass as MyOtherClassAlias } from "./MyClass";
// use MyClass and MyOtherClassAlias
Or you could import everything that's exported by using * as:
import * as MyClasses from "./MyClass";
// use MyClasses.MyClass and MyClasses.MyOtherClass here
Which to use?
In ES6, default exports are concise because their use case is more common; however, when I am working on code internal to a project in TypeScript, I prefer to use named exports instead of default exports almost all the time because it works very well with code refactoring. For example, if you default export a class and rename that class, it will only rename the class in that file and not any of the other references in other files. With named exports it will rename the class and all the references to that class in all the other files.
It also plays very nicely with barrel files (files that use namespace exports—export *—to export other files). An example of this is shown in the "example" section of this answer.
Note that my opinion on using named exports even when there is only one export is contrary to the TypeScript Handbook—see the "Red Flags" section. I believe this recommendation only applies when you are creating an API for other people to use and the code is not internal to your project. When I'm designing an API for people to use, I'll use a default export so people can do import myLibraryDefaultExport from "my-library-name";. If you disagree with me about doing this, I would love to hear your reasoning.
That said, find what you prefer! You could use one, the other, or both at the same time.
Additional Points
A default export is actually a named export with the name default, so if the file has a default export then you can also import by doing:
import { default as MyClass } from "./MyClass";
And take note these other ways to import exist:
import MyDefaultExportedClass, { Class1, Class2 } from "./SomeFile";
import MyDefaultExportedClass, * as Classes from "./SomeFile";
import "./SomeFile"; // runs SomeFile.js without importing any exports
I was trying to solve the same problem, but found an interesting advice by Basarat Ali Syed, of TypeScript Deep Dive fame, that we should avoid the generic export default declaration for a class, and instead append the export tag to the class declaration. The imported class should be instead listed in the import command of the module.
That is: instead of
class Foo {
// ...
}
export default Foo;
and the simple import Foo from './foo'; in the module that will import, one should use
export class Foo {
// ...
}
and import {Foo} from './foo' in the importer.
The reason for that is difficulties in the refactoring of classes, and the added work for exportation. The original post by Basarat is in Avoid Export Default
Named export
In TypeScript you can export with the export keyword. It then can be imported via import {name} from "./mydir";. This is called a named export. A file can export multiple named exports. Also the names of the imports have to match the exports. For example:
// foo.js file
export class foo{}
export class bar{}
// main.js file in same dir
import {foo, bar} from "./foo";
The following alternative syntax is also valid:
// foo.js file
function foo() {};
function bar() {};
export {foo, bar};
// main.js file in same directory
import {foo, bar} from './foo'
Default export
We can also use a default export. There can only be one default export per file. When importing a default export we omit the square brackets in the import statement. We can also choose our own name for our import.
// foo.js file
export default class foo{}
// main.js file in same directory
import abc from "./foo";
It's just JavaScript
Modules and their associated keyword like import, export, and export default are JavaScript constructs, not TypeScript. However, TypeScript added the exporting and importing of interfaces and type aliases to it.
Here's an example with simple object exporting.
var MyScreen = {
/* ... */
width : function (percent){
return window.innerWidth / 100 * percent
}
height : function (percent){
return window.innerHeight / 100 * percent
}
};
export default MyScreen
In the main file (use it when you don't want and don't need to create a new instance) and it is not global, you will import this only when it is needed:
import MyScreen from "./module/screen";
console.log(MyScreen.width(100));
What is the reason for:
import something1 from './something1'
import something2 from './something2'
export default {
something1,
something2
}
export {
something1,
something2
}
?
And why isn't possible to do:
export default something
export something
Thank you.
For the case where you want individual module elements and a library namespace. If this were the old days:
import { extend } from "jquery";
import $ from "jquery";
One of these is importing a named export, and one of these is importing the default. Either is valid. But in general, the common practice is individual exports.
Because an export statement is either expecting you to declare the thing inline
export const something = ...
Which means that it can't be reassigned as default as well...
Or it's expecting you to export a batch of named values.
export default something;
export { something };
After create some components and export it in the logs show:
Invariant Violation: Element type is invalid: expected a string (for
built-in components) or a class/function (for composite components)
but got: object.
Some answers that i read about this topic complicated more about import and export on react-native.
so, doubt is:
if the component is not dynamic export with curly brackets?
and if dynamic export without curly brackets and with default?
here is the answer
Exporting without default means it's a "named export". You can have multiple named exports in a single file. So if you do this,
export class Template {}
export class AnotherTemplate {}
then you have to import these exports using their exact names. So to use these components in another file you'd have to do,
import {Template, AnotherTemplate} from './components/templates'
Alternatively if you export as the default export like this,
export default class Template {}
Then in another file you import the default export without using the {}, like this,
import Template from './components/templates'
There can only be one default export per file. In React it's a convention to export one component from a file, and to export it is as the default export.
You're free to rename the default export as you import it,
import TheTemplate from './components/templates'
And you can import default and named exports at the same time,
import Template,{AnotherTemplate} from './components/templates'
You should use the curly braces for import a module only if the module is just exported, and if the module is exported as default exported module, you should import it without curly braces.
Exported module example 1:
...
export SomeModule;
then you should import it as below:
import { SomeModule } from 'someWhere'
...
Exported module example 2:
...
export default SomeModule;
then you should import it as below:
import SomeModule from 'someWhere'
...
What is the difference between these two statements
import React from 'react';
and
import React, { Component } from 'react';
Shouldn't import React from 'react' import everything including the content? What should I read to understand this?
You can read about this here.
Importing something without curly braces imports whatever was defined as the default export in the module from which you are importing. There can only be exactly one (or no) default export in a module.
foo.js:
const myObject = {foo: 'bar'};
export default myObject;
bar.js:
import theObject from './foo';
console.log(theObject);
// prints {foo: 'bar'}
// note that default exports are not named and can be imported with another name
Importing with curly braces imports what was exported as a named export with that name by the module. There can be multiple named exports in a module.
foo.js:
export const myObject = {foo: 'bar'};
export const anotherObject = {bar: 'baz'};
bar.js:
import {myObject, anotherObject, theObject} from './foo';
console.log(myObject);
// prints {foo: 'bar'}
console.log(anotherObject);
// prints {bar: 'baz'}
console.log(theObject);
// prints undefined
// because nothing named "theObject" was exported from foo.js
With
import React, { Component } from 'react';
you can do
class Menu extends Component { /* ... */ }
instead of
class Menu extends React.Component { /* ... */ }
from this: Import React vs React, { Component }
This is the ES6.
import Raect, { Component } from 'react';
Like
import default_export, { named_export } from 'react';
Consider two file. Person.js like
const person = {
name: 'johon doe'
}
export default person; // default export
Utility.js like
export const clean = () => { ... } //named export using const keyword
export const baseData = 10; //named export using const keyword
inport in App.js file. like
import person from './Person';
import prs from './Person';
import {clean} from './Utility';
import {baseData} from './Utility';
import {data as baseData} from './Utility';
import {* as bundled} from './Utility';
//bundled.baseData
//bundled.clean
João Belo posted a great answer to read, but I'll add one more thing. the second instance is using destructuring and object-shorthand to grab the 'Component' property's value from the react module and assign it to a 'Component' variable that you can use locally. If you don't know about destructuring and object-shorthand, you should definitely look them up. They come in handy.
Primarily, this boils down to the way you export variables. I believe, this must be a deliberate design decision from Facebook contributors.
export default class ReactExample {}
export class ComponentExample {}
export class ComponentExampleTwo {}
in the above example, ReactExample can be imported without using {}, where as the ComponentExample, ComponentExampleTwo , you have to import using {} statements.
The best way to understand is going through the source code.
React export source code
React Component source code
import * as myCode from './../../myCode';
This inserts myCode into the current scope, containing all the exports from the module in the file located in ./../../myCode.
import React, { Component } from 'react';
class myComponent extends Component { ... }
By Using above syntax your bundler ( e.g : webpack) will still bundle the ENTIRE dependency but since the Component module is imported in such a way using { } into the namespace, we can just reference it with Componentinstead of React.Component.
For more information you can read mozilla ES6 module docs.