Основная причина, по которой глобальные переменные не приветствуются в javascript, заключается в том, что в javascript весь код разделяет одно глобальное пространство имен, а также javascript подразумевает глобальные переменные, т.е. переменные, которые явно не объявлены в локальной области видимости, автоматически добавляются в глобальное пространство имен. Слишком большая зависимость от глобальных переменных может привести к конфликтам между различными скриптами на одной странице (прочтите статьи Дугласа Крокфорда ).

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

var FOO = (function() {
    var my_var = 10; //shared variable available only inside your module

    function bar() { // this function not available outside your module
        alert(my_var); // this function can access my_var
    }

    return {
        a_func: function() {
            alert(my_var); // this function can access my_var
        },
        b_func: function() {
            alert(my_var); // this function can also access my_var
        }
    };

})();

теперь, чтобы использовать функции в вашем модуле в другом месте, используйте FOO.a_func(). Таким способом разрешить конфликты глобальных пространств имен вам нужно только изменить имя FOO.

Семантика мой мальчик. Семантика.

Начните с одного глобального: myApp = {}; В этом должно быть все. Единственным исключением будет ваша библиотека AJAX (есть несколько крайних исключений, например, работа с обратными вызовами JSONP).

В myApp должно быть очень мало свойств. Вы захотите хранить свойства своего приложения в контейнерах, таких как config или settings.

myApp = {
    config:{
        prop:1
    },
    settings:{
        prop:2
    },
    widgets:{
        List: function(props){},
        Item: function(props){}
    }
}

Тогда у вас может быть больше свойств в нижних модулях, компонентах, синглтонах и конструкторах классов (виджетах).

Эта настройка дает вам дополнительное преимущество, заключающееся в возможности доступа к любому свойству из любого другого места, поскольку вы можете получить его с помощью myApp global. Однако вы должны использовать "this", когда это возможно, потому что поиск выполняется быстрее. И просто установите свойство напрямую, не беспокойтесь о псевдогеттерах / сеттерах. Если вам действительно нужен геттер / сеттер, запрограммируйте его для этого конкретного использования.

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

И не умничай с частными переменными. Они тоже плохие: http://clubajax.org/javascript-private-variables-are-evil/

Глобальное состояние вызывает проблемы в нескольких областях. Один из них - повторное использование кода. Когда вы получаете доступ к некоторому глобальному состоянию, это означает, что компонент должен знать о своей среде (что-то вне себя). По возможности этого следует избегать, поскольку это делает компонент непредсказуемым.

Скажем, у меня есть объект, который обращается к вашей функции globalVariables, и я хочу использовать его на другой странице. Как мне узнать, как определить объект globalVariables или даже как его определить? Однако, если вы можете передать информацию в конструктор или в качестве аргумента функции, я могу легко определить, что требуется объекту.

Также, когда вы получаете доступ или изменяете глобальную область видимости, вы рискуете повлиять на другие объекты. Вот почему библиотеки, такие как jquery, используют только одно имя в глобальной области (наименее возможное). Это снижает вероятность конфликта с другими библиотеками. Другими словами, глобальная область действия находится вне вашего контроля, поэтому это опасно.

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

Рассмотрим этот фрагмент кода, который я нашел:

if (typeof session != 'undefined' && !data.cart.request_status)
  data.input_definitions.passengers =
    inflate_passenger(session, data.input_definitions.passengers);

Мне нужно было обернуться и спросить программиста felow, откуда взялась эта session переменная, так как поиск кода не обнаружился там, где она была установлена.

Оказалось, еще один пакет от компании устанавливает глобальную переменную. Кодируйте это как шутку: если вам нужно это объяснить, это, вероятно, не так уж и хорошо.

Временное решение с использованием ES6:

Находясь в Node, используйте import или require, чтобы привести желаемый материал в лексическую область видимости, не позволяйте людям касаться вашей глобальной среды без вашего ведома.

import {Sesssion} from 'api-core';
const Session = require('api-core').session;

Если вы используете внешний интерфейс, доставляющий код для браузера, вы не можете использовать import, если вы не транспилируете свой код ES6 с помощью Babel < / а>.

// $ npm install --save-dev gulp-babel babel-preset-es2015

// gulpfile.js
const gulp  = require('gulp');
const babel = require('gulp-babel');

gulp.task('transpile', () => {
  return gulp.src('src/app.js')
    .pipe(babel({presets: ['es2015']}))
    .pipe(gulp.dest('dist'));
});

// $ gulp transpile

// scripts/app.js
var MyApp = {
  globals: {
    foo: "bar",
    fizz: "buzz"
  }
};

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

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

Вы действительно не хотите этого делать.
Что касается того, почему вы видите, например, верхний пост здесь: Какой самый ЗЛОЙ код вы когда-либо видели в производственной корпоративной среде?

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

(function() {
  var notaglobal = 1;
  alert(notaglobal);
})();
//notaglobal is not defined in this scope

Другой ответ наиболее объясняется анонимной функцией, поскольку упоминается в этой статье,

Анонимные функции сложно отлаживать, поддерживать, тестировать или повторно использовать.

Вот пример с нормальной функцией. Легче читать и понимать.

/* global variable example */

    var a= 3, b= 6;
    
    function fwithglobal(){
    console.log(a, b); // 3 6 expected
    }
    
    fwithglobal(); // first call
    
    function swithglobal(){
    var a=9;
    console.log(a, b); // not 3 6 but 9 6
    }
    
    swithglobal(); // second call
    

/* global variable alternative(function parameter) */

    function altern(){
    var a= 3, b= 6; // var keyword needed
      f_func(a,b);
      s_func(a,b);
    }
    
    function f_func(n, m){
    console.log(n, m); // 3 6 expected
    }
    
    function s_func(n, m){
    var a=9;
    console.log(n, m); // 3 6 expected
    }
    
    altern(); // only once

Глобальные переменные плохи ... если оставить их неуправляемыми!

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

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

Одна вещь, не упомянутая в текущих ответах, которая, на мой взгляд, важна, - это понимание контейнеров DI и IoC. Они решают многие проблемы, которые люди пытаются решить с помощью глобальных переменных, но покрывают связанные проблемы, которые не могут быть реализованы простыми глобальными переменными, например жизненные циклы объектов.