NOVA Grid — техническое задание

С-1. Найти запись в большом наборе. Оператор вводит фрагмент в поиск, получает сокращённый набор, уточняет условием по колонке, находит запись, раскрывает детали.

С-2. Групповое действие над выборкой. Инженер фильтрует набор по условию, выделяет все результаты (не перечисляя вручную), выполняет действие над всей выборкой — включая записи, которые физически не загружены в браузер.

С-3. Точечная правка. Инженер находит запись, переводит строку в режим редактирования, правит два-три поля, сохраняет. Соседние строки при этом не смещаются.

С-4. Настройка под себя. Оператор скрывает ненужные колонки, меняет ширины, закрепляет ключевую колонку слева. Настройки переживают перезагрузку страницы.

С-5. Долгий просмотр. Оператор прокручивает набор от начала к концу. Данные подгружаются по мере скролла. Ширины колонок за всё время не изменились ни разу.

С-6. Разбор инцидента. Оператор фильтрует по критическому статусу, раскрывает несколько строк одновременно, сравнивает их детали, копирует значения.

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

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

Архитектура не должна блокировать перечисленное, но в v1 этого нет.

Принцип. У каждой асинхронной операции есть видимое состояние. Индикатор соответствует области, которую операция затрагивает: операция над всей таблицей индицируется на уровне таблицы, над строкой — на строке, внутри всплывающего элемента — внутри него. Индикатор не блокирует работу с тем, что операции не касается, и не смещает разметку (НФТ-1): место под индикатор либо зарезервировано, либо он накладывается поверх.

Следствия для приёмки. П-5 (сценарии С-1…С-6 полностью с клавиатуры) проверяется по таблице ФТ-17.4. Автоматический аудит доступности (П-4) включает проверку, что все интерактивные элементы достижимы с клавиатуры и имеют видимый фокус.

Ни одно из перечисленных событий не должно изменять ширину колонок или вызывать горизонтальное смещение содержимого:

Следствие: ширины колонок не могут зависеть от содержимого ячеек ни в какой момент. Это ограничивает выбор техники разметки (§10) и делает невозможной автоширину по содержимому (ФТ-12.12).

Вертикальное смещение содержимого ниже раскрытой строки при раскрытии — ожидаемое поведение, не нарушение.

Бюджеты проверяются автоматически и блокируют сборку при нарушении.

«Совокупное смещение layout» разделено на горизонтальное (стабильность колонок) и вертикальное (стабильность высот распорок и кэша деталей). Последняя строка адресует сценарий С-5: таблица открыта весь рабочий день.

Позицию или курсор, размер порции, список правил сортировки, список условий фильтрации (обоих видов по ФТ-4.3), строку поиска, признак отмены запроса.

Порцию записей, признак наличия следующей порции, размер набора при текущих условиях фильтрации. Ответ разбит на страницы (курсорная или позиционная постраничность).

Вместе с первой порцией данных источник отдаёт сопутствующие сведения. Каждое из них компонент обязан уметь принять и отдельным запросом — источник вправе отдавать их асинхронно, и ожидание не блокирует показ данных (ФТ-4.7, ФТ-4.26).

Корневой элемент, идентификатор (для раздельного сохранения настроек), описание колонок, источник данных, способ получения устойчивого идентификатора записи.

Режим постраничности; схему фильтрации как запасной вариант на случай, если источник её не отдаёт (ФТ-4.6); состав действий строки и групповых действий; наличие и содержимое деталей; потолок высоты деталей и оценку высоты (§11, Р-4); режим редактирования; режим добавления; политику удаления; источник обновлений в реальном времени как точку расширения (§6.7); набор включённых возможностей; начальное состояние; политику сохранения настроек.

Идентификатор; заголовок; способ извлечения значения из записи; способ отрисовки значения; исходная, минимальная и максимальная ширина; выравнивание; моноширинный набор (meta.mono → data-mono), отдельно от выравнивания; участие в сортировке, изменении ширины, скрытии, закреплении, поиске; поле сортировки, если оно отличается от идентификатора колонки (ФТ-3.8); ссылку на фильтруемое поле, если колонка с ним связана (ФТ-4.2); способ редактирования либо его отсутствие.

Тип и операторы фильтра описанием колонки не задаются — они принадлежат схеме фильтрации (§6.4). Колонка лишь указывает, с каким полем она связана.

