Використання Node.js вимагає порівняно з ES6 імпорту / експорту

У проекті, над яким я співпрацюю, у нас є два варіанти, яку модульну систему ми можемо використовувати:

1. Імпорт модулів за допомогою requireта експорт із використанням module.exportsта exports.foo.
2. Імпорт модулів за допомогою ES6 importта експорт за допомогою ES6export

Чи є якісь переваги від використання одного над іншим? Чи є ще щось, що ми повинні знати, якби ми використовували модулі ES6 над Node?

Чи є якісь переваги від використання одного над іншим?

Майте на увазі, що ще немає механізму JavaScript, який би підтримував ES6 модулі. Ви самі сказали, що використовуєте Babel. Babel перетворює importта exportдекларацію на CommonJS ( require/ module.exports) за замовчуванням у будь-якому випадку. Тож навіть якщо ви використовуєте синтаксис модуля ES6, ви будете використовувати CommonJS під кришкою, якщо запускаєте код у Node.

Існують технічні відмінності між модулями CommonJS та ES6, наприклад CommonJS дозволяє динамічно завантажувати модулі. ES6 цього не дозволяє, але для цього є API для розробки .

Оскільки модулі ES6 є частиною стандарту, я б їх використовував.

Ви можете скористатися кількома можливостями використання / можливостями:

Потрібно:

• Ви можете мати динамічне завантаження там, де завантажене ім'я модуля не заздалегідь визначене / статичне, або де умовно завантажуєте модуль, лише якщо це "справді потрібно" (залежно від певного потоку коду).
• Завантаження синхронне. Це означає, що якщо у вас кілька requires, вони завантажуються та обробляються по черзі.

Імпорт ES6:

• Ви можете використовувати імпортний імпорт, щоб вибірково завантажувати лише потрібні вам частини. Це може зберегти пам'ять.
• Імпорт може бути асинхронним (і в поточному завантажувачі модулів ES6, він насправді є) і може працювати трохи краще.

Крім того, система модуля «Вимагати» не базується на стандартах. Зараз існування модулів ES6 навряд чи стане стандартним. В майбутньому буде наявна підтримка модулів ES6 в різних реалізаціях, що буде вигідним з точки зору продуктивності.

Основними перевагами є синтаксичні:

• Більш декларативний / компактний синтаксис
• Модулі ES6 в основному зроблять UMD (Universal Module Definition) застарілим - по суті видаляє розкол між CommonJS та AMD (сервер проти браузера).

Ви навряд чи зможете побачити якісь переваги в роботі з модулями ES6. Вам все одно знадобиться додаткова бібліотека для з’єднання модулів, навіть якщо в браузері є повна підтримка функцій ES6.

Чи є якісь переваги від використання одного над іншим?

Поточна відповідь - ні, оскільки жоден із поточних двигунів браузера не реалізується import/exportзі стандарту ES6.

Деякі діаграми порівняння http://kangax.github.io/compat-table/es6/ не враховують це, тому коли ви бачите майже всю зелень для Chrome, будьте обережні. importключове слово від ES6 не враховано.

Іншими словами, поточні двигуни браузера, включаючи V8, не можуть імпортувати новий файл JavaScript з основного файлу JavaScript через будь-яку директиву JavaScript.

(У нас може бути ще лише кілька помилок або років, поки V8 не впровадить це відповідно до специфікації ES6.)

Цей документ - це те, що нам потрібно, і цей документ - це те, що ми мусимо підкорятися.

А стандарт ES6 сказав, що залежність від модуля повинна бути там, перш ніж ми прочитаємо модуль, як на мові програмування C, де у нас були (заголовки) .hфайли.

Це гарна і добре перевірена структура, і я впевнений, що фахівці, які створили стандарт ES6, мали це на увазі.

Це те, що дозволяє Webpack або іншим постачальникам пакетів оптимізувати пакет в деяких особливих випадках, а також зменшити деякі залежності від пакета, які не потрібні. Але у тих випадках, коли ми маємо ідеальні залежності, цього ніколи не станеться.

Буде потрібно деякий час, поки import/exportнативна підтримка не з’явиться, і requireключове слово довгий час нікуди не дінеться.

Що таке require?

