не знаю что там у вас за книжка, которая предлагает примеры алгоритмов с квадратичной сложностью, но для реальных проектов так лучше не писать. делайте как-нибудь через сеты:
в языках с приличным ооп, миксины могут ограничить тип объекта к которому их можно подмешать.
в той же скале у миксина (трейта) есть self type. и если объект, не соответствует ему, миксын к нему подмешиваться не согласен. зато, имея эту гарантию, внутри он может свободно обращаться к методам этого типа у объекта, к которому подмешан. это вполне нормальный механизм, чтобы на уровне системы типов чётко указать чего миксину для работы надо.
не знаю, какой смысл имеет этот вопрос в контексте жабаскрипта, там и приватных полей-то нет.
1. народ правильно пишет про debounce - лишние запросы просто не надо отправлять.
2. при смене фильтра перед отправкой очередного запроса надо отменить предыдущий: https://developer.mozilla.org/en-US/docs/Web/API/X...
3. при желании, в ответе можно передавать обратно набор фильтров и не показывать ответ если фильтры не соответствуют текущему состоянию. это на тот редкий случай, когда запрос уже успел докачаться, но не успел обработаться когда юзер поставил галку. (хотя я не уверен насчёт поведения браузеров при отмене запроса - может они и обрабатывают такой случай, даже не представляю как это можно надёжно выяснить)
const arr = [].concat([1,23,23,21,1,23,41],[2,12,3,321,234,234,1,31,321,22,3],[12,32,53,1,3,12,3,2],[12,32,53,1,3,12,3,2]);
let set = new Set();
while(set.size < 6) set.add(arr[Math.random()*arr.length|0]);
[...set]
вы пытаетесь логику связать с повторяющейся разметкой. это фундаментально неправильный подход.
для такой задачи достаточно иметь разметку для одного вопроса с ответами без текста (шаблон), а текст всех вопросов и ответов иметь как данные в скрипте.
текст текущего вопроса и ответов на него выводить в нужные места разметки, при выборе ответа переходить к следующему.
то есть данные отдельно, отображение отдельно. а там и до mvc недалеко.
настроить хттп заголовки кэширования при отдаче содержимого страниц и спокойно запрашивать каждый раз. браузеры не вчера кэшировать научились, они это делают куда эффективнее чем вы руками. их нужно только правильно проинструктировать.
графики с большим количеством данных вообще трудно делать, при каком-то размере датасета любой подход перестаёт работать.
конкретно насчёт скорости простой отрисовки, главное - не перекрашивать одни и те же пикселы много раз. если у вас, конечно, не 30 тысяч пикселов в ширину график, то на одну колонку пикселов у вас рисуется много отсчётов. поэтому можно отобрать данные, которые попадают в эту группу, взять из них минимум и максимум (если диапазон не касается прошлого - растянуть до его границы) и отрисовать одной линией.
битовые операции (и операции с подстроками) по-человечески не индексируются.
по булевым полям индес тоже низкоселективный, но если галочек в конкретном запросе сильно меньше чем галочек всего, то польза будет.
так что лучше разложить флажки по отдельным полям.
если всё плохо, и сгенерировать настоящий xlsx каким-нить POI на сервере никак нельзя, то можно по-колхозному сгенерировать html таблицу и отдать её файлом с ёкселевским расширением и Content-Type: application/vnd.ms-excel
ёксель будет ругаться, но откроет и даже какое-то оформление попытается воспроизвести, если оно инлайновыми стилями задано. ещё можно пытаться ёкселевские атрибуты ячейкам добавлять, подсмотрев их в том хтмл, который сам ёксель выгружает.
это, конечно, не полноценное решение, но зато тривиально реализуемое чисто на клиенте.