Проигрывать / рандомайзер работают не на весь список

[raxefron]

В запросе к сервису контакта параметр количества треков задан как: options.count = options.count || 300;

расчет индекса следующей песни nextTrackIndex = (currentTrackPlaylistIndex + 1 < playlist.length) ? currentTrackPlaylistIndex + 1 : 0; то есть не больше чем количество срендереных элементов ($$(".music p.song"))

в результате: даже если список песен контакта содержит больше чем 300 элементов то будут проигрываться только первые 300 (если не сделать скрола несколько раз для загрузки всего списка)

audio.get - возвращает количество треков пользователя в элементе count возможные решения:

1. поставить options.count = options.count || 6000;(ограничение апи)
2. использовать для расчета индекса следующей песни максимальное значение = count из audio.get вместо playlist.length, и подгружать при необходимости не подгруженые треки
3. вариация первого решения - загружать все треки по 300 пока не загрузятся все (если количество пользователя больше 6000)

зы При большом количестве треков возможно памяти сильно много будет использоватся для решения этого можно использовать виртуализацию на UI и заполнять playlist не с $$(".music p.song") а с респонса апи

[1999]

@raxefron ты моя совесть - все руки не доходят до этого "бага". Не понял, что ты имеешь в виду про виртуализацию.

[raxefron]

Сейчас в dom для каждой песни добавляется <p class="song" ...

при большом количестве элементов это "тяжело" для браузера по памяти и после определенного количества песен может начать подтупливать при скролинге для решения подобной проблемы используют "виртуализацю" (пример для select http://www.tricedesigns.com/2012/06/27/megalist-jquery-plugin/ ) - то есть список обьектов хранится отдельно (например в local storage или просто как массив) а для отображения отрисовывается только видимое количество элементов, а при операции скролинга происходит ребиндинг списка из хранилища на созданые UI элементы

Это "возможная" проблема который в данный момент - решение здесь описано так как при исправлении проблемы тикете придется затронуть кучу кода в том числе и этот список

зы у меня песен не так много потому вариант проскролить несколько раз в низ мне помогает :)

[1999]

Хм, я раньше не встречал такой техники, поэтому достаточно занятно. Единственное, что мне непонятно: вот у меня отрисованы 300 песен, а всего у меня их скажем 6К. Я листаю и на каждой N-290 песне подгружаются следующие 300 песен (я рассматриваю кейс, когда все песни уже загружены и находятся где-нибудь в памяти или БД). Разве при листании DOM-дерево не будет увеличиваться и проблема (если она есть) не будет становиться все актуальней? Или подход подразумевает чистку старых элементов, которые уже ушли из видимой области браузера?

[raxefron]

Этот подход развитие пэйджинга В DOM хранится только видимое количество элементов (при высоте приложения по умолчанию 15 штук) когда пользователь начинает скролить вниз - элементы не создаются и не удаляются - в них обновляются значения(например время и имя композиции ) Грубо говоря количество дом элементов расчитывается из формулы высота окна/ высота одного элемента+ элементы буфера для плавности а длинна скрола определяется как общее количество элементов* высоту одного элемента. Операция обновления элемента DOM выполняется быстрее чем добавление и удаление отсюда профит. Если в премере сверху в девтуле открыть список и после его скролить можно увидеть как это работает в живую

[1999]

когда пользователь начинает скролить вниз - элементы не создаются и не удаляются - в них обновляются значения

аа, вот откуда ноги растут. Прикольно. Подумаю. Что мне не нравится - нужно будет постоянно смотреть на позицию скролла и как-то обновлять содержимое. Но подход занятный