Почему в первом console.log переменная видна, а во втором нет?

Question

[kid-programmer]

var slider = {
    isRun: true,
    run: function (element, callback) {
        function timer(element, callback) {
            (function inner() {
                    console.log(slider.isRun); //Так переменная видна
                    console.log(this.isRun); //а так нет
                    setTimeout(inner, 1000);
            })();
        }
        setTimeout(function () { timer(element, callback); }, 1000);
    }
}

Обьясните пожалуйста почему в первом console.log переменная видна а во втором нет, правильно ли так к ней обращаться (как в первом варианте) или это некорректно и есть другие способы?

Answer 1

[Евгений Петров]

Ну сейчас вы наслушаетесь всяких фантазий:) На самом деле вы столкнулись с 3-мя вещами.

Объект активации
Это куда ссылается волшебное слово this. Зависит от способа вызова функции (она же метод). Неразрывно связан с контекстом выполнения.

Контекст выполнения
Контекст выполнения отложенного кода в виде таймеров setTimeout и setInterval — глобальный. Поэтому при отложенном вызове this ссылается на глобальный объект. Для клиентского JS глобальный объект — window. А у window нет такого свойства isRun.

Как побороть
Установить явно объект вызова activation object. Для этого есть 3 метода функций — call, apply, bind. Например:

var timer = function (element, callback) {
	...
}.bind(this);

После такой привязки функция timer будет выполняться с объектом активации, ссылающимся на тот контекст, где была создана.

Немедленно исполняемые функциональные выражения (IIFE)
По сути вопрос касается всё того же контекста выполнения.
Вызов функции немедленно после её объявления (или инициализации) выполняется не просто так. В этом случае объектом активации (это куда ссылается this) является глобальный объект.

То есть получается, что даже если принять меры по указанию в timer нужного объекта активации, в функции inner объект активации всё равно будет глобальный объект.

Как побороть
Передать в замыкании для inner ссылку на нужный объект. Кстати, замыкание — это все внешние контексты для созданной функции (для конструктора Function, для таймеров и для eval — отдельная песня). Для инструкции with тоже отдельная песнь, хотя и deprecated.

var timer = function (element, callback) {
	var $this = this;
	(function inner() {
		console.log(slider.isRun); // Так свойство видно
		console.log($this.isRun); // И так тоже
		setTimeout(inner, 1000);
	})();
}.bind(this);

Не создавать функцию inner (а по факту именованный функциональный литерал), и вызывать timer

var timer = function (element, callback) {
	console.log(slider.isRun); // Так свойство видно
	console.log(this.isRun); // И так тоже
	setTimeout(timer, 1000);
}.bind(this);

Итог
Вот так можно представить ваш код

var slider = {
	isRun: true,
	run: function (element, callback) {
		var timer = function (element, callback) {
			var $this = this;
			(function inner() {
				console.log(slider.isRun); // Так свойство видно
				console.log($this.isRun); // И так тоже
				setTimeout(inner, 1000);
			})();
		}.bind(this);
		setTimeout(function () {
			timer(element, callback);
		}, 1000);
	}
}

Comments

[kid-programmer]

спасибо большое за исчерпывающий ответ. Ну почему нет альтернатив джавескипту (мысли в слух) =)

[Евгений Петров]

@kid-programmer а зачем? JS — невероятно мощное средство, способное принять почти любую парадигму. Это круто.

[kid-programmer]

Очень тяжелый, много нужно в голове держать, что чуть упустишь так фэйл. Неочевидный что-ли.

[kid-programmer]

есть ощущение что если решишь написать на нем что-то серьезнее чем slider) то опухоль мозга гарантирована).

[Евгений Петров]

@kid-programmer поэтому я сразу предостерегаю — хотите просто понять основы программирования? Не нужно начинать с JS. Он очень сильно отличается от других.

Если же цель — именно клиентское программирование, то тут никуда не деться. Однако, я вас сразу постараюсь настроить на нужный лад. В HTML5 появилось очень много API или элементов, которые потянули за собой API из смежных областей. Некоторые из них объёмны и требуют знаний в других секторах WEB (например, Canvas).

Если вы пропустили предыдущие абзацы, то вот резюме — клиентское программирование очень сложное. Начинается с простого, а потом уводит в такие джунгли, что мало не покажется.

[Евгений Петров]

@kid-programmer да ну перестаньте... Какая там опухоль. Вы зайдите на codepen.io и посмотрите. Хотите так же? HTML, SVG, CSS, JS.

[kid-programmer]

Да, круто, страшно подумать какие сайты будут лет через 10 ) Я просто начинал с C++ потом перешел на Java потом на C# и параллельно смотрю на Python =). Просто изначально учил все штуки по ООП, принципы, паттерны, архитектуры программ и перейти с языка на язык не проблема, неделя знакомства с синтаксисом и особенностями, например щас остановился на следующем для win server это конечно C# для lin серверов это python. Это я все о том что в любой сфере есть альтернативы, например серверная сторона, выбирай что по душе, RoR, Django, Asp, Java и еще куча всего. Странно что для клиента один только JavaScript, даже печально. Я не против javascript, я уважаю все технологии, языки, каждому свое. Но выбор должен быть, а его нет.

[Евгений Петров]

@kid-programmer сервер (условно) — это один компьютер с известной ОС и всем прилагающимся. Клиентом может выступать совсем неизвестное ПО от совсем неизвестного производителя.

Какая альтернатива?)) С поддержкой единственного языка большие проблемы. Мы уже жили в эпоху «Мы делаем сайты только для IE». Ничего хорошего. Тьфу просто. Поддержка VBScript и Javascript в IE показали, насколько губителен такой подход к мультиязычности. Наелись, больше не хочется.

Так что так и будет — клиент на выбор, невеста одна. Не нравится? За дорогой другой стрипбар.