Что означает "утечка" в глобальную сферу?

Ответ 1

[[Рассказ]]

Не делайте глобальных переменных когда-либо и используйте загрузчик асинхронного модуля, например requirejs или curl

[[Длинная история]]

Этот комментарий был плохо структурирован.

В модульной системе нет ничего плохого. Я жаловался на использование глобальных переменных вообще. (Я все еще думаю, что полный шаблон типового модуля раздувается).

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

• Что означает "утечка" в глобальную область?

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

• Почему так плохо?

Наличие какого-либо состояния во всем мире может привести к повреждению этого состояния.

• Как вы его избегаете?

Вы не можете. Тем не менее, вы можете минимизировать количество глобальных переменных. Чтобы полностью исключить глобальное состояние, вы можете использовать асинхронные загрузчики. Они определяют несколько глобальных переменных, которые вы можете использовать.

• Если вы хотите создавать постоянные пользовательские объекты, почему шаблон модуля (ниже) плохой?

В шаблоне модуля нет ничего плохого. Проблема заключается в том, чтобы хранить ваш модуль по всему миру. Проблема связана с глобальными пространствами имен.

• Шаблоны проектирования позволяют вам инкапсулировать сложную логику, неожиданно ли инкапсуляция возникает из-за того, что они писали в JavaScript?

Теперь, когда я прояснил намерение комментария, этот вопрос не имеет особого значения

• Или... этот комментатор просто ошибается?

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

Альтернативой является использование асинхронных загрузчиков и определение модулей. Их можно сузить до двух глобальных переменных. define и require.

require = function(moduleName, callback)

Это получит модуль, а затем вернет его вам.

define = function(obj)

определяет модуль.

Концепция здесь заключается в том, что вы несколько файлов кода следующим образом:

// main.js
require([
  "foo.js",
  "bar.js",
  ...,
], function(foo, bar, ...) {
   // do stuff
}); 

//foo.js

(function() {
    var namespace = modulePatternCode;
    ...
    define(namespace):
})();

//bar.js 

(function() {
    var namespace = modulePatternCode;
    ...
    define(namespace):
})();

Ответ 2

"Утечка" в глобальную область действия - это когда что-то, используемое в локальной области, непреднамеренно доступно для глобальной области. Это означает назначение переменной, не указанной в текущей области:

function myFunction() {
    a=1;
}

myFunction();
alert(a);
//-> 1

Это плохо, потому что могут возникать конфликты имен, приводящие к переменным с разными значениями/типами, чем ожидалось. Это также может привести к ошибке в старых Internet Explorers, когда вы забудете использовать ключевое слово var для переменной, используемой в инструкции for.

Я бы не умышленно делал переменную global "утечкой", потому что это больше похоже на то, что вы "заливаете" ее в глобальную область. Тем не менее, это по-прежнему часто считают неправильной практикой некоторыми (хотя я думаю, что это немного мелодраматично), потому что по-прежнему существуют потенциальные столкновения имен с текущими свойствами объекта window или переменными, заданными другими скриптами и библиотеками.

Ответ 3

Ваш модуль только "просачивает" его держатель пространства имен, поэтому он довольно приемлем.

Ответ 4

Пример загрузчика с использованием RequireJS:

Определите модуль utilities в utils.js:

define(function () {
    return {
        each: function (iterable, callback) {
            // ...
        },
        map: function (iterable, mapper) {
            // ...
        }
    };
});

Используйте вышеуказанный модуль в другом модуле, скажем, math.js:

define([ "utils" ], function (utils) {
    return {
        sum: function (numbers) {
            var sum = 0;

            utils.each(numbers, function (n) {
                sum += n;
            });

            return sum;
        },
        average: function (numbers) {
            return this.sum(numbers) / numbers.length;
        }
    };
});

И вы можете использовать math.js в другом файле, например main.js:

console.log("About to add 1-3");

require([ "math" ], function (math) {
    console.log(math.sum([ 1, 2, 3 ]));
});

У вас все еще есть пространства имен и по-прежнему сохраняйте их теплыми и уютными внутри модулей:

namespace.js:

define([ "foo", "bar", "moo" ] function (foo, bar, moo) {
    return {
        foo: foo,
        bar: bar,
        moo: moo
    };
});

Тогда остальные модули могут использовать это пространство имен во время определения:

define([ "namespace" ], function (namespace) {
    namespace.foo(42);
});

Или во время выполнения в другом модуле:

define(function () {
    return {
        initialize: function () {
            require([ "namespace" ], function (namespace) {
                namespace.foo(42);
            });
        }
    };
});

В вышеприведенных правилах ничего, кроме define и require, являются глобальными. Конечно, это просто иллюстративные примеры, так как существует множество различных вариантов определения/использования модулей в RequireJS.