import * in JavaScript without specifying namespace? [duplicate] - javascript

I know that we can import all named modules with alias as below,
import * as name from "module-name";
Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
Actually, I have re-exported my modules in A.js and the same is inherited in B.js. PFB. Now, it's two level of inheritance, so it's not a big deal to import the named modules. But, when I'm taking this to 5 level of inheritance (A -> B -> C -> D -> E), I need to import all named modules in all files and need to do the (re)export the same in all. Instead of doing this,
Is there any other way to copy scope of all named modules into all level without reiterating the wheel (Import and Export)
Behind the scene of this design is to make them to follow Opps concept and to avoid the redeclaration of the same modules.
A.js
import React from 'react';
import I18n from 'i18n-js';
import m1 from 'module1';
import m2 from 'module2';
export default class A extends React.Component {}
export {React, I18n, m1, m2)
B.js
import BaseComponent from './A';
import {React, I18n, m1, m2) from './A;
export default class B extends A {}
Is there any way to import all named modules without alias like import {*} from './A' (instead of 2nd in B.js)

JavaScript solution:
import * as exports from 'foo';
Object.entries(exports).forEach(([name, exported]) => window[name] = exported);
Note: the imported wrapper object remains there.
Node.js solution:
Object.entries(require('foo')).forEach(([name, exported]) => global[name] = exported);

Is there any way to import all named modules without alias like import {*} from './A' (instead of 2nd in B.js)
No.
And the whole idea of re-exporting more than you need to save the "number of lines" in the final js file as you stated at
Because, It's putting two lines for each import in the final js file. Consider If there are 10 import lines than, 20 lines will be added in final js. When you are thinking for production it will too cost
Does not make much sense, since that's what JS minifiers are for.
To summarise: one should not do that at the very first place:
You export only what you need to export
You import whatever you need wherever you need.
You use JS minifiers to optimise the output JS file size.

Here's a crazy experiment I did, that works, but it's probably dangerous in ways I don't fully understand.
Would somebody explain to me why we don't do this?
var lodash = require("lodash");
function $localizeAll(name) {
return `eval("var " + Object.getOwnPropertyNames(${name}).reduce((code, prop)=>{
if (/^[a-zA-Z$_][a-zA-Z$_0-9]*$/.test(prop)) {
return code.concat(\`\${prop} = ${name}["\${prop}"]\n\`);
} else {
console.warn("did not import '" + prop + "'");
return code;
}
}, []).join(", ")+";")`
}
// this will make all exports from lodash available
eval($localizeAll("lodash"));
console.log(add(indexOf([1,2,6,7,12], 6), 5)); // => 7
It's a bit complicated as it evals in two levels, but it basically iterates of all the properties of an object with the given name in scope and binds all properties that have names qualified to be identifiers to an identifier by that name:
var length = lodash["length"]
, name = lodash["name"]
, arguments = lodash["arguments"]
, caller = lodash["caller"]
, prototype = lodash["prototype"]
, templateSettings = lodash["templateSettings"]
, after = lodash["after"]
, ary = lodash["ary"]
, assign = lodash["assign"]
, assignIn = lodash["assignIn"]
, assignInWith = lodash["assignInWith"]
, assignWith = lodash["assignWith"]
, at = lodash["at"]
, before = lodash["before"]
, bind = lodash["bind"]
, bindAll = lodash["bindAll"]
, bindKey = lodash["bindKey"]
//...
, upperCase = lodash["upperCase"]
, upperFirst = lodash["upperFirst"]
, each = lodash["each"]
, eachRight = lodash["eachRight"]
, first = lodash["first"]
, VERSION = lodash["VERSION"]
, _ = lodash["_"]
;
There are some examples in this list of why this is a bad idea (e.g. it shadows arguments).
You should be able to use this as follows (though you probably shouldn't like they say above).
B.js
import BaseComponent, * as extras from './A';
eval($localizeAll("extras"));
export default class B extends BaseComponent {}
Anyways, couldn't resist trying this out ;)

global is your current scope in node.js, similar to the window object in the browser, so you can import into this object.
To import all symbols from util module:
import * as util from "./util";
util.importAll(util, global);
In util.js:
/**
* Takes all functions/objects from |sourceScope|
* and adds them to |targetScope|.
*/
function importAll(sourceScope, targetScope) {
for (let name in sourceScope) {
targetScope[name] = sourceScope[name];
}
}
... and a number of other functions like assert() etc., which I need everywhere, and which should be part of the JavaScript language, but are not yet. But as others said, use this sparingly.

For Now, there is no clean way to do this.
But you can overcome the problem by :
1) defining an alias
import * as foo from "foo"
2) writing all modules
import {a,b,c,d,...} from "foo"

