Undertanding import in ES6 - javascript

I came across this source code.
I do not understand the first line:
import type { a, b, c, d } from 'types'
What is the difference with
import { a, b, c, d } from 'types'
Could you please explain? Thanks
import type { a, b, c, d } from 'types'// not sure what it does
import { a, b, c, d } from 'types' // I am familar with this

This is not vanilla JavaScript import usage. This is probably Flow, or a closely-related transpiled language.
I found a blog post from the Flow project entitled Announcing Import Type. I don't know Flow, but it looks like a strictly-type superset of JavaScript. The import type statement is how you import type information about a class without importing the class itself. They give an example where you might want to declare stirctly-typed formal arguments in a function and need to import the appropriate types:
import type {Crayon, Marker} from 'WritingUtensils';
module.exports = function junkDrawer(x: Crayon, y: Marker): void {}

It is importing type definitions from the file.
// Here you are importing the actual method, variable from the file.
import xyz from 'abc';`
// Here you are importing the type defination of xyz
import type { xyz } from 'abc';
Now if you want to use it as
let a: xyz = new xyz();

From MDN, although the missing comas from OP is weird:
Importing defaults: It is possible to have a default export (whether it
is an object, a function, a class, etc.). The import statement may
then be used to import such defaults.
The simplest version directly imports the default:
import myDefault from '/modules/my-module.js';
It is also possible to
use the default syntax with the ones seen above (namespace imports or
named imports). In such cases, the default import will have to be
declared first. For instance:
import myDefault, {foo, bar} from '/modules/my-module.js'; // specific, named imports
In other words, this will import the default as myDefault, and then import the named exports.

Related

BuildRestClient import causes problems - Azure DevOps

Currently i'm trying to get the workitems of my azure devops server with following code:
export function geWorkitems(target: HTMLElement): void {
// Get an instance of the client
let client = WorkitemRestClient.getClient();
client.getWorkItems([1]).then(definitions => {
target.innerText = JSON.stringify(definitions)
}
);
}
show("workitems", geWorkitems);
when I include the needed import its gives me this error:
Import assignment cannot be used when targeting ECMAScript modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from "mod"', or another module format instead.ts(1202)
The import i am talking about:
import WorkitemRestClient = require("TFS/WorkItemTracking/RestClient");
People have been suggesting to write it this way, but it still doesnt work
import WorkitemRestClient from "TFS/WorkItemTracking/RestClient";
same with import BuildRestClient = require("TFS/Build/RestClient");
Best method
Have you tried the code suggested in the error message (import {a} from "mod"):
import { geWorkitems } from "TFS/WorkItemTracking/RestClient";
Make sure you have the correct spelling and capitalisation because the export name must be the same as the import
Alternative 1
You could also try:
const WorkitemRestClient = require("TFS/WorkItemTracking/RestClient");
using require is like normal assignments so you can't use the import keyword.
require is less used nowadays and works better with the module.exports = {} notation
Alternative 2
Finally, you could keep the second import you mentionne:
import WorkitemRestClient from "TFS/WorkItemTracking/RestClient";
but you need to export it differently with the default keyword:
export default function geWorkitems(target: HTMLElement): void {

export is not working when try to destructure in javascript import

I have two file:
file A.js:
export default={
name:"sample"
}
file B.svelte:
import {name} from './A';
Error:
name is not export from A.js
There are two problems there:
That's now how you make the default export an object, you should remove the =.
import is not destructuring, they just have a superficial resemblance to each other. You can't destructure during an import.
I would make the export a named export:
export let name = "sample";
...which would work with your import. Changes to name by the source module will show up in the imported binding for it (imports are live bindings to the original export).
But if you don't want to do that, here's how you export an object as the default export:
export default {
name: "sample",
};
and then you have to import and destructure separately:
import obj from "./A.js";
const { name } = obj;
Note: The above is how standard JavaScript modules work according to specification. Bundlers may go beyond the spec when bundling code (for instance, may allow named import syntax when in fact you're destructuring a default exported objects), but if so, it's non-standard.

How can I import javascript module without ReferenceError?

I made an export Javascript file like following:
export const A = 1;
export const B = 2;
export const C = 3;
And, I try to import that to another Javascript file like following:
import 'path/export_file.js'
console.log(A); // ReferenceError: A is not defined
I know I can fix it if I do the following:
import A from 'path/export_file.js'
// or
import { A, B, C } from 'path/export_file.js'
But I want to use like import 'path/export_file.js'
Some modules just do import'path/file' and I can use all of exported from that module.
What should I do?
Or am I mistaken for something?
There are 2 things to know:
You should know about Import/Export default & named in ES6
As #CertainPerformance's mention, you have to use {} unless the module assigns to global properties.
import { A, B, C } from 'path/export_file.js
In case of mix both Default and Named, you can use * like this
import * as Mix from 'path/export_file.js
Thanks #prosti's answer with a great answer.

Is there any advantage to default export compared to named export? [duplicate]

I have referred all the questions in stackoverflow.
But none of the suggested why and when to use default export.
I just saw that default can be metioned "When there is only one export in a file"
Any other reason for using default export in es6 modules?
Some differences that might make you choose one over the other:
Named Exports
Can export multiple values
MUST use the exported name when importing
Default Exports
Export a single value
Can use any name when importing
This article does a nice job of explaining when it would be a good idea to use one over the other.
It's somewhat a matter of opinion, but there are some objective aspects to it:
You can have only one default export in a module, whereas you can have as many named exports as you like.
If you provide a default export, the programmer using it has to come up with a name for it. This can lead to inconsistency in a codebase, where Mary does
import example from "./example";
...but Joe does
import ex from "./example";
In contrast, with a named export, the programmer doesn't have to think about what to call it unless there's a conflict with another identifier in their module.¹ It's just
import { example } from "./example";
With a named export, the person importing it has to specify the name of what they're importing. They get a nice early error if they try to import something that doesn't exist.
If you consistently only use named exports, programmers importing from modules in the project don't have to think about whether what they want is the default or a named export.
¹ If there is a conflict (for instance, you want example from two different modules), you can use as to rename:
import { example as widgetExample } from "./widget/example";
import { example as gadgetExample } from "./gadget/example";
You should almost always favour named exports, default exports have many downsides
Problems with default exports:
Difficult to refactor or ensure consistency since they can be named anything in the codebase other than what its actually called
Difficult to analyze by automated tools or provide code intellisense and autocompletion
They break tree shaking as instead of importing the single function you want to use you're forcing webpack to import the entire file with whatever other dead code it has leading to bigger bundle sizes
You can't export more than a single export per file
You lose faster/direct access to imports
checkout these articles for a more detailed explanation:
https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad
https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/
https://rajeshnaroth.medium.com/avoid-es6-default-exports-a24142978a7a
With named exports, one can have multiple named exports per file. Then import the specific exports they want surrounded in braces. The name of imported module has to be the same as the name of the exported module.
// imports
// ex. importing a single named export
import { MyComponent } from "./MyComponent";
// ex. importing multiple named exports
import { MyComponent, MyComponent2 } from "./MyComponent";
// ex. giving a named import a different name by using "as":
import { MyComponent2 as MyNewComponent } from "./MyComponent";
// exports from ./MyComponent.js file
export const MyComponent = () => {}
export const MyComponent2 = () => {}
You can also alias named imports, assign a new name to a named export as you import it, allowing you to resolve naming collisions, or give the export a more informative name.
import MyComponent as MainComponent from "./MyComponent";
You can also Import all the named exports onto an object:
import * as MainComponents from "./MyComponent";
// use MainComponents.MyComponent and MainComponents.MyComponent2 here
One can have only one default export per file. When we import we have to specify a name and import like:
// import
import MyDefaultComponent from "./MyDefaultExport";
// export
const MyComponent = () => {}
export default MyComponent;
The naming of import is completely independent in default export and we can use any name we like.
From MDN:
Named exports are useful to export several values. During the import, one will be able to use the same name to refer to the corresponding value.
Concerning the default export, there is only a single default export per module. A default export can be a function, a class, an object or anything else. This value is to be considered as the “main” exported value since it will be the simplest to import.
There aren't any definitive rules, but there are some conventions that people use to make it easier to structure or share code.
When there is only one export in the entire file, there is no reason to make it named.
Also, when your module has one main purpose, it could make sense to make that your default export. In those cases you can extra named exports
In react for example, React is the default export, since that is often the only part that you need. You don't always Component, so that's a named export that you can import when needed.
import React, {Component} from 'react';
In the other cases where one module has multiple equal (or mostly equal) exports, it's better to use named exports
import { blue, red, green } from 'colors';
1st Method:-
export foo; //so that this can be used in other file
import {foo} from 'abc'; //importing data/fun from module
2nd Method:-
export default foo; //used in one file
import foo from 'blah'; //importing data/fun from module
3rd Method:-
export = foo;
import * as foo from 'blah';
The above methods roughly compile to the following syntax below:-
//all export methods
exports.foo = foo; //1st method
exports['default'] = foo; //2nd method
module.exports = foo; //3rd method
//all import methods
var foo = require('abc').foo; //1st method
var foo = require('abc')['default']; //2nd method
var foo = require('abc'); //3rd method
For more information, visit to Default keyword explaination
Note:- There can be only one export default in one file.
So whenever we are exporting only 1 function, then it's better to use default keyword while exporting
EASIEST DEFINITION TO CLEAR CONFUSIONS
Let us understand the export methods, first, so that we can analyze ourselves when to use what, or why do we do what we do.
Named exports: One or more exports per module. When there are more than one exports in a module, each named export must be restructured while importing. Since there could be either export in the same module and the compiler will not know which one is required unless we mention it.
//Named export , exporting:
export const xyz = () =>{
}
// while importing this
import {xyx} from 'path'
or
const {xyz} = require(path)
The braces are just restructuring the export object.
On the other hand , default exports are only one export per module , so they are pretty plain.
//exporting default
const xyz =() >{
};
export default xyz
//Importing
import xyz from 'path'
or
const xyz = require(path)
I hope this was pretty simple to understand, and by now you can understand why you import React modules within braces...
Named Export: (export)
With named exports, one can have multiple named exports per file. Then import the specific exports they want surrounded in braces. The name of imported module has to be the same as the name of the exported module.
// imports
// ex. importing a single named export
import { MyComponent } from "./MyComponent";
// ex. importing multiple named exports
import { MyComponent, MyComponent2 } from "./MyComponent";
// ex. giving a named import a different name by using "as":
import { MyComponent2 as MyNewComponent } from "./MyComponent";
// exports from ./MyComponent.js file
export const MyComponent = () => {}
export const MyComponent2 = () => {}
Import all the named exports onto an object:
// use MainComponents.MyComponent and MainComponents.MyComponent2 here
import * as MainComponents from "./MyComponent";
Default Export: (export default)
One can have only one default export per file. When we import we have to specify a name and import like:
// import
import MyDefaultComponent from "./MyDefaultExport";
// export
const MyComponent = () => {}
export default MyComponent;
Note: The naming of import is completely independent in default export and we can use any name we like.
Here's a great answer that explains default and named imports in ES6

What are the advantage or disadvantages difference import styles such as module import and * as import

I was wondering and kinda confused as to which style of import should i use, till this moment i came across these imports and i'm not sure which on is faster, or if its worth refactoring my codes to use one of these instead of another one
Type1 :, (very simple, no problem here):
//This is simple and straight forward
import Component from 'Component';
Type2 (This is one of the ones i have some doubt about):
//#definition JavascriptUtils :
export function a {}
export function b {}
///,2000 more lines
Now this can be used in two ways:
//#usage JavascriptUtils :
//1-
import * as JavascriptUtils from 'Utils/JavascriptUtils'
//2-
import {a, b} as JavascriptUtils from 'Utils/JavascriptUtils'
Now i'm not sure if there is a difference between 1 or 2 or if there is, should i even care ?, is there that much difference in performance or package size, i do use this utility a lot, so i'd like to know how much advantage way 1 can give me
Type3:
//#definition UIUtils :
export const UIUtils = {
a,
b,
}
export function a {}
export function b {}
//#usage UIUtils
import {UIUtils} from 'Utils/UIUtils'
Type4:
//#definition UIUtils :
export const UIUtils = {
a,
b,
}
export function a {}
export function b {}
//#definition JSUtils :
export const JSUtils = {
c,
d,
}
export function c {}
export function d {}
//inside utils/index.js
export * from './UIUtils';
export * from './JSUtils';
//#usage UIUtils
import {UIUtils} from 'utils'
import {JSUtils} from 'utils'
So this all the different types of import i used until now, i really like to know which one is the best, which one is faster, which one causes less build size ? or if there is not difference or the difference is small, i'd like to know that as well.
I specially like to know if i'll notice any big difference in build size if i use {a} from import vs * as utils import, my utils are more than 2000 line and are used hundred of times throughout the program
Thanks!

Categories