Отложенные вычисления в JavaScript

[Kolyaj]

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

И будет функция, обёрнутая в три функции, вместо одной.

В результате не надо помнить порядок аргументов

Но надо помнить, что defer должен быть последний А список аргументов IDE по Ctrl+P показывает.

и не надо пихать эти ctx, args во все остальные функции

Я раньше примерно так же рассуждал. Но в результате пришёл к варианту, когда рядом с callback-функцией всегда предаётся контекст его вызова. Гораздо меньше обёрток получается. Я из-за этого в NodeJS страдаю

onTimer.periodical(500)();

А остановить его как?

Я стараюсь не вводить сущности без особой необходимости. defer упрощает жизнь, periodical -- нет.

а что за паттерны?

Отсюда.

offtopic: код выглядит контрастно на фоне основного текста...

Ну так он же раскрашен, а текст -- нет
Ему может фон добавить, чтоб оттенял.

[tenshi]

var timerId;
element.onmouseover = function() {
    timerId = setTimeout(function() {
        alert(1);
    }, 2000);
};
element.onmouseout = function() {
    clearTimeout(timerId);
};

правильно так:

var timerId;
element.onmouseover = function() {
    if( timerId ) return
    timerId = setTimeout(function() {
        alert(1);
    }, 2000);
};
element.onmouseout = function() {
    timerId = clearTimeout(timerId);
};

или так:

var timerId;
element.onmouseover = function() {
    clearTimeout(timerId);
    timerId = setTimeout(function() {
        alert(1);
    }, 2000);
};
element.onmouseout = function() {
    clearTimeout(timerId);
};

[tenshi]

касательно периодических вызовов, я делаю так:

var clock= Clock().latency( 5000 ).proc( function(){ alert(1) } ).active( true )

полученный таймер мы можем произвольно включать/выключать, менять период и вызываемую функцию.

[x-yuri]

В общем разные у нас приоритеты, Kolyaj Я в первую очередь стараюсь убрать детали реализации, чтобы было видно что происходит, а не как это работает. А потом решаю проблемы с производительностью, если такие имеются. Потому что это упрощает мне жизнь. И поэтому количество оберток для меня не аргумент

Но надо помнить, что defer должен быть последний

не надо

Function.prototype.defer = function( timeout ){
    var f = this;
    return function(){
        var actualFunc = f.of(this);
        actualFunc = actualFunc.pass.apply(actualFunc, arguments);
        setTimeout( actualFunc, timeout );
    }
}

А список аргументов IDE по Ctrl+P показывает.

да, я помню один раз мне ide-подсказки помогли

А остановить его как?

например так

function onTimer(){
    ...
    onTimer.stopPeriodical();
}

Отсюда

а что ты хочешь: обобщить этот код до шаблона проектирования или показать пример использования setTimeout? Просто использование тобой слова "паттерн" вызывает неоднозначные эмоции

Ну так он же раскрашен, а текст -- нет
Ему может фон добавить, чтоб оттенял.

я бы просто css для кода пофиксил

[x-yuri]

и еще...

первое событие timer в любом случае "пропадает"

Array.prototype.deferForEach = function(delay, fn, finish, scope) {
    ...
                if (finish) {
                    finish.call(scope, this);
                }
    ...
    } else {
        finish.call(scope, this);   // finish вызывается, даже если не передан
    }
};

то что нельзя создать два таймера, смещенных по времени - это by design? Просто я не сразу это осознал, несмотря на то, что прочитал "Для каждого интервала создает лишь один экземпляр таймера."

Я стараюсь не вводить сущности без особой необходимости. defer упрощает жизнь, periodical -- нет.

так твой класс - это по сути periodical в виде класса

[with-love-from-siberia]

.defer можно было бы чуть-чуть переписать, чтобы можно было передавать аргументы не в массиве.

foo.defer(100, this, 1, 2);

вместо

foo.defer(100, this, [1, 2]);

[Kolyaj]

Я в первую очередь стараюсь убрать детали реализации, чтобы было видно что происходит, а не как это работает. А потом решаю проблемы с производительностью, если такие имеются.

Не, я тут с производительностью не борюсь. Я тут борюсь с внешними зависимостями. Минимальные внешние зависимости упрощают мне жизнь.

Вообще, я ж с тобой не спорю. Я раньше точно так же рассуждал, поэтому понимаю твои доводы. Я не говорю, что ты потом будешь рассуждать как-то по другому, просто для меня вариант максимальной абстракции оказался неподходящим. Я ввожу готовые функции, если это
1. Добавляет кроссбраузерности, как например, addEventListener/attachEvent.
2. Сильно упрощает жизнь, как например XMLHttpRequest.


Про Timer: основная его функция -- менеджить много таймеров. Т.е. если у тебя на странице будет несколько десятков независимых анимированных объектов, у каждого из которых свой setTimeout, всё будет слегка поттормаживать. А если сделать один setTimeout, который будет вызывать колбэки из каждого объекта, будет полегче.

так твой класс - это по сути periodical в виде класса

Так что нет


Ещё про тот файлик -- там deferForEach. Мне не нравится список аргументов, чтобы описывать его. Он перебирает элементы массива через заданные промежутки времени. Анимация им в две строчки делается.

.defer можно было бы чуть-чуть переписать, чтобы можно было передавать аргументы не в массиве.

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