Преобразование закрытия в модуль es6

Question

Я использую среду сборки javascript, которая поддерживает модули es6 (using es6-module-transpiler), чтобы вы могли просто импортировать материал из разных файлов.

Теперь у меня есть сторонняя библиотека, которую я бы хотел «импортировать».

Библиотека населяет его функциональность, как это:

(function() {/*...*/}).call(this); 

было бы безопасно опустить замыкание и преобразовать его в:

export default function() {/* ... */}; 

Или есть лучший способ?

Заранее благодарен!

Answer 1

Исходный код, который вы показываете , вызывает анонимную функцию, которая в любом смысле должна определять глобальную переменную, тогда как второй фрагмент кода, который вы показываете, просто экспортирует функцию, что совсем другое.

В целях обсуждения, давайте предположим, что исходный код определяет глобальный, как это:

// my-third-party-module.js 
(function() { 
    let myVar = 22; 
    window.MyThirdPartyModule = { log: function() { console.log(myVar); } }; 
}.call(this); 

и вы используете в качестве так:

// app.js 
MyThirdPartyModule.log(); 

Вы можете переписать это как

// my-third-party-module.js 
let myVar = 22; 
export default { log: function() { console.log(myVar); } }; 

// app.js 
import MyThirdPartyModule from `my-third-party-module'; 
MyThirdPartyModule.log(); 

Обратите внимание, что мы переместили переменную myVar, которая была локальной для t он анонимная функция на верхнем уровне модуля.

Однако, в зависимости от ваших предпочтений, а не экспортировать большой объект, который является своим родом предварительно модуль менталитета, вы можете экспортировать свои API, индивидуально:

// my-third-party-module.js 
let myVar = 22; 
export function log { console.log(myVar); } 

// app.js 
import {log} from `my-third-party-module'; 
log(); 

или, если вы предпочитаете

// app.js 
import * as MyThirdPartyModule from `my-third-party-module'; 
MyThirdPartyModule.log(); 

Однако все эти подходы предполагают, что вы можете и хотите отредактировать источник сторонней библиотеки. Если это не так, то вы могли бы написать небольшой кусок клея кода, такие как

// my-third-party-module-interface.js 
import 'my-third-party-module'; // This will run the module. 
export default MyThirdPartyModule; // Export the global it defined. 

// app.js 
import MyThirdPartyModule from 'my-third-party-module-interface'; 

Если вы предпочли бы снова экспортировать отдельные интерфейсы API, вы можете расширить клей для реэкспорта каждого из них:

// my-third-party-module-interface.js 
import 'my-third-party-module'; // This will run the module. 

const {log, otherAPI, ...} = MyThirdPartyModule; 
export {log, otherAPI, ...}; 

// app.js 
import {log} from 'my-third-party-module-interface'; 

Answer 2

Преобразование устаревших зависимостей по-прежнему является проблемой. И ужасный рабочий процесс, который они используют, делает вещи намного сложнее, прикрывая фактический код браузером и глупостью webpack.

А что делать? Экзистенциально библиотека гарантируется только для того, чтобы внести глобальное окно, но неясно и странно. И все немного другое.

Так пусть наследие просто делать то, что он должен сделать для вас, но завернутые в модуле, так что вы можете импортировать его, а не использовать тег сценария:

https://medium.com/@backspaces/es6-modules-part-2-libs-wrap-em-up-8715e116d690