All streams
Search
Write a publication
Pull to refresh
38
0
Зиновьев Антон @xobotyi

Full-stack developer

Send message
как вариант — сделать еще троттлинг, даже если сделать 100мс очень сильно сократится кол-во расчетов и обхода дерева элементов в случае скроллинга перетаскиванием ползунка скроллбара.
Вот прям щас сделал пункт 2 и делаю пункт 1 :D

+ повысил до 250 элементов, объединив getFromTop и getFromLeft в один метод, сократив кол-во обходов DOM в два раза, странно что я сразу до этого не допер, а только в момент написания статьи=)
Полноценные нагрузочные пока не проводил, но да, быстродействие на большом кол-ве отслеживаемых элементов — пока узкое место плагина.

Конкретнее, на 170-200 отслеживаемых эл-тах появляются просадки.

Буду работать в этом направлении, решение, скорее всего, заключается в минимизации количества хэндлеров события scroll
да нет, как раз offsetParent помог мне избавиться от parseInt( val, 10 )
Буду благодарен за багрепорты на гитхабе.
Категорически не понимаю чем вас не устраивает:
getFromTop: function() {
	var fromTop = 0;

	for( var obj = $( this ).get( 0 ); obj && !$( obj ).is( ':have-scroll' ); obj = obj.offsetParent ) {
		fromTop += obj.offsetTop;
	}

	return Math.round( fromTop );
}
который написан на чистом javascript, и использует приведенный Вами .offsetParent
Кстати об иерархичности селекторов, планирую доработать этот момент, вспомнил про иерархичность уже после написания статьи, когда спать ложился, пасибо что напомнил^_^
Интересно, в случае если часть эл-та над областью скроллинга и часть под действительно будет возвращаться outside.

Может возвращать что-то из серии «exceeds-vertically»? получится если включены allowMixedStates будет возвращаться exceeds-vertically exceeds-horizontally если блок во все стороны выходит за пределы области видимости
Стесняюсь спросить, но все же, ткните меня пожалуйста носом в функцию которая будет выдавать мне позицию элемента относительно ближайшего элемента имеющего скроллинг, с учетом того что это не обязательно окно браузера.
Во первых: у меня и так голый JS используется в том месте
Во вторых:
Начнем, пожалуй, с определения того, что же для данного контекста является областью видимости.
Для моей задачи, а писал я плагин, в первую очередь, для удовлетворения своих нужд, областью видимости является ближайший родитель, имеющий прокрутку.
.getBoundingClientRect() получает позицию элемента относительно окна браузера пользователя, что уже не подходит в случае если если область видимости у нас — не окно, а какой-либо другой блок ниже по дереву DOM.
Во всяком случае сейчас сравнил цифры возвращаемые моим методом и .getBoundingClientRect(), последний возвращает левак какой-то, и я не горю желанием выяснять почему, ибо есть уже работающий вариант функции.
Просто привел пост о котором знаю=)
как там сделано уже не помню.

а о быстрых решениях написал и я и норлин, сообщения норлина не видел, у него там развернутее
как вариант передавать в урле либо ?template=xxx, либо #template_name
если оны не заняты под другие нужды
Советую пост: http://habrahabr.ru/post/200662/
Аккурат роутинг в ангуляе
Меня прям умиляют эти минусёры…
Вот за что минус этому комменту?
Ну там часть для ноды.

А так, как я уже говорил — основной интерес в том, чтобы сделать самому. Хоть на текущий момент я уже и знаю по меньше мере 4-5 библиотек.
Совершенно верно.

Неоднозначность я имел в виду — по RFC 1738 это path, но я то имел в виду домен.
А если я укажу строку index.com, ресурса такого я не помню, но однако видя .com лично я воспринимаю ее как домен, а некоторые воспримут его как исполняемый windows файл.

Неоднозначность как раз в том, что нельзя выдернуть некий линк ( даже не полный, не являющийся линком по RFC ) из контекста и однозначно сказать домен это или путь.

Я то предполагал мочь обрабатывать всё.
Вполне осмысленное название… parameter1, parameter2 , я же не знаю что точно придет в parameter1.
— его может не прийти вовсе.
— а может прийти строка, тогда имело бы смысл назвать эту переменную value ( ибо если param1 указан, то это сеттер )
— а для метода params это был бы key ( читаем параметр с указанным ключом )
— а если пришла строка в param2, тогда param1 стоило бы назвать key, а param2value
— а если в param1 пришел хэш, то тогда param1 надо назвать hash
Как посоветуете быть в этом случае?

Что же касается Array.prototype.join то array.join склеивает весь массив с 1 сепаратором.
А у меня:
1) Не массив, а хэш, Т.е. объект, а не массив.( хотя вот если память не изменяет join и у хешей есть )
2) Мне надо склеивать значения с разными сепараторами.
Это, я бы сказал, неоднозначность.
Ибо hosthame имеет ровно ту же структуру, что и filename, например,, и достоверно по неполному/неправильному линку не всегда можно определить домен это или путь.

В текущем случае, ya.ru, по-правилам, является filename, т.е. относительной ссылкой на файл ya.ru лежащий в той же директории.
НО! я то например подразумевал домен, в данном случае.

как обрабатывать такие непонятки — пока не определился.
О_О убейте меня сразу… а если ошибся где-то в ней, или поправить чего-нибудь надо ( ._.)
Жаль плюсомета пока нету.
Простейший пример:
var link = document.createElement('a');
link.href = 'ya.ru';
return link.hostname;
// -> 

Information

Rating
Does not participate
Location
Budapest, Венгрия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Web Developer
Lead