Если колонка ссылается на фильтруемое поле, а в полученной схеме этого поля нет, условие по нему обрабатывается как нераспознанное по ФТ-4.8: помечается, отключается, остаётся видимым для удаления. Молчаливое игнорирование связи колонка→поле недопустимо.

Идентификатор; человекочитаемую подпись; тип; допустимые операторы; для перечислений — источник значений (готовый список либо запрос к источнику данных); опционально — собственный способ ввода и формат значения (ФТ-4.28).

Для именованного условия: идентификатор; подпись; описание смысла; перечень параметров, если они есть.

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

Уведомления о: изменении состояния, изменении выборки, действии по строке, раскрытии, начале и завершении редактирования, ошибке.

Решение. Нативная табличная разметка (table / thead / tbody / th / td) с фиксированным табличным раскладом, при котором ширины колонок берутся из явной колоночной группы, а не из содержимого ячеек. Сеточная разметка на произвольных элементах отклонена.

Обоснование. * Фиксированный табличный раскладка делает НФТ-1 свойством браузера, а не дисциплины кода: ширина колонки не зависит от содержимого ни в один момент. Подгрузка данных, замена заполнителей, длинный текст (усекается), строка деталей на всю ширину — ничто не двигает колонки. * Структура таблицы даёт вспомогательным технологиям роли строк, заголовков и ячеек без ручной разметки ролей (НФТ-3.2). * Строка деталей на всю ширину выражается штатным объединением ячеек. * Единая колоночная группа — единственная точка записи ширин, к которой обращается изменение размера (Р-3).

Следствия (проверяемы). * С-1.1. Ни одно событие из таблицы НФТ-1 не меняет геометрию заголовков (тест П-2). * С-1.2. Роли строк и ячеек доступны вспомогательным технологиям без переопределения (аудит П-4).

Узкие экраны. Отдельного режима отображения нет. Применяются: горизонтальная прокрутка с закреплённой первой колонкой (ФТ-12.8) и адаптивное скрытие низкоприоритетных колонок по порогу ширины (ФТ-12.13…12.15). Скрытие управляется программно из наблюдателя за шириной области и пишет в тот же механизм видимости, что и пользовательская настройка, — двух источников правды о видимости колонки не существует. Перестроение в карточный вид отклонено: оно ломает НФТ-1, лишает фиксированный раскладку предмета и убирает роли таблицы из дерева доступности.

Решение (уточнено версией 1.5). Видимое окно строк реализуется двумя строками-распорками (сверху и снизу от пула отрисованных строк), высота которых равна суммарной высоте непоказанных строк соответствующей стороны. Числа для распорок и диапазон индексов отрисовки считает virtualizer.getVirtualItems()/getTotalSize() из @tanstack/virtual-core 3.17.7 в padding-режиме: верхняя распорка = items[0].start, нижняя = getTotalSize() - items[last].end, диапазон отрисовки = items[0].index … items[last].index. Абсолютное позиционирование строк по-прежнему отклонено как несовместимое с нативным табличным потоком (Р-1) — это дефолтный режим virtual-core, но не используемый здесь.

Обоснование пересмотра. virtual-core не диктует разметку — он только считает диапазон видимых индексов и офсеты по высоте контейнера, позиции скролла и (переменной, Р-4) высоте строки. Padding-режим — документированный паттерн использования библиотеки, буквально совпадающий с уже принятым приёмом распорок, и ничего не меняет в Р-1. Переход не вызван конфликтом с Р-1 (его нет) — это перенос ранее ручной, слабо покрытой тестами арифметики в общий протестированный движок. Пул переиспользуемых узлов и стратегия работы со строками с активным состоянием (Р-5) virtual-core не затрагивает — он не заводит и не переиспользует DOM-узлы.

Следствия. * С-2.1. Распорки не участвуют в чередовании фона, наведении и нумерации и невидимы для вспомогательных технологий. * С-2.2. Число строк в документе ограничено размером пула независимо от размера набора (НФТ-2, бюджет узлов DOM). * С-2.3. Полная высота полотна и, следовательно, размер полосы прокрутки известны с первого кадра из размера набора (ФТ-13.2). * С-2.4. У высоты распорок и диапазона отрисовки ровно один источник истины (virtualizer); параллельного ручного расчёта того же диапазона/офсетов в кодовой базе не существует.

