Ну не знаю как довольно большому количеству комментаторов, но лично мне приятнее смотреть на девушек. Конечно, может быть, мои взгляды слишком архаичны для современного либерастичного общества :D
Строгая последовательность постов в фидах соц сетей, не имеет ровным счетом никакого значения.
Не понимаю, кому и в какой ситуации может быть важно, что вот этот пост был запощен на 1 секунду раньше чем другой.
Я не защищаю г+, хз как у них там организовано размещение карточек.
В конечном итоге, самым затратным по времени выполнения оказался метод определения позиции элемента.
Увеличил скорость работы плагина просто введя некий аналог кеширования значений на 1 секунду:
getRelativePosition: function( forceViewport ) {
var fromTop = 0;
var fromLeft = 0;
var $obj = null;
for( var obj = $( this ).get( 0 ); obj && !$( obj ).is( forceViewport ? forceViewport : ':have-scroll' ); obj = $( obj ).parent().get(0) ) {
$obj = $( obj );
if( typeof $obj.data( 'pos' ) == 'undefined' || new Date().getTime() - $obj.data( 'pos' )[1] > 1000 ){
/*
* Making some kind of a cache system, it takes a bit of memory but helps us veeery much, reducing calculation
* */
fromTop += obj.offsetTop;
fromLeft += obj.offsetLeft;
$obj.data( 'pos', [ [ obj.offsetTop, obj.offsetLeft ], new Date().getTime() ] );
} else{
fromTop += $obj.data( 'pos' )[0][0];
fromLeft += $obj.data( 'pos' )[0][1];
}
}
return { "top": Math.round( fromTop ), "left": Math.round( fromLeft ) };
}
1 — секунда это не так уж и мало чтобы в значительной степени снизить кол-во вычислений, в то же время это и не так много чтобы прозевать вероятные изменения в DOM.
По идее надо бы вообще вынести этот лимит в конфиг, т.к. по идее программист то знает когда и как часто меняется DOM
Так вот, перепроверил, в текущем виде иерархичность селекторов поддерживается более чем полностью, у меня закономерный вопрос: что вы понимаете под иерархичностью?
сам плагин — да, ток вот ему до кучи еще 5 других плагинов надо:
var MO = require('mutation-observer');
var evt = require('emmy');
var matches = require('matches-selector');
var getElements = require('tiny-element');
var intersects = require('intersects');
«Там» это в моем проекте=)
здесь же ситуевина немного другая, не позволяющая использовать такой подход, ибо он не подходит для отслеживания положения вне области видимости.
Так же можно добавить к плюсам jQuery.viewport:
— Более точное определение момента вхождения элемента в область видимости, по причине наличия у scrollspy троттлинга.
— Возможность работы в случае использования кастомного скроллбара.
Возможность отслеживать относительно местоположение элемента за пределами области видимости
Областью видимости может быть не только окно браузера
Более точный и кроссбразуерный вариант функции позиционирующей элемент относительно области вдимости
jQuery.viewport хуже:
В случае с scrollspy создается свое событите, с котором можно работать более широко и гибко нежели с моим вариантом трекера, взять тот же one( event, fn )
Более высокая производительность, в силу того, что у scrollspy много меньше расчетов по отслеживанию расчетов позиции элемента
В остальном, если брать мой плагин с настройками по-умолчанию, они вроде равны (при первом приближении к коду)
А, по количеству отслеживаемых… да честно говоря — фиг знает, но хочется иметь большой задел.
У меня в одном проекте, например, есть лента уведомлений, уведомление считается прочитанным если если оно попало в область видимости, за пределами области видимости может быть до 100 элементов, но как только элемент попадает в область видимости, производится нужная кухня и трэкер отвязывается, так что это не совсем тот пример.
Ссылку на проект дать не могу, да и честно говоря не хочу, в силу того что я пока не очень доволен своим детищем.
Не понимаю, кому и в какой ситуации может быть важно, что вот этот пост был запощен на 1 секунду раньше чем другой.
Я не защищаю г+, хз как у них там организовано размещение карточек.
Увеличил скорость работы плагина просто введя некий аналог кеширования значений на 1 секунду:
1 — секунда это не так уж и мало чтобы в значительной степени снизить кол-во вычислений, в то же время это и не так много чтобы прозевать вероятные изменения в DOM.
По идее надо бы вообще вынести этот лимит в конфиг, т.к. по идее программист то знает когда и как часто меняется DOM
З.ы. И все равно, даже это плагин работатет с viewport=window
З.ы.ы. и нечего тут минусами кидаться, кармы итак нету Т_Т
здесь же ситуевина немного другая, не позволяющая использовать такой подход, ибо он не подходит для отслеживания положения вне области видимости.
Плагин написал потому что хотел написать что-то более универсальное, что можно приложит вообще к чему угодно.
viewport != window— Более точное определение момента вхождения элемента в область видимости, по причине наличия у
scrollspyтроттлинга.— Возможность работы в случае использования кастомного скроллбара.
jQuery.viewport лучше:
jQuery.viewport хуже:
one( event, fn )scrollspyмного меньше расчетов по отслеживанию расчетов позиции элементаВ остальном, если брать мой плагин с настройками по-умолчанию, они вроде равны (при первом приближении к коду)
У меня в одном проекте, например, есть лента уведомлений, уведомление считается прочитанным если если оно попало в область видимости, за пределами области видимости может быть до 100 элементов, но как только элемент попадает в область видимости, производится нужная кухня и трэкер отвязывается, так что это не совсем тот пример.
Ссылку на проект дать не могу, да и честно говоря не хочу, в силу того что я пока не очень доволен своим детищем.
Но пока — я, пожалуй, буду копать в сторону оптимизации работы с набором отслеживаемых эл-тов, это на текущий момент очевидное узкое место плагина.
onScroll, не?во всяком случае, я когда проверял — все работало, и не помню чтобы
onScrollне вызывался этими кнопками.