Комментарии 9
// === module1.js
export class First {}
export class Second {}
export class Third {}
// === module2.js
import { First } from './module1.js';
First.whatever();
// === module3.js
import * as namespace from './module1.js';
new namespace.Second();
// === module4.js
export * as namespace from './module1.js';
Вылезайте из бункера, немцы ушли :-)
Основные фишки namespace в том, что они могут быть иерархическими, а реализацию одного пространства имён можно раскидывать по разным файлам. Модуль это просто вырожденный случай, где файл образует отдельный одноуровневый namespace.
Тот же Typescript поддерживает обе концепции, но по-моему на практике модули используются гораздо чаще.
Модуль это просто вырожденный случай, где файл образует отдельный одноуровневый namespace.
Учитывая что есть re-export-ы, вы можете организовать какую-угодно матрёшку любой вложенности и структуры. Dead code elimination вам за это спасибо не скажет, но тем не менее.
Тот же Typescript поддерживает обе концепции, но по-моему на практике модули используются гораздо чаще.
Потому что namespace
-ы получились какими-то шибко неудобными и контринтуитивными.
Вылезайте из бункера, немцы ушли :-)
Пусть сначала немцы капитулируют и признают, что CORS-ограничения на локальные файлы были ошибкой.
namespaceOne у вас объявлена как var, значит её легко переписать в любом месте кода, потеряв весь ваш якобы namespace.
Если уж колхозить что-то, то, IMHO, лучше так:
const namespaceOne = (() => {
class First {};
class Second {};
class Third {};
return { First, Second, Third };
})();
Но, в целом, хватает и возможностей модулей.
Это из вики:
In computing, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds.
Namespace'ы дают возможность однозначно идентифицировать любой объект кода (класс, константу, функцию, метод, свойство) в рамках всего проекта (приложения) или даже глобально (в рамках всех объектов кода в пределах одного ЯП). Именно в этом и вся сложность - обеспечение уникальной идентификации (в пределах пакета/проекта/глобально).
То, что вы описали в данной публикации:
Теперь вы можете смело добавлять свой код в любой проект, в любое место просто взяв его {в фигурные скобки} и все - секундное дело.
это scope. Ограничение области видимости переменных. А var
- способ пробиться за границы блочной видимости:
var namespaceOne = {First: First, Second: Second, Third: Third};
Вы должны каким-то образом обеспечить уникальность всех var namespaceX
в пределах вашего проекта, чтобы не получилось нечто типа такого:
{
class First {}
var namespace = {First};
}
{
class Second {}
var namespace = {Second};
}
{
const ns = namespace; // {Second}
}
Вот это "каким-то образом обеспечить уникальность" и есть про namespace'ы (т.е., про идентификацию).
В общем, коллеги выше правы - используйте es-модули. У каждого модуля уже есть свой scope. А ещё у каждого модуля есть свой адрес, уникальный в пределах приложения.
Спасибо. Комментарии учитываются и отражаются на статье. Чтобы каша из топора была понаваристее.
Namespaces в JavaScript. Ставим точку в вопросе