Решение. Высота деталей измеряется по факту отрисовки и кэшируется по идентификатору записи. Опорные параметры: * ширина деталей — ширина видимой области, от ширин колонок не зависит; * оценка высоты — одна на инстанс, задаётся в конфигурации (число и состав полей деталей на этом этапе известны); * потолок высоты — высота трёх строк; сверх него детали прокручиваются внутри себя (ФТ-7.7).

Почему скачок прокрутки практически исключён. * Переменную высоту имеют только раскрытые строки; обычные фиксированы токеном высоты строки. * Раскрытие — всегда явное действие пользователя, никогда не побочный эффект прокрутки: в момент измерения строка уже в видимой области, прокрутка не корректируется. * Измеренная высота кэшируется по идентификатору записи; при повторном входе строки в окно высота известна точно — прокрутка мимо ранее раскрытой строки не дёргается. * Промах оценки ограничен сверху потолком (высота двух строк), поэтому «плыть» прокрутке не на что.

Инвалидация кэша высот: обновление данных строки, смена плотности, смена темы. Изменение ширин колонок кэш не инвалидирует — ширина деталей от них не зависит.

Следствия. * С-4.1. Вертикальный скачок при прокрутке мимо ранее раскрытой строки отсутствует (тест на нулевой сдвиг, П-2, расширенный на вертикаль). * С-4.2. Горизонтальное изменение ширины колонки не пересчитывает высоту деталей.

Решение. Пул переиспользуемых узлов обслуживает только строки-отображения. Строки, несущие живое состояние — редактируемая, раскрытые, сфокусированная, — исключаются из пула и отрисовываются выделенными узлами, привязанными к идентификатору записи. Узел вынесенной строки в пул не возвращается, пока состояние активно.

Уточнение (версия 1.5). Диапазон видимых индексов, из которого пул подбирает строки для показа, начиная с этой редакции — вывод @tanstack/virtual-core (Р-2), а не результат ручного расчёта. virtual-core не заводит и не переиспользует DOM-узлы, не знает ни о пуле, ни о строках с активным состоянием — reconciliation между диапазоном индексов и тем, какой записи какой узел (пул/выделенный) достаётся, остаётся кодом @nova/kit, как и раньше.

Редактируемая строка. Реализует ФТ-9.9. Любой перевод прокрутки или фокуса, при котором строка покинула бы видимую область целиком, откладывается до ответа в модальном диалоге; при отказе — не выполняется, при согласии — редактирование сбрасывается и действие выполняется. Как следствие редактируемая строка всегда остаётся в видимой области, а механизм её удержания вне окна не требуется.

Сфокусированная строка. При выходе из окна фокус переносится на контейнер таблицы, координата фокуса (запись, колонка) запоминается; при возврате строки в окно фокус восстанавливается на ту же ячейку (НФТ-3.5, ФТ-17.7).

Раскрытая строка. Переиспользованию не подлежит; при сворачивании вызывается очистка отрисовщика деталей (обработчики, наблюдатели), после чего узел возвращается в пул (НФТ-5.4).

Следствия. * С-5.1. Узел строки с активным состоянием не оказывается в пуле переиспользования (модульный тест). * С-5.2. Данные редактирования не теряются при попытке прокрутки (тест сценария по всем источникам из ФТ-9.9). * С-5.3. Свёрнутая строка не оставляет висящих обработчиков и наблюдателей (тест на утечки).

Решение. Интерактивные примитивы (меню, поповер, диалог, всплывающая подсказка, поля выбора, выбор даты, уведомления, переключатели) поставляются выделенной библиотекой ui-kit, построенной на zag.js. Таблица потребляет примитивы через неё, а не инстанцирует машины напрямую.

Правило жизненного цикла — ключевое для НФТ-2. Число живых машин не зависит от числа строк. Машина на строку при частичном рендере означала бы создание и уничтожение тысяч объектов в секунду при прокрутке. Поэтому: * элементы управления внутри строк-отображений, повторяющиеся на каждой строке (переключатель выбора), реализуются без машины на строку; их поведение и разметка доступности задаются напрямую; * разделяемые оверлейные примитивы (меню колонки, поповер фильтра, меню действий, всплывающая подсказка) существуют в одном экземпляре на таблицу и переносят точку привязки к активному элементу; * машины полей редактирования создаются только для строки в режиме редактирования и уничтожаются при выходе из него; * диалог подтверждения и уведомления — по одному экземпляру, создаются лениво.

