Как создать собственный модуль/плагин?

Question

[Анатолий Родин]

Приветствую.

Предыстория: работаю фронтендером в компании. Стаж еще не велик. Используем плагин jplist (не реклама) для отображения и фильтрации динамически приходящих данных на фронт. При большом кол-ве данных уперлись в производительность. Как ни пытались, как ни крутились - не вышло.
В общем, принято решение написать собственный плагин/модуль без jQuery и на ES6-7. Но т.к. опыта создания чего-то своего практически нет, то хотелось бы услышать от более опытных совета, куда мне копать или что почитать.

Comments

[gleendo]

разве в

в компании

нет

более опытных

?

[Сергей Горячев]

Ну, а если

в компании

нет

более опытных

фриланс вам в помощь.

[Анатолий Родин]

iamevg_: глупо задавать подобные вопросы. Это же очевидно.

[Анатолий Родин]

Сергей Горячев: спасибо за совет. Фриланс как самый последний вариант.

[gleendo]

Анатолий Родин: Глупо спрашивать кого то на стороне, когда в окружении есть более опытные. В компании всегда так, менее опытные советуются и набираются опыта от более опытных.
Если бы вы были соло, то тогда можно было бы спросить совета на этом или подобном этому сервисе.
А так вы в компании работаете. В команде должны быть люди, которые имеют опыт в разработке поболее вашего, у них то и стоит спрашивать в первую очередь, если вопрос не банальный.

[Анатолий Родин]

iamevg_: скажу Вам так, что на проекте я самый опытный, к сожалению. На проекте я и еще один человек. Есть параллельный проект, где есть ребята поопытнее. Общение с ними привело к использованию Vue, т.к. у них тоже нет опыта создания чего-то своего.
В итоге, решил еще дальше копнуть, чтобы услышать больше мнений и точно определиться с тем, куда копать и с чего начинать.

Answer 1

[Максим Тимофеев]

Не уверен, что при отсутствии опыта Вы сделаете более оптимальнее, даже без jquery. Хотя пробовать надо, для саморазвития обязательно. Просто не питайте иллюзий.
Я к чему - затея хорошая, но если есть проект и сроки - поищите аналоги без jquery на чистом js.
Кстати, может быть стоит принципиально иначе все делать? Возложить часть фильтрации на сервер, если работаете с большим объемом данных.

Comments

[Анатолий Родин]

Стаж еще не на том уровне, чтобы создавать какие-то свои решения наподобие своих библиотек или плагинов, но и на том, чтобы не использовать jQuery (перечитано много веб-страниц про его оптимизацию). То что мы используем сейчас, как раз и использует его как основу, поэтому городить что-то свое на его основе просто не целесообразно.

Затея хорошая и сроки не горят + уже есть наброски архитектуры (ядро + модули) + уже хочется перейти на ES6 (т.к. в планах перевести весь проект на него). Фильтрация на стороне сервера в нашей нынешней реализации будет занимать еще больше времени чем сейчас на фронте.

Поэтому нужна отправная точка, с которой нужно начать "взлетать". :)

Answer 2

[VoidVolker]

Судя по всему тут проблема не jquery и не в jplist, а в банальном большом количестве элементов на странице. Решается очень просто - невидимые элементы выкидываются из дома динамически, а остаются только видимые плюс/минус один экран для прокрутки. Таким образом можно рендерить десятки и сотни тысяч элементов без тормозов. А для фильтрации использовать максимально быстрые методы фильтрации (какой именно зависит от того, что именно фильтруется) в отдельном объекте/массиве/списке.

Comments

[Анатолий Родин]

Спасибо за ответ, но.... нет. Фильтрация происходит в плагине, кол-во элементов в DOM = тому кол-ву, которое задает пользователь (у нас их 15), остальное - это "пагинация".

Закачка в плагин за один раз до 1500 объектов, их фильтрация и сортировка, пагинация и отрисовка на страницу происходит достаточно быстро. А вот динамическое добавление данных и увеличение кол-ва фильтров как раз и вызывает "тормоза" страницы.

Плагин устроит таким образом, что мы в него закидываем не просто обычный объект с данными, а разметку (html), построенную шаблонизатором (в нашем случае JsRender) и он внутри себя парсит ее и создает элемент.

[VoidVolker]

Ого, тогда да, надо избавляться от этого плагина и делать все по нормальному. А парсить текст, затем строить объект, потом его перегонять в текст, который опять парсится, перегоняется в объект, который потом опять в текст и опять в объект... Конечно будет медленно. На JS фильтр с рендерингом результата в виде пары десятков элементов реализуется довольно просто и легко переваривает десятки тысяч элементов.

[Анатолий Родин]

VoidVolker: абсолютно с Вами согласен. Вот поэтому и создал этот вопрос тут. Буду дальше искать)

[newpy]

А вот динамическое добавление данных и увеличение кол-ва фильтров как раз и вызывает "тормоза" страницы.

ну логично же. Динамика работает с DOM. Каждая вставка/замена/операция с ним, вызывает перерисовку дерева DOM полностью. Не питайте иллюзий что вы сперва фильтруете, а потом все сразу в html "вставляете/заменяете". В таком случае вы пытаетесь действовать по принципу работы VirtualDOM, "изобрести" его. Но есть две проблемы - он уже существует, и вторая у вас он не VirtualDOM. Что мешает взять тот же Vue, там есть слой данных(модель), в которой вы можете все так же данные фильтровать, принимать, записывать, выполнять все необходимые операции с данными на фронте, при этом оставить заботу по отрисовке самому Vue. Таким образом вы избавляетесь и от легаси библиотек сразу нескольких. Вам не нужен будет шаблонизатор, вам не нужен будет рендерер. Вам теоретически даже не нужен будет jquery. Т.к. данные привязываются декларативно к элементам.
При этом Vue можно использовать как обычную библиотеку и не тянуть кучи зависимостей и внедрять ее на любом этапе, не переписывая весь фронтенд с нуля.