In ES6 importing goes for example:
import MyClass from "module";
The problem is intellisense doesnt pick up like in python. In python it would be for example:
from mo and here intellisense would already start working and would offer to complete module
from module import M and here would already offer all the classes starting with M.
Instead of import Class from module is there a way to do
from module import Class in ES6?
It is dependent upon the IDE. I have found in VS Code that the method Bergi said works quite well, starting with import {} from Module and going from there. Again, this is dependent upon the IDE. When a module only exports one thing, you are responsible for the naming of that variable.
Happy Coding!
Related
I've noticed that React can be imported like this:
import * as React from 'react';
...or like this:
import React from 'react';
The first imports everything in the react module (see: Import an entire module's contents)
The second imports only the default module export (see: Importing defaults)
It seems like the two approaches are different and fundamentally incompatible.
Why do they both work?
Please reference the source code and explain the mechanism...I'm interested in understanding how this works.
Update
This is not a duplicate of What is the difference between import * as react from 'react' vs import react from 'react'
That question was answered with general ES6 module information.
I am asking about the mechanism that makes the react module work like this. It seems to be related to "hacky" export mechanism in the source here but it's not clear how that enables both importing the entire module and just the default export into React and having both of those approaches work with transpiling JSX, etc.
TL;DR
Indeed ES import statements import default and import * are not the same thing, the fact that they behave the same in this case is a combination of how React authors chose to publish the library and compatibility layers in TypeScript (using esModuleInterop) or Babel and your bundler to make them "just work". It probably shouldn't work according to ES6 spec, but today we are still working in an era where JS modules are a mess, so tools like Babel, TypeScript, Webpack, etc try to normalize behavior.
More details:
React is not an ES6 library. If you look at the source code you see this in index.js:
const React = require('./src/React');
// TODO: decide on the top-level export form.
// This is hacky but makes it work with both Rollup and Jest.
module.exports = React.default || React;
(Note the comment, even in React source code they struggle with ES6 default export compatibility.)
The module.exports = syntax is CommonJS (NodeJS). A browser would not understand this. This is why we use bundlers like Webpack, Rollup, or Parcel. They understand all kinds of module syntax and produce bundles that should work in the browser.
But even though React is not an ES library, both TypeScript and Babel let you import it as if it is (using import syntax, rather than require(), etc), but there are differences between CJS and ES that have to be resolved. One of them is the fact that export = can give you things that ES has no spec-compliant way to import, like a function or a class as the module. To work around these incompatibilities Babel has for awhile allowed you to import CJS modules as if they were exporting something by default, or import as a namespace. TypeScript for awhile didn't do this, but more recently added that as an option under esModuleInterop. So now both Babel and TypeScript can pretty consistently allow a CJS module to be imported using default or namespace ES imports.
With TypeScript it also depends on how the type-definitions for the library are actually defined. I won't get into that, but you can imagine situations where thanks to transpilers and bundlers a particular import works at runtime, but TypeScript doesn't compile without errors.
Another thing worth mentioning is that if you look at the built code for React there is a UMD module version as well as the CJS version. The UMD version includes some gnarly runtime code to try to make it work in any module environment, including the browser. It's mainly for use if you want to just include React at runtime (ie you don't use a bundler). Example.
Confusing? Yeah, I think so. :)
You most likely have "allowSyntheticDefaultImports": true, set in your tsconfig.json, which essentially shuts the compiler up about default imports it thinks are invalid. Typescript added esModuleInterop which does essentially what babel does for module loading.
This allows you to use ES6 default imports even when the source code you're importing doesn't export anything as default
Typescript is strict (follows the rules) when it comes to this, which is why they require you to import * as React from 'react'. Or requires you to tell it to allow synthetic default imports in its base config.
More On That Here
I've used multiple 3rd party libraries in my ReactJS project like lodash, d3 etc. I just found out that I've not written explicit imports
like
import d3 from 'd3'
or import _ from 'lodash'
in all my components (I've imported them in some though). Yet it all works fine and I can also get the d3 object and _ in the browser console. How is it supposed to be?
Considering this is okay behavior can I just import the node_modules dependencies for react only once in my App(Root) Component and don't import them at all in all the other child components.
P.S I'm using webpack 1 and I've verified the behavior.
Even when it works, it is a bad practice, so my advice would be to play nice and always explicitly import modules you are using.
The reason why it is working is probably because some of those modules declare globals when they are imported, so your components that do not import them still reach global.
I was using both require and import but got some different behaviors from both. Until now I was assuming that require and import are just ES5 vs ES6. I was doing the below:
abc.js
console.log("abc");
xyz.js
console.log("xyz");
hello.js
require("./abc");
import "./xyz";
and the second time when I changed the file and swapped the two lines.
hello.js
import "./xyz";
require("./abc");
Both the times it was giving the same output
xyz
abc
ie. output of require was always after the import. If I use only import, or only import, it was giving consoles as expected ie. one after the other.
Can anyone help in understanding this?
Modules declared in hello.js via import are imported before any code in hello.js is run. It doesn't matter if the import statement appears after another statement. The module is still loaded before the code is run. So that is why you are getting "xyz" first no matter where you put the import statement.
require() on the other hand is programmatic. The module code is run when the require() statement is encountered while your program is running.
Since ES6 modules yet to be implemented(not sure) in node.js, I'm assuming you're using babel for transpiling export, import statements.
When babel transpiling the code it always place the import statements at the top of the module, therefore this happens. You can test it in REPL.
DEMO
More in depth details on import and require
I really don't know how to do this and not sure how to google either.
Right now I have this
let source = require('vinyl-source-stream');
I would like to change to be import but this doesn't work
import {'vinyl-source-stream' as source} from 'vinyl-source-stream';
If that module even supports the ES6 import/export system, then what you want is this:
import source from 'vinyl-source-stream';
Your version is attempting to import an exported value named vinyl-source-stream from the module; instead, you just want the module itself to be imported (into an object named source in this case).
If you want everything in the module imported, instead of just the default exports, use this instead:
import * as source from 'vinyl-source-stream';
But neither of those will work if the module isn't actually written to use the new system.
This library doesn't use the ES2015 module system. It doesn't export at all, so you can't import it or from it.
This library uses the CommonJS module pattern (as can be seen in the source) and is meant to be requireed.
You could import the library with:
import form 'vinyl-source-stream';
which will cause the code to be executed, but that will be useless in this case since nothing (useful) will happen - in fact, you'll probably get a runtime exception due to undefined module.
I'm doing this in TypeScript, but tried it in vanilla JS as well with the same error. I've pulled down two modules: express and hbs. I'm trying to use the ES6 import syntax like this:
import * as http from 'http';
import * as express from 'express';
import hbs from 'hbs';
The last line gives me an error saying it can't find module hbs. I'm looking right at it... I can see it just fine. However when I replace the line with the older CommonJS syntax:
var hbs = require('hbs');
It works fine... what gives? Still on the learning curve with ES6...
Observation 1... as you have in your other exports, you should either import the whole module with an alias:
import * as hbs from 'hbs';
Or you can choose to import specific exports:
import {thing} from 'hbs';
Observation 2... is hbs a TypeScript module, or a JavaScript one? If it is a JavaScript one (as I believe it may be) you will need to pair it with a definition file, for example hbs.d.ts that describes the JavaScript file. TypeScript won't recognise a plain JavaScript module without the definition.
I was experiecing a similar problem. The syntax is correct ES6 indeed.
Good news is that the problem seems to have been fixed already in the development version of the typescript compiler 0.8: try 'npm install typescript#next -g' and then running the compiler again.
you should use default as the imported module name .
import {default as hbs} from "hbs";
this works same as
var hbs = require('hbs');
because require("hbs") imports default module exported by hbs.