Related

ESM export * except from module

Given I have two imports with lots of named exports (too many to write them all out) and I want to reexport these except a few of them. In my case this is because a few exports collide.
As an example of what I want to archive lets assume we have two files:
foo.js:
export const a = 1;
export const b = 2;
bar.js:
export const b = 1;
export const c = 3;
If I want to aggregate and reexport them all using CommonJS I could do something like this:
/* use rest destructuring to put everything except "b" into variable "foo" */
const { b, ...foo } = require("./foo");
const bar = require("./bar");
module.exports = {
...foo,
...bar
};
As I'm using typescript the closest I've gotten is using export = { ... } in a similar way:
import * as foo from "./foo";
import * as bar from "./bar";
const { b, ...foo2 } = foo;
export = {
...foo2,
...bar,
};
However it is my understanding this will create a file with CommonJS module.exports instead of a proper ESM module (and probably require esModuleInterop). And it is a typescript construct and not available when writing vanilla JS.
Is there a way to archive this using ESM import / export instead?
Is there a way to archive this using ESM import / export instead?
No, not in pure standard ESM, not without doing what you're trying to avoid: Listing the named exports. There's no "rest" concept in ESM import/export.
I think you know this, but you could export an object with properties for a, b, and c, but that's a very different thing from re-exporting named exports. It wouldn't be a live binding, and the syntax for importing its parts is different from importing named exports (unless build-time tools like TypeScript or bundlers, etc. are involved).
Just FWIW, here's what that looks like (it's very similar to your TypeScript version near the end), but I don't think it's what you want:
reexport.js:
import * as foo from "./foo.js";
import * as bar from "./bar.js";
const { b, ...restOfFoo } = foo;
export default {
...restOfFoo,
...bar,
};
Then using it is:
// Import the object (which is the default export)
import stuff from "./reexport.js";
// Destructure into local vars (optional, but...)
const { a, b, c } = stuff;
// Use it...
console.log(a, b, c);
That's all standard ESM.

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.

Using Import * from single export

I am not used to seeing a import * often
The react + readux code I am going through uses import *
According to firefox documentation about import *
This inserts myModule into the current scope, containing all the
exports from the module in the file located in /modules/my-module.js.
suppose we have an export statement like this in our code (call it articleTypes.js) .
export const ARTICLES_FETCHED = 'articles.ARTICLES_FETCHED';
Doing this, Would make actually probably make sense we didn't use export default above
import * as types from './actionTypes'
But If we alter the above lines like this
export default const ARTICLES_FETCHED = 'articles.ARTICLES_FETCHED';
and do something like this
import types from './actionTypes'
Will it work the same way as the above code? or will this actually work? and will this be a better approach?
But If we alter the above lines like this
export default const ARTICLES_FETCHED = 'articles.ARTICLES_FETCHED';
and do something like this
import types from './actionTypes'
Will it work the same way as the above code?
Will it work the same way as the above code?
No, types would be equal to 'articles.ARTICLES_FETCHED'
On the other hand, this module:
export default {ARTICLES_FETCHED: 'articles.ARTICLES_FETCHED'}
would act the same as this module:
export const ARTICLES_FETCHED = 'articles.ARTICLES_FETCHED'
The main benefit from using import * as myVar from 'module' is that you get all the exports from module wrapped up in a neat variable myVar.

What is the difference between " import {foo} form './foo' " and " import foo form './foo' " [duplicate]