Отличие от собственного macro-автомата таблицы (Р-6). Примитивы выше — то, что таблица потребляет из общей библиотеки готовых zag-машин. Отдельно от них таблица авторит одну собственную zag-машину для своих семи macro-режимов (Р-6) — готовой машины для этого набора состояний в zag.js нет. Оба вида подчиняются одному и тому же правилу «число живых машин не зависит от числа строк»: разделяемые примитивы — по одному экземпляру на таблицу, собственная macro-машина — тоже по одному экземпляру на инстанс.

Следствия. * С-7.1. Число живых машин примитивов и собственной macro-машины на инстанс не превышает малой константы независимо от размера набора (тест: снять счётчик машин при наборе в 100 000 записей). * С-7.2. Уничтожение инстанса освобождает все машины, обработчики и наблюдатели (тест на утечки, НФТ-5.4).

Разграничение. Zustand — хранилище приложения, в которое встраивается таблица, а не собственное хранилище компонента. Компонент на Zustand не завязан: приложение-потребитель может использовать любой стор, и таблица обязана в него встраиваться (НФТ-5.3, НФТ-5.1). Поэтому состояние делится на два слоя.

Внутреннее состояние инстанса. Инстанс владеет своим состоянием сам, не завися от внешнего стора, но с версии 1.5 — через два хранилища, а не одно. @tanstack/table-core (см. ниже) владеет табличной моделью: сортировка, условия фильтрации уровня колонки, настройки колонок (ширины, порядок, видимость, закрепление). Собственное лёгкое реактивное ядро компонента, как и раньше, владеет остальным: выбор, раскрытие, окно кэша и его метаданные (размер набора, статусы загрузки), состояние подсистем-автоматов (ниже). Подписка на срезы обоих хранилищ даёт точечную перерисовку (НФТ-2); несколько инстансов на странице не делят состояние (НФТ-5.1); уничтожение инстанса освобождает состояние в обоих хранилищах (НФТ-5.4).

Связь с хранилищем приложения. Компонент публикует своё состояние и события через API (§7.5: чтение и запись состояния, подписка, события). Приложение связывает нужные срезы состояния инстанса со своим Zustand — двусторонним адаптером поверх этого API, а не прямым доступом к внутренностям. Адаптер — тонкий слой на стороне приложения либо опциональный пакет-мост; в ядре компонента зависимости от Zustand нет. Источник истины по внутреннему состоянию — инстанс; приложение зеркалирует и управляет им через публичный контракт.

Граница с движком табличной модели (пересмотрено версией 1.5). Прежний вывод этого раздела — «отдельный headless-движок табличной модели не требуется» — снимается для модели данных и подтверждается для режимов (FSM). @tanstack/table-core 9.1.2 владеет ColumnDef<Row>[], SortingState, ColumnFiltersState (только для фильтров уровня колонки, не для именованных условий — граница описана в NOVA-Grid-Architecture.md §7), видимостью/порядком/закреплением/шириной колонок и row model, сконфигурированной в manual/server-side режиме: getCoreRowModel() без клиентской сортировки/фильтрации/пагинации (manualSorting, manualFiltering, manualPagination: true) — реальные сортировка, фильтрация и постраничная загрузка остаются на сервере через DataSource (К-1 не нарушается). table-core не имеет понятия FSM и не затрагивает семь macro-режимов ниже — переходы режимов по-прежнему целиком покрывает zag-машина. Пример границы: изменение SortingState вызывает onSortingChange table-core → это триггерит переход подсистемы «применение фильтра/сортировки/поиска» (settled → applying, отмена незавершённых запросов, ФТ-13.6, сама таблица переходов не меняется) → адаптер (NOVA-Grid-Architecture.md §7) строит запрос страницы данных из состояния table-core → ответ переводит подсистему applying → settled. Технической структуре пакета (размещение файлов, порядок инициализации, форма точек расширения для отключаемых возможностей, НФТ-5.2) это не мешает — она по-прежнему решается на этапе архитектурного проектирования. Риск конкурирующих хранилищ снимается тем же способом, что и раньше: единственный источник истины на каждый срез состояния — либо table-core, либо реактивное ядро, никогда оба сразу.