Це node.jsспосіб завантаження модулів. ( https://github.com/nodejs/node )

Вузол використовує методи системного рівня для читання файлів. Ви в основному покладаєтесь на це під час використання require. requireзавершиться в деяких системних викликах, таких як uv_fs_open(залежить від системи завершення, Linux, Mac, Windows), щоб завантажити файл / модуль JavaScript.

Щоб перевірити, чи це правда, спробуйте скористатися Babel.js, і ви побачите, що importключове слово буде перетворене в require.

Використання модулів ES6 може бути корисним для «струшування дерева»; тобто дозволяють Webpack 2, збірці (або іншим постачальникам) ідентифікувати кодові шляхи, які не використовуються / імпортуються, і тому не вносять їх у отриманий пакет. Це може значно зменшити розмір файлу, усунувши код, який вам ніколи не знадобиться, але з CommonJS постачається за замовчуванням, оскільки Webpack та ін не мають можливості знати, чи потрібен він.

Це робиться за допомогою статичного аналізу шляху коду.

Наприклад, використовуючи:

import { somePart } 'of/a/package';

... надає постачальнику натяк, який package.anotherPartне потрібен (якщо він не імпортований, його не можна використовувати, правда?), тому він не буде турбувати його пакет.

Щоб увімкнути це для Webpack 2, вам потрібно переконатися, що ваш транспілер не виплює модулі CommonJS. Якщо ви використовуєте es2015плагін з babel, ви можете відключити його .babelrcтак:

{
  "presets": [
    ["es2015", { modules: false }],
  ]
}

Збірка та інші можуть працювати по-різному - перегляньте документи, якщо вас цікавить.

Якщо мова йде про асинхронізацію або, можливо, ліниве завантаження, то import ()це набагато потужніше. Подивіться, коли нам потрібен компонент асинхронним способом, тоді ми використовуємо importйого якось асинхронним способом, як при constвикористанні змінних await.

const module = await import('./module.js');

Або якщо ви хочете використовувати require()тоді,

const converter = require('./converter');

Річ - import()насправді асинхронний характер. Як зазначає neehar venugopal в ReactConf , ви можете використовувати його для динамічного завантаження реагуючих компонентів для архітектури на стороні клієнта.

Крім того, це краще, коли справа доходить до маршрутизації. Це одне особливе, що змушує мережевий журнал завантажити необхідну частину, коли користувач підключається до певного веб-сайту до його конкретного компонента. наприклад, сторінка входу до інформаційної панелі не завантажуватиме всі компоненти інформаційної панелі. Тому що те, що потрібно поточного, тобто компонента для входу, те лише буде завантажено.

Це ж стосується export: ES6 exportточно такі ж, як і для CommonJS module.exports.

ПРИМІТКА. Якщо ви розробляєте проект node.js, тоді вам потрібно суворо використовувати, require()оскільки вузол викине помилку виключення, як invalid token 'import'якщо б ви використовували import. Отже, вузол не підтримує заяви про імпорт.

ОНОВЛЕННЯ - Як запропонував Дан Даскалеску : З версії 8.5.0 (випущена вересня 2017 року), node --experimental-modules index.mjsви можете використовувати importбез Babel. Ви також можете (і повинні) публікувати свої пакети npm як рідний ESModule, маючи зворотну сумісність за старим requireспособом.

Щоб дізнатися більше про те, де використовувати імпорт асинхронізації, див. Це https://www.youtube.com/watch?v=bb6RCrDaxhw

Найголовніше, що потрібно знати, це те, що модулі ES6 справді є офіційним стандартом, тоді як CommonJS (Node.js) модулі - це не такі.

У 2019 році модулі ES6 підтримують 84% браузерів. Хоча Node.js ставить їх за прапором --experimental-модулів , є також зручний пакет вузлів під назвою esm , який робить інтеграцію плавною.

Інша проблема, з якою ви, швидше за все, зіткнетеся між цими модульними системами, - це розташування коду. Node.js припускає, що джерело зберігається в node_modulesкаталозі, в той час як більшість модулів ES6 розгорнуті в плоскій структурі каталогів. Зробити це непросто, але це можна зробити, взломивши package.jsonфайл зі скриптами до і після встановлення. Ось приклад ізоморфного модуля та стаття, що пояснює, як це працює.

Я особисто використовую імпорт, тому що ми можемо імпортувати потрібні методи, члени за допомогою імпорту.

import {foo, bar} from "dep";

Назва файлу: dep.js

export foo function(){};
export const bar = 22

Кредит йде на Поля Шаня. Більше інформації .

На сьогоднішній день імпорт ES6, експорт завжди збирається в CommonJS , тому використання тих чи інших переваг не буде. Хоча використання ES6 рекомендується, оскільки це повинно бути вигідним, коли виходить нативна підтримка браузерів. Причина полягає в тому, що ви можете імпортувати партії з одного файлу, тоді як для CommonJS потрібно вимагати весь файл.

ES6 → import, export default, export

CommonJS → require, module.exports, exports.foo

Нижче наведено загальне використання цих даних.

За замовчуванням експорт ES6

// hello.js
function hello() {
  return 'hello'
}
export default hello

// app.js
import hello from './hello'
hello() // returns hello

ES6 експортує кілька, а імпортує кілька

// hello.js
function hello1() {
  return 'hello1'
}
function hello2() {
  return 'hello2'
}
export { hello1, hello2 }

// app.js
import { hello1, hello2 } from './hello'
hello1()  // returns hello1
hello2()  // returns hello2

CommonJS module.exports

// hello.js
function hello() {
  return 'hello'
}
module.exports = hello

// app.js
const hello = require('./hello')
hello()   // returns hello

CommonJS module.exports кілька

// hello.js
function hello1() {
  return 'hello1'
}
function hello2() {
  return 'hello2'
}
module.exports = {
  hello1,
  hello2
}

// app.js
const hello = require('./hello')
hello.hello1()   // returns hello1
hello.hello2()   // returns hello2

Не впевнений, чому (ймовірно, оптимізація - ледаче завантаження?) Це працює так, але я помітив, що importможе не проаналізувати код, якщо імпортовані модулі не використовуються.
Що може не очікувати поведінки в деяких випадках.

Взяти ненависний клас Foo як нашу залежність вибірки.

foo.ts

export default class Foo {}
console.log('Foo loaded');

Наприклад:

index.ts

import Foo from './foo'
// prints nothing

index.ts

const Foo = require('./foo').default;
// prints "Foo loaded"

index.ts

(async () => {
    const FooPack = await import('./foo');
    // prints "Foo loaded"
})();

З іншої сторони:

index.ts

import Foo from './foo'
typeof Foo; // any use case
// prints "Foo loaded"