а запрос зачем?

Можно. И даже стрелочки навигации.

как???

чтобы получить массив ссылок, которые в свойство ВыделенныеСтроки списка

а, это если ссылки есть в дин.списке

Рассчитываю на опыт на знания, чатик. Нуждаюсь в совете/рекомендации по рефакторингу.
Есть форма, некоего АРМ, с кучей дин.списков. При навигации по страницам, установке значений в разные поля, которые играют роль фильтров, выполняются тяжелые серверные вызовы, потому что в этих вызовах происходит изменение свойств элементов формы и некоторые запросы к БД.
Какие то обработчики оптимизировал и отправил на фоновое выполнение, но этого оказалось мало для обеспечения комфортной работы.
Замена дин.списков на таб.документы формируемые СКД сможет улучшить ситуацию?

а какие конкретно места тормозят? код? передача данных между клиентом и сервером? излишнее количество серверных вызовов?

В худшем случае готовься реализовывать свою пагинацию и отображение таблицы / списка на форме

Сейчас посмотрю по замеру производительности, чтобы прям точно сказать

Отправка данных с серверным контекстным методом.
1) Установили на клиенте какое то значение поля
2) Событие ПриИзменении вызывает серверный метод
3) Серверный метод устанавливает фильтры дин.списка
и вот между 2-3 замер производительности показывает просадки и в простом пользовательском режиме приходится ждать пока всё обновиться

Примерно вижу что можно упростить - кешировать что-то и устанавливать фильтры дин списка без явного вызова сервера.

может быть попробовать фильтры устанавливать на клиенте?

возврат с сервера на клиент вызывает ПриАктивизацииСтроки у всех текущих списков. тут тоже может быть просадка

Как раз сейчас займусь этим.
Но не теряю из головы и вариант с скд)

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

Зачем при изменении вызывает серверный метод?
Отборы можно установить на клиенте.
Возможно чтобы получить значения отборов выполняется большой запрос?
Или, к примеру, значения отборов являются огромным массивом данных и списку тяжело фильтровать по такому массиву.
В таком случае не нужно значения отборов передавать с сервера на клиент, нужно устанавливать их в той директиве, где они формируются

Если при вызове серверного метода с клиента вы меняет например заголовок любого элемента формы, то это жутко тормозит всю форму со списком, как будто список обновляется ещё несколько раз.

Тяжёлых запросов для получения значений отборов нет, есть 1 простой совсем, значение которого буду кешировать.
В рамках серверного вызова изменяется оформление элементов формы (заголовки, цвета)

Отключайте это.
Это 100% из за этого.
Если вы делаете это из обработчика Активизации, тем более отключайте.
Добавляйте изменяемые заголовки через реквизиты формы или меняйте их через обработчик ожидания.
Закомментируйте сейчас строки, где изменяются заголовки и другое у элементов при клиент-серверном вызове и проверьте гипотезу.

Будет у вас шок)))