[PrimeNg, Angular4] Несколько DataTable в нескольких вложенных TabView со множеством фильтров и бади темплейтами тормозит — как победить?

Question

[Антон]

plnkr.co/edit/qX7o1CBaDtRuLVz7SlH9?p=preview здесь синтетический пример, все сильно упрощено (для каждого должны быть поля свои options, естественно они берутся из бэкенда, и для каждой таблицы должны быть свои данные), всего по две записи в каждой таблице, но даже здесь заметны тормоза и при первой отрисовке и при взаимодействии с элементами.

Пробовал задавать для TabView [lazy]="true" - страница зависала, так же пробовал обновить DataTable и задать [immutable]="true" - не принесло заметного результата.

UPD.: обновил версии ангуляра и праймнг - стало чуть быстрее, но все равно довольно весомая задержка.

Comments

[denismaster]

Мы в свое время боролись, но в итоге выбрали более легковесную right-angled.

[Антон]

denismaster: она уж совсем простая, ну и в такой куче табов и с таким количеством инпатов и дропдаунов она тоже начнет загибаться, мне кажется)

[denismaster]

Антон: вовсе нет) В ней есть сортировки, фильтрация и многое другое. Она работает быстро потому что отдает все это действие на откуп пользователю. Мы один раз написали на сервере реализацию, и забыли. В итоге библиотека сгенерировала запрос, получила данные(по сути массив), отобразила. Там простейший ngFor. Использовал ее на двух проектах, было около 5 вкладок с разными списками, никаких проблем.

[Николай]

Это какая-то жесть.
Ну т.е. у вас шаблон на 800 строк ангулярских директив.
Сделайте компонент, содержащий одну таблицу. Для табов используйте роутер, должно стать намного легче. Ну и вообще проблема явно в библиотеке, т.к. при таком количестве данных не должно быть 500 ms хэндлеров.

[Антон]

Николай: вот насчет табов и роутеров - мне уже посоветовали, но я не совсем понимаю, это получается на этой странице будет свой роутер? или использовать роутер приложения?

[Антон]

Николай: разбить на компоненты - не проблема, но на скорость работы это мне кажется не повлияет)

[rumsey]

А changeDetection: ChangeDetectionStrategy.OnPush пробывали выставлять?

[Николай]

Антон: ну только первичный рендер может ускорить, а дальше - да, вряд ли повлияет.
rumsey: разве для этого используемые внутри библиотеки не должны уметь поддерживать это?
p.s. добавил trackBy - всё стало быстрее в 2 раза, но всё равно всё очень плохо

[Антон]

Николай: у таблицы есть [immutable]="true" но заметного прироста я вроде не заметил... мне кажется, больше всего тормозит мультиселект

[rumsey]

Николай:
Нет. Но если использовать как сейчас, то прибавка в скорости реакции интерфейса заметна. А если разбить на компоненты и в них установить ChangeDetectionStrategy.OnPush, то по идеи должно еще быстрее быть.

[0X12eb]

Прежде чем задавать такие вопросы - изучите компонентный подход в разработке SPA!
Как уже говорили выше, вот пути для Вашего решения:
1. Компонент на таблицу куда будут приходить инпутом все необходимые опции
2. Роутинг на каждую вкладку (на внешние и на внутренние)
3. Если не лень - написать свою таблицу с one-way bindings (там где можно) и наименьшим количеством хандлеров

Даже только эти пункты позволят ускорить эту часть приложения на порядок!

[Антон]

0X12eb: каждая таблица в приложении - это компонент, просто для примера вставил их в один, но на скорости отклика это не отражается, с роутингом буду разбираться, а у таблицы есть свойство иммутабл - тормоза по большей части из-за дропдаунов и мультиселектов

Answer 1

[Роман]

Быстродействие приложения закладывается на этапе дизайна.
Конкретно в вашем случае UI выглядит жутко перегруженным. Технически можно добиться быстрой реализации, но, кажется это в целом не спасет ситуацию.

Comments

[Антон]

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