It seems to be obvious, but I found myself a bit confused about when to use curly braces for importing a single module in ES6. For example, in the React-Native project I am working on, I have the following file and its content:
File initialState.js
var initialState = {
todo: {
todos: [
{id: 1, task: 'Finish Coding', completed: false},
{id: 2, task: 'Do Laundry', completed: false},
{id: 2, task: 'Shopping Groceries', completed: false},
]
}
};
export default initialState;
In the TodoReducer.js, I have to import it without curly braces:
import initialState from './todoInitialState';
If I enclose the initialState in curly braces, I get the following error for the following line of code:
Cannot read property todo of undefined
File TodoReducer.js:
export default function todos(state = initialState.todo, action) {
// ...
}
Similar errors also happen to my components with the curly braces. I was wondering when I should use curly braces for a single import, because obviously, when importing multiple component/modules, you have to enclose them in curly braces, which I know.
The Stack Overflow post at here does not answer my question, instead I am asking when I should or should not use curly braces for importing a single module, or I should never use curly braces for importing a single module in ES6 (this is apparently not the case, as I have seen single import with curly braces required).
This is a default import:
// B.js
import A from './A'
It only works if A has the default export:
// A.js
export default 42
In this case it doesn’t matter what name you assign to it when importing:
// B.js
import A from './A'
import MyA from './A'
import Something from './A'
Because it will always resolve to whatever is the default export of A.
This is a named import called A:
import { A } from './A'
It only works if A contains a named export called A:
export const A = 42
In this case the name matters because you’re importing a specific thing by its export name:
// B.js
import { A } from './A'
import { myA } from './A' // Doesn't work!
import { Something } from './A' // Doesn't work!
To make these work, you would add a corresponding named export to A:
// A.js
export const A = 42
export const myA = 43
export const Something = 44
A module can only have one default export, but as many named exports as you'd like (zero, one, two, or many). You can import them all together:
// B.js
import A, { myA, Something } from './A'
Here, we import the default export as A, and named exports called myA and Something, respectively.
// A.js
export default 42
export const myA = 43
export const Something = 44
We can also assign them all different names when importing:
// B.js
import X, { myA as myX, Something as XSomething } from './A'
The default exports tend to be used for whatever you normally expect to get from the module. The named exports tend to be used for utilities that might be handy, but aren’t always necessary. However it is up to you to choose how to export things: for example, a module might have no default export at all.
This is a great guide to ES modules, explaining the difference between default and named exports.
I would say there is also a starred notation for the import ES6 keyword worth mentioning.
If you try to console log Mix:
import * as Mix from "./A";
console.log(Mix);
You will get:
When should I use curly braces for ES6 import?
The brackets are golden when you need only specific components from the module, which makes smaller footprints for bundlers like webpack.
Dan Abramov's answer explains about the default exports and named exports.
Which to use?
Quoting David Herman:
ECMAScript 6 favors the single/default export style, and gives the sweetest syntax to importing the default. Importing named exports can and even should be slightly less concise.
However, in TypeScript named export is favored because of refactoring. Example, if you default export a class and rename it, the class name will change only in that file and not in the other references, with named exports class name will be renamed in all the references.
Named exports is also preferred for utilities.
Overall use whatever you prefer.
Additional
Default export is actually a named export with name default, so default export can be imported as:
import {default as Sample} from '../Sample.js';
If you think of import as just syntax sugar for Node.js modules, objects, and destructuring, I find it's pretty intuitive.
// bar.js
module = {};
module.exports = {
functionA: () => {},
functionB: ()=> {}
};
// Really all that is is this:
var module = {
exports: {
functionA, functionB
}
};
// Then, over in foo.js
// The whole exported object:
var fump = require('./bar.js'); //= { functionA, functionB }
// Or
import fump from './bar' // The same thing - object functionA and functionB properties
// Just one property of the object
var fump = require('./bar.js').functionA;
// Same as this, right?
var fump = { functionA, functionB }.functionA;
// And if we use ES6 destructuring:
var { functionA } = { functionA, functionB };
// We get same result
// So, in import syntax:
import { functionA } from './bar';
Summary ES6 modules:
Exports:
You have two types of exports:
Named exports
Default exports, a maximum one per module
Syntax:
// Module A
export const importantData_1 = 1;
export const importantData_2 = 2;
export default function foo () {}
Imports:
The type of export (i.e., named or default exports) affects how to import something:
For a named export we have to use curly braces and the exact name as the declaration (i.e. variable, function, or class) which was exported.
For a default export we can choose the name.
Syntax:
// Module B, imports from module A which is located in the same directory
import { importantData_1 , importantData_2 } from './A'; // For our named imports
// Syntax single named import:
// import { importantData_1 }
// For our default export (foo), the name choice is arbitrary
import ourFunction from './A';
Things of interest:
Use a comma-separated list within curly braces with the matching name of the export for named export.
Use a name of your choosing without curly braces for a default export.
Aliases:
Whenever you want to rename a named import this is possible via aliases. The syntax for this is the following:
import { importantData_1 as myData } from './A';
Now we have imported importantData_1, but the identifier is myData instead of importantData_1.
In order to understand the use of curly braces in import statements, first, you have to understand the concept of destructuring introduced in ES6
Object destructuring
var bodyBuilder = {
firstname: 'Kai',
lastname: 'Greene',
nickname: 'The Predator'
};
var {firstname, lastname} = bodyBuilder;
console.log(firstname, lastname); // Kai Greene
firstname = 'Morgan';
lastname = 'Aste';
console.log(firstname, lastname); // Morgan Aste
Array destructuring
var [firstGame] = ['Gran Turismo', 'Burnout', 'GTA'];
console.log(firstGame); // Gran Turismo
Using list matching
var [,secondGame] = ['Gran Turismo', 'Burnout', 'GTA'];
console.log(secondGame); // Burnout
Using the spread operator
var [firstGame, ...rest] = ['Gran Turismo', 'Burnout', 'GTA'];
console.log(firstGame);// Gran Turismo
console.log(rest);// ['Burnout', 'GTA'];
Now that we've got that out of our way, in ES6 you can export multiple modules. You can then make use of object destructuring like below.
Let's assume you have a module called module.js
export const printFirstname(firstname) => console.log(firstname);
export const printLastname(lastname) => console.log(lastname);
You would like to import the exported functions into index.js;
import {printFirstname, printLastname} from './module.js'
printFirstname('Taylor');
printLastname('Swift');
You can also use different variable names like so
import {printFirstname as pFname, printLastname as pLname} from './module.js'
pFname('Taylor');
pLanme('Swift');
Usually when you export a function you need to use the {}.
If you have
export const x
you use
import {x} from ''
If you use
export default const x
you need to use
import x from ''
Here you can change X to whatever variable you want.
The curly braces ({}) are used to import named bindings and the concept behind it is destructuring assignment
A simple demonstration of how import statement works with an example can be found in my own answer to a similar question at When do we use '{ }' in javascript imports?.
If there is any default export in the file, there isn't any need to use the curly braces in the import statement.
if there are more than one export in the file then we need to use curly braces in the import file so that which are necessary we can import.
You can find the complete difference when to use curly braces and default statement in the below YouTube video.
21. ES6 Modules. Different ways of using import/export, Default syntax in the code. ES6 | ES2015
The curly braces are used only for import when export is named. If the export is default then curly braces are not used for import.
For a default export we do not use { } when we import.
For example,
File player.js
export default vx;
File index.js
import vx from './player';
File index.js
File player.js
If we want to import everything that we export then we use *:

ES6 module syntax for multiple "static" functions

I'm coming from Java, and trying to turn the idea of a "utility class" into something that works in ES6.
In my file numbers.js, I can export a single function:
export default function padDigits(number, digits) {
return new Array(Math.max(digits - String(number).length + 1, 0)).join(0) + number;
}
Which can then be imported in another file like:
import padDigits from '../utils/numbers';
...
var paddedNum = padDigits(myNum, 2);
However: I would like for two things to be possible: I want to (1) export multiple functions from this single file, and (2) I would like for them to be accessible via a single import statement, and called via a namespace/classname prefix, like:
import Numbers from '../utils/numbers';
...
var paddedNum = Numbers.padDigits(myNum, 2);
var truncatedNum = Numbers.truncate(myNum, 3);
But I'm having a hard time finding the right syntax to accomplish this.
are you perhaps looking for the wildcard?
import * as nums from '../utils/numbers';
A similiar question: TypeScript 1.5: ES6 Module default import of CommonJS 'export =' (.d.ts only issue?)
A more detailed answer into this: New es6 syntax for importing commonjs / amd modules i.e. `import foo = require('foo')`

Categories