I've just been following a tutorial about Axios and I noticed that in it, they import it as axios but when they import React it's as React.
Why are some imports capitalised? is there a technical reason?
is there a technical reason?
Yes and no.
Both of the ones you've listed are the default export of their relevant modules, which means the name you use for them in your code is largely up to you (with a frequent exception in the case of React, more below). (It's different if they're named exports, more below on that as well). I've seen people use Axios instead of axios, for instance.
// Valid:
// ESM
import axios from "axios";
// CommonJS
const axios = require("axios");
// Also valid:
// ESM
import Axios from "axios";
// CommonJS
const Axios = require("axios");
With React, is used to be (and may well still be in some environments) that you needed to call it React if you were using JSX, because JSX is compiled to calls to React.createElement, and if you've used the name react instead, it won't match. (With some modern bundlers and configurations, you don't have to import React at all anymore.)
Named exports have to be imported with the name that they're exported with (so the names are defined by the module author), like this:
// ESM
import { memo } from "react";
// CommonJS
const { memo } = require("react");
although you could rename your local binding if you wanted to with as (perhaps to avoid conflicts with something else you're importing):
// ESM
import { memo as reactMemo } from "react";
// CommonJS
const { memo: reactMemo } = require("react");
With ESM it's an import of a named export using import renaming syntax. With CommonJS, it's destructuring with destructuring renaming syntax.
Related
I am running a react application. The code below does not work because of the following error message:
import = is not supported by #babel/plugin-transform-typescript
Please consider using import <moduleName> from '<moduleName>'; alongside Typescript's --allowSyntheticDefaultImports option.
apiTypes.d.ts
declare module ModuleA {
declare module ModuleB {
export interface ModuleABInterface {
}
}
}
token.ts
import ModuleABInterface = ModuleA.ModuleB.ModuleABInterface
let test: ModuleABInterface
What would be the correct solution to import from nested modules?
It's impossible to nest ES6 modules. TypeScript namespaces (that were originally called "modules") can be nested, but should be avoided. And yes, it's impossible to import from them - you can only import the namespace object itself, using normal ES6 import declarations (not the deprecated import = syntax), then access their properties.
Now I'm studying 'react-native-router-flux' with 'react-redux'.
Beginning of my App.js Code is below.
import { Router } from 'react-native-router-flux';
const RouterWithRedux = connect()(Router);
import { createLogger } from 'redux-logger';
const logger = createLogger();
import ReduxThunk from 'redux-thunk';
const middleware = [logger, ReduxThunk];
I think this code is not neatly because I only use just one of Property from the Modules. Is there any better way to express it?
Maybe the below code is equal with above part of "logger".
const logger = require('redux-logger').createLogger();
How these works are different between import {property} and require.property?
if you use import, Babel then transpire under the hood to require. Also require can require files dynamic.
Require is synchronous and import is asynchronous with better performance.
Require is a node.js way to import files.
I think that import export is more declarative.
Say I have these imports:
import clearLineReporter from '../modules/clear-line-reporter';
import karmaReporter from '../modules/karma-reporter';
import metaTestReporter from '../modules/meta-test-reporter';
import stdReporter from '../modules/std-reporter';
import tapJSONReporter from '../modules/tap-json-reporter';
import tapReporter from '../modules/tap-reporter';
import webSocketReporter from '../modules/websocket-reporter';
these must be referenced like I do above, in other words, I obviously can't do this:
const imports = {
stdReporter: import(...),
tapJSONReporter: import(...),
...
webSocketReporter: import(...)
}
Is there any way I can reference imported files through some form of reflection? Because it seems like I can't group them together to reference them somehow.
Instead of import syntax, I could use require(), but I am wondering if there is some way I can do some dynamic things with import statements, for example reference them all dynamically, such that if I add or remove an import, I don't have to change any other code.
There is a great answer to this question that I discovered by asking a different question, here:
exporting imports as a namespace with TypeScript
Create a file name grouped-modules.ts for example, where you want to simply list only the modules and export each one.
export {default as clearLineReporter} from '../modules/clear-line-reporter';
export {default as karmaReporter} from '../modules/karma-reporter';
export {default as metaTestReporter} from '../modules/meta-test-reporter';
...
export {default as stdReporter} from '../modules/std-reporter';
export {default as tapJSONReporter} from '../modules/tap-json-reporter';
Then in your module you can just do :
import * as mods from './grouped-modules'
export {mods}
It will export both types and values in a namespace called s. You can then import them using :
import {mods} from 'your-module'
const anObject: mods.clearLineReporter = ...;
This allows you to dynamically group your modules into one variable.
Is there any way I can reference imported files through some form of reflection?
Answer is dependent on environment, meant in questing, because import statement can be ES native modules implementation in browser, or babel-ed to require statements in node.js, or compile-time resolved bindings in webpack.
So, in each case there is solution to do something reflection. In node.js with babel-ed code import is just require wrapper, so any information is available there.
In browser with native ES modules, all requests to them can be served via ServiceWorker, so it can provide necessary information about fetched ES modules. Also in browser ES modules can be dynamically imported that way: https://matthewphillips.info/posts/loading-app-with-script-module
Most interesting part is webpack: compile-time resolve and semi-reflection can be achieved by externals resolver in functional style (https://webpack.js.org/configuration/externals/#function), and runtime by load module API (https://webpack.js.org/api/module-variables/#webpack_modules-webpack-specific- )
I'm a newbie on server side javascript, I've used nodejs before for simple things, but only the default libraries (where I never ever need to use require or import keywords), but lately I'm learning ReactNative/ReactXP I've seen:
import RX = require('reactxp');
const popsicle = require('popsicle');
import LoginPage = require("./LoginPage");
import React, { Component } from 'react';
import { AppRegistry, Text } from 'react-native';
import AppState from './AppState';
And exports:
export default Resources; // Resources is an object
export = LoginPage; // LoginPage is a class
The question is, what's the difference between combination of const-require, import-require and import-from? also what is export= it seems not on the Mozilla's doc?
import RX = require('reactxp');
import LoginPage = require("./LoginPage");
export = LoginPage; // LoginPage is a class
These 3 are typescript modules import/export syntax.
const popsicle = require('popsicle');
This is the nodejs modules require.
The rest
import React, { Component } from 'react';
import { AppRegistry, Text } from 'react-native';
import AppState from './AppState';
export default Resources; // Resources is an object
are ES2015 modules (import export).
It's not that you can compare them: they are just import/export for different environments.
It's not basically differences : -
const is new in ES5. Before you had to create it explicitly or by using iffy.
import is new in ES6, which is just a replacement of require (which depended on common js module).
Export is also a feature of ES6, which lets you to use the module or object/var in other file.
So, It is just the new convention & nothing. And now by default in Javascript after ES6.
Also, {} lets you directly expose the modules/object properties, It's also new feature in ES6. E.g : -
Let's you have an object & in file obj.js:
export let objj1 = {
a : function () {},
b : function () {},
}
So Basically there are two ways to use that
1.
let obj = require('obj');
a = obj.a or b = obj.b;
OR
import {a, b} from 'obj'
So now you can direct acess the a & b properties.
This question already has answers here:
`export const` vs. `export default` in ES6
(6 answers)
Closed 6 years ago.
I found a strange situation in ES6. For example, I'm using npm packages react and react-router. I want to import them to the file:
import React from "react";
import { browserHistory } from "react-router";
The strange situation is that I need to wrap browserHistory in figure brackets, but I don't need to wrap React. What is the reason?
import { React } from "react"; // React is undefined
import browserHistory from "react-router"; // browserHistory is undefined
What's the reason that I need to customize my import?
ES6 modules differentiate between two kinds of exports: default exports and other exports.
Every module can have at most one default export. A default export is kind of like the “main attraction” of a module. It’s supposed to be the one thing that you probably meant the module to have. All other exports fit into the other category.
So a module can have any number of exports (even zero), of which at most one can be a default export.
On the export side of the syntax, a default export is simply marked by adding a default after the export keyword:
// this is a normal export
export var foo = 'foo';
// this is a default export
var bar = 'bar';
export default bar;
On the import side of the syntax, this gets a it more complicated: Default exports are imported outside of curly braces. All other exports are imported inside curly braces.
import bar, { foo } from 'some-module';
This would import the default exported member of the module as bar and also import the (named) other export foo. Note that default exports do not have a fixed name: The original name of the member at export time does not matter. Instead, you give it some name when importing it. So you could also write this instead:
import baz, { foo } from 'some-module';
This would still import the same default export from the module, but give it a different name. Other imports however are required to have the correct name, since that’s what’s used to identify them. You can however give them a different name by using the as keyword.
There are a few more things to know when using the export and import statements. You should check MDN for a full description of them.
If the module you are importing has a default export, then you do not have to use the { } syntax to access the given export. Named (non-default) exports must be accessed via the { } syntax. A module can have a default export as well as many named exports.
An example of that would be React which is a default export, but the module also has a named export of Component. To import both of these exports the syntax: import React, { Component } from 'react' would be used.