Правильный захват контекста в Javascript

Всегда волновал вопрос правильной и удобной работы с контекстом, ваша статья очень помогла, спасибо.
В ExtJS у ольшинства функций есть параметр scope, указав который, к нему можно обращаться по this.
В документации jquery вообще не освещен этот вопрос.
Пример из MooTools намного удобней всех велосипедов, которые я себе для этого создавал, работая с jquery.

Часто бывает еще удобно использовать mootools.net/docs/more/Class/Class.Binds

что-то как-то похоже на перегон из пустого в порожнее, и аргументы весьма неубедительные. чем это this семантичнее self?

ваш предпоследний пример, кстати, отлично показывает преимущества сохранения контекста в переменную.

var self = this;
…
dataRouter.get(self.parse);

parse: function() {
// self.*
}

это не говоря о том, что «приватные» методы вообще-то хранятся в переменных внутри scope конструктора, а не в this, т.к. this публичен.

() {

var private = function() {};

self.public = function() {
setTimeout(private, 100);
}

Спасибо за чудесную стилистическую идею var $this = $(this);! И как сам не догадался :)

TheShock, ты, конечно, клевый чувак, но это все ненужное наживание геморроя.

asyncFunc(function () {
    this.callMethod();
}.bind(this));

А если внутри функции требуются оба this? А как быть с параметрами? Все что нужно давать осмысленные имена для внешних this.

Еще один плюс к использованию var self = this; — при сжатии кода зарезирвированное слово «this» остается без изменений, т.е. не сжимается. А переменная «self» или любая другая — может быть сжата.

В статье — ни слова про замыкания… а ведь var self = this; перед моментом смены контекста работает только потому что в js есть механизм замыканий. Этот механизм является очень красивым, но и довольно «дорогим». Злоупотребление им (а var self = this — это явное злоупотребление) в больших количествах приводит к утечкам памяти.

Постоянно это использую. Ну и есть мнение, что не стоит трогать прототипы, в таком случае можно пользоваться underscore.js

Мое мнение: если приходится сохранять два контекста — с кодом что-то не так и надо еще раз его пересмотреть. На моей памяти не было ни одного случая, когда приходилось бы запоминать более одного контекста.
Про осмысленные имена: они несомненно нужны, если по какой-либо причине сохраняется более одного контекста. В случае с одним — self вполне достаточно и понятно.

putCardSmart: function (card) {
this.putCard( card,
// Этот метод вызовется только когда карта долетит, но он сохранит контекст.
this.finishSmart.bind(this)
);
},

В каком контексте будет выполнен метод this.finishSmart? :)

.bind(this) в данном примере явно лишний.

Больше похоже на навязывание своего мнения.
Как по мне, bind особо не отличается от self, использую оба способа в разных ситуациях.
По производительности не понятно что лучше, создание анонимной функции (на вызов bind) или замыкание (self)
self использую в своих библиотеках, т.к. bind определяют чуть ли не в каждом framework'e и везде по разному, а self удобно использовать когда нужно передать дополнительные параметры, например

var cl = {
    test: function() {
        var a = 1;
        var b = 2;
        var self = this;

        setTimeout(function() {
            self.callMethod(a);
        }
        setTimeout(function() {
            self.callMethod(b);
        }
    }
}

Я предпочитаю var that = this. Всё-таки используется «тот» контекст, а не «этот». Да и self — предопределённая переменная в JS, которая впрочем, как правило, не используется.

Немножко расширим прототип Function

Если ваш браузер поддерживает ES5, то вы его не расширяете, а напротив «портите». Потому что в ES5 уже есть Function.bind со своей семантикой. В MooTools даже баг есть связанный с этим: их bind неправильно себя ведёт в браузерах где уже есть Function.bind c ES5 семантикой, потому что они пытаются его использовать в качестве своего bind. И вот решение:

For MooTools Core 1.3 we are going to adopt the ES5 version of Function.prototype.bind.

Поддержу критиков по ключевым моментам.

1) Случай, когда нужно сохранять разные контексты, возможен, но это уже повод задуматься — может что-то здесь не так? Может стоит что-то упросить и переделать, а не городить огород? А с одним контекстом и self/that/me/<что_нравится> сойдет. Наоборот — будет единообразие в коде и не требуется каждый раз вспоминать, как замыкание на себя назвал.

2) Уже сказали, что злоупотребление биндом чревато утечками памяти. Все-таки плодить замыкания внутри анонимных функций лишний раз, ИМХО, не стоит — это даже не только обсуждаемого случая касается, а вообще. Одно дело, когда мы в конструкторе сделали одно замыкание и потом его используем в асинхронной работе, приватных методах и т.п., а другое — когда все вызовы тех же приватных методов у нас обернуты в анонимную функцию с замыканием в ней контекста. Брррр… Мне аж жалко становится несчастных разработчиков интерпретаторов Javascript… :-)