Подсистемы-автоматы (FSM). Часть внутреннего состояния имеет форму конечного автомата — набор режимов с запрещёнными переходами. Начиная с версии 1.4 эти автоматы авторятся как обычные zag-машины (@zag-js/core createMachine) и исполняются через тот же VanillaMachine/PartResolver из packages/core, которым пользуются остальные компоненты кита (menu, combobox, tree-view, date-picker, dialog, splitter) — тот же connect()/normalizeProps-контракт и детерминированный id (см. Р-8). Готовой машины для таблиц в самом zag.js нет, поэтому машина для этих семи режимов авторится в этом пакете как собственная, а не берётся из официального набора @zag-js/* — в отличие от разделяемых оверлейных примитивов Р-7.

Экземпляр этой машины — один на инстанс таблицы, независимо от размера набора и числа отрисованных строк: правило Р-7 «число живых машин не зависит от числа строк» распространяется и на неё. Разметка и интерактивность строк/ячеек (Р-1, Р-2, Р-5) по-прежнему не управляются частями ([data-part]) этой или любой другой машины и остаются нативной table-разметкой с пулом узлов — это не смягчается, поскольку продиктовано бюджетом НФТ-2 (≤2000 DOM-узлов, ≤8 мс кадр при прокрутке на 100 000 записей), который машина на строку или на ячейку нарушила бы так же, как нарушила бы у tree-view или listbox-части combobox в этом же ките.

Правило: автомат — для режимов, обычное значение — для данных. Сортировка, фильтры, ширины и т.п. — значения, не состояния автомата; с версии 1.5 эти значения физически живут в @tanstack/table-core, а не в реактивном ядре (см. выше). Автоматами моделируются:

Остальные подсистемы (позиция прокрутки, содержимое кэша, наборы значений фильтров) автоматами не являются и живут как данные.

Следствия. * С-6.1. В ядре компонента нет зависимости от Zustand (хотя есть зависимость от @zag-js/core/packages/core и, с версии 1.5, от @tanstack/table-core, как у остальных компонентов кита с их зависимостями от @zag-js/*); таблица встраивается в приложение с произвольным стором через публичный API (тест: инстанс работает без Zustand в окружении). * С-6.2. Состояние инстанса не пересекается с состоянием других инстансов (тест: два инстанса, изменение в одном не влияет на другой). * С-6.3. Изменение среза состояния не вызывает перерисовку не подписанных на него участков (тест счётчиков перерисовки). * С-6.4. Каждый автомат из перечня проверяется изолированно, без DOM: допустимые переходы проходят, недопустимые отклоняются, недопустимые состояния непредставимы (модульные тесты переходов). * С-6.5. Двусторонний адаптер синхронизирует срез состояния инстанса с внешним стором в обе стороны без расхождения (тест round-trip через публичный API). * С-6.6. Число живых экземпляров macro-машины равно числу инстансов таблицы на странице и не растёт с размером набора или числом отрисованных строк (тест: снять счётчик машин при наборе в 100 000 записей, ср. С-7.1). * С-6.7. Состояние table-core проходит через тот же публичный API (§7.5), что и остальное внутреннее состояние: снаружи нет разницы между чтением/записью сортировки и чтением/записью выбора или раскрытия (тест round-trip через публичный API, ср. С-6.5).

Решение. NOVAGrid — не custom element и не отдельный рантайм: light DOM компонент на общем базовом классе packages/core (VanillaMachine + PartResolver), как и остальные компоненты кита. Стилевой контракт — тот же, что у всех: атрибуты [data-scope="grid"] / [data-part="…​"] / [data-state="…​"], @scope с корнем на содержательный узел и пределом to ([data-nova-slot]), слой nova.components. Собственных классов на частях компонент не заводит.

Обоснование. Форма компонента оставалась открытой, пока не было решено, авторится ли macro-автомат (Р-6) как zag-машина. После этого решения вопрос снимается естественным образом: раз ядро компонента — обычный потребитель packages/core, как menu/combobox/tree-view/date-picker/dialog/splitter, у него нет причин иметь другую форму компонента или другой стилевой контракт, чем у соседей по киту. Ранее написанный table.css со скоупом на классе .nova-table переносится в grid.css со скоупом [data-scope="grid"] на этапе реализации.

Следствия. * С-8.1. Стили таблицы проходят тот же Definition of Done, что и остальные компоненты кита: слой nova.components, @scope на содержательном узле, отсутствие собственных классов на частях. * С-8.2. Таблица не инлайнит значения цветов/размеров и не заводит собственные CSS-переменные с именами дизайн-системы (НФТ-4.5).

Решение. Тема и плотность выражены дизайн-токенами в CSS custom properties. Смена темы или плотности — это смена значений переменных на предке (переключение атрибута/класса), после чего внешний вид меняется силами каскада, без перестроения разметки и без пересоздания компонента (НФТ-4.2). Единственный источник истины из CSS.

Что остаётся на компоненте. Смена плотности меняет высоту строки (НФТ-4.3). Само значение приходит из переменной, но расчёты, зависящие от высоты, живут в JS (виртуализатор, Р-2/Р-4). Поэтому компонент наблюдает за сменой темы/плотности и, при ней: перечитывает высоту строки и высоту заголовка из вычисленных стилей, пересчитывает виртуализатор, сбрасывает кэш измеренных высот деталей (Р-4), пересчитывает смещения закреплённых колонок. Пользовательские ширины колонок при этом не сбрасываются (НФТ-4.4).

Следствия. * С-9.1. Смена темы не меняет геометрию (тест на нулевой сдвиг заголовков до/после, П-2). * С-9.2. Смена плотности сохраняет прокрутку, выбор, раскрытие и незавершённое редактирование (тест сценария), а пользовательские ширины остаются (НФТ-4.4). * С-9.3. Компонент не задаёт цвета и размеры напрямую — только через токены (аудит: отсутствие захардкоженных значений, НФТ-4.5).

Решение. Разделяемая часть состояния (условия фильтрации, поиск, сортировка, настройки колонок — состав по ФТ-4.21) сериализуется в адрес страницы, чтобы состоянием можно было поделиться ссылкой (ФТ-15.2). Именованный сохранённый набор транслируется в тот же адрес. Долговременное хранение наборов — на стороне источника (сервере); локальное хранилище — запасной вариант, когда источник наборы не хранит (К-11).

Разбор двух путей. * По ссылке (URL). Несёт применённое состояние целиком либо ссылку на именованный набор. Открытие такой ссылки другим пользователем воспроизводит тот же вид, если у него есть доступ к набору (право проверяет источник, Р-8/К-8). * На сервере. Именованные наборы и, при поддержке, персональные настройки колонок. Переживают смену устройства и браузера.

Совместимость. Формат сериализации версионируется; несовместимое состояние из адреса или хранилища отбрасывается без ошибки (ФТ-15.4). Настройки для колонок, которых больше нет в конфигурации, отбрасываются молча (ФТ-15.3).

Сериализация условий обоих видов (поглощает Р-12). Единый набор содержит условия двух видов — по полю (поле, оператор, значение) и именованные (идентификатор, параметры). Оба кодируются одной версионируемой формой в составе этого же URL/хранилища, без отдельного механизма. Нераспознанный вид или поле при разборе отключается видимо (ФТ-4.8, ФТ-4.27), а не роняет разбор. Отдельного решения Р-12 не требуется — форма определяется здесь.

Следствия. * С-10.1. Ссылка с сериализованным состоянием, открытая заново, воспроизводит тот же набор, сортировку и настройки колонок (тест round-trip). * С-10.2. Устаревший или повреждённый формат в адресе не роняет компонент (тест деградации).

Решение. Значение ширины колонки применяется через единую точку записи, предопределённую разметкой (колоночная группа, Р-1): изменение размера пишет ширину туда, без чтения геометрии из JS — этим держится бюджет кадра при перетаскивании (НФТ-2) и стабильность разметки (НФТ-1).

Источник исходной ширины — по приоритету, сверху вниз:

Пользовательское изменение ширины всегда перекрывает и backend, и конфигурацию и сохраняется (ФТ-15.1). «Сбросить ширину» (ФТ-12.3) возвращает к ширине уровня 2, если она есть, иначе — уровня 3. Минимум и максимум (ФТ-12.2) из конфигурации применяются к значению из любого источника. Смена плотности пользовательские ширины не трогает (НФТ-4.4).

Следствия. * С-3.1. Ширина, пришедшая с backend, применяется при отсутствии пользовательской настройки и перекрывается ею после ручного изменения (тест приоритетов). * С-3.2. Перетаскивание границы не вызывает чтения геометрии из JS и укладывается в бюджет кадра (НФТ-2, тест).