$('input').bind('keydown', function () {
        var $this = $(this);
        $this.css({
            background : $this.val()
        });
    });

В примере выше вообще нет переключения контекста.

bind использовать стоит однозначно. Тем более он уже вошел в новый в javascript 1.8.5

Как именовать переменные — это наверно от команды больше зависит.

Мне кажется кроме bind и call не стоит ничего использовать, они на много удобней.

О да, а расширять прототипы базовых объектов — это офигенно правильно.

Стоит отметить что использование closure (замыкание) или bind — зависит от архитектуры. Вы не упомянули в статье, что Function.prototype.bind внесен в стандарт ECMAscript 5, и последние версии браузеров его поддерживают (даже IE9). По стандарту можно передавать не только контекст но и статичные параметры, то есть myfunc.bind(someObject, 1, 2) вернет функцию которая будет вызываться с контекстом someObject а первые два параметра будут 1 и 2 соответственно, не важно с какими параметрами она вызвана, и с каким контекстом (для call и apply игнорируется первый аргумент).
Если bind поддерживается браузером нативно, то его использование гораздо эффективнее замыкания, так как в случае замыкания создается экземпляр функции, которая «помнит» переменные своей области видимости, что ведет к затратам по памяти. В случае с bind создается обертка для функции, то есть это отдельная специальная структура, которая содержит ссылку на функцию, контекст и список значений для статичных параметров (если такие есть). В последнем случае получается экономичнее в плане памяти.
К тому же closure ни разу не эквивалентно bind и есть ряд ситуаций, когда нельзя использовать одно или другое. Разница проявляется в области видимости. Все дело в том что когда вы делаете closure то у созданной функции будет та область видимости, где она объявлена (создана). Когда вы делаете bind, то область видимости у функции сохраняется (там где она была объявлена), меняется только контекст. Это нельзя увидеть в примерах статьи, так как в них область видимости перекрывается, и сами примеры весьма просты.
Вот пример:

function example(){
return this.value + privateValue;
}

function exampleClass(value){
var provateValue = value;

// делаем метод со статичным контестом
var self = this;
this.methodWithFixedContext = function(){
return self.value + privateValue;
}
// либо же
this.methodWithFixedContext = (function(){
return this.value + privateValue;
}).bind(this);

// но никак не
this.methodWithFixedContext = example.bind(this);
}

Не смотря на то, что текст второй анонимной функции совпадает с текстом функции example — у них разная область видимости, и результат выполнения будет разный. Во втором случае по сути мы делает замыкание плюс делаем bind, который в случае эмуляции (для браузеров которые не поддерживают его нативно), создает еще одно замыкание. В такой ситуации второй вариант весьма затратный, к тому же нагроможденный. Так что предпочтение лучше отдать первому варианту (менее накладно и проще в восприятии).
Другой пример:

var globalCounter = 0;
function setMethodTimeout(someObject){
globalCounter++;

// замыкание
setTimeout(function(){
someObject.method(globalCounter);
}, 10)

// почти то же самое, но через bind
setTimeout(someObject.method.bind(someObject, globalCounter), 10);
}

var objectA = { method: function(){ console.log(arguments) } };
var objectB = { method: function(){ console.log(arguments) } };
setMethodTimeout(objectA);
setMethodTimeout(objectB);

В случае использования замыкания по сути будут вызовы:

// замыкание
objectA.method(2);
objectB.method(2);
// bind
objectA.method(1);
objectB.method(2);

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

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

в общем-то в нормальных фреймворках это реализовано (см. scope в ExtJS или context в YUI).

Похоже, тут начинает действовать закон en.wikipedia.org/wiki/Sayre%27s_Law: «In any dispute the intensity of feeling is inversely proportional to the value of the stakes at issue.»

Какая разница, bind — не bind, по большому счету-то, а комментарии за сотню уже перевалили)

Спасибо. Давно не читал таких очевидных вещей + копипасту из документации.
Вы бы подумали о сборщике мусора в том же ИЕ6. Он с ума сойдет от такого количества контекстов, которые ему придется хранить.

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

правильная реализация BIND в соответствии стандарту есть нечто вроде:

Function.prototype.bind = function() {
    if (arguments.length < 1 && typeof arguments[0] != "undefined") return this;
    var __method = this, args = [];
    for(var i=0;i<arguments.length;i++){ args.push(arguments[i]);}
 
    var object = args.shift();
    return function() {
      var args_to_apply = []
 
      for(var i=0;i<args.length;i++){ args_to_apply.push(args[i]);}
      for(var i=0;i<arguments.length;i++){ args_to_apply.push(arguments[i]);}
      return __method.apply(object, args_to_apply);
    }
};

For dojo devs => dojo.hitch(scope,cb_or_property_name); docs.dojocampus.org/dojo/hitch

var fn = this

Вы мой спаситель!