Каркас приложения: как связать панели, навигацию и состояние

Каркас приложения — это общий слой интерфейса, который удерживает навигацию, панели и состояние в одной модели. В английской терминологии его часто называют application shell. Для адаптивного интерфейса это важно: разные экраны могут показывать разные области, но пользователь должен оставаться в том же сценарии.

Дальше держим в голове пример CRM или админки: слева разделы и фильтры, в центре список клиентов или задач, справа карточка объекта и дополнительные действия. Каркас описывает, какие из этих областей видны рядом, какие открываются следующим шагом и что нельзя сбросить при смене ширины.

Базовую модель см. в статье про адаптивный интерфейс, а правила поведения при изменении размера — в материале про resize и сохранение состояния.

Почему каркас приложения — это не один layout-компонент

В коде может быть компонент с названием Shell, AppLayout или MainLayout, но архитектурный смысл шире. Каркас приложения определяет устойчивую часть продукта: где живёт навигация, как выбирается layout state, какие панели существуют, как хранится состояние и какие переходы считаются допустимыми. Один визуальный компонент не закрывает эти вопросы сам по себе.

Если shell свести к компоненту-обёртке, логика быстро расползается: часть правил оказывается в роутере, часть в таблице, часть в форме, часть в локальном состоянии панели. Тогда каждый экран начинает по-своему реагировать на resize и back. Контракт нужен, чтобы разные разделы приложения использовали одну модель поведения.

Постоянные области и временные слои

В CRM или админке часть интерфейса образует постоянную рабочую поверхность: навигация, список, карточка объекта, вспомогательные панели и inspector. Эти области могут быть видны рядом или переходить в следующий уровень, но они остаются частью основной задачи пользователя.

Отдельно нужно описывать временные слои действия: sheet, modal, preview, action panel. Они помогают создать запись, подтвердить действие, посмотреть вложение или изменить настройку, но не должны ломать основной маршрут. После закрытия такого слоя пользователь должен вернуться к тому же объекту, списку, фильтру и месту работы.

Практическое правило для shell contract: постоянные области отвечают за структуру приложения, временные слои — за короткое действие поверх текущего контекста. Если временный слой начинает заменять detail или сбрасывает навигацию, его роль описана неправильно.

Граница между routing и shell

URL и routing важны, но они не обязаны хранить всю механику интерфейса. URL хорошо фиксирует адресуемое состояние: раздел, выбранный объект, иногда вкладку или фильтр. Shell отвечает за представление этого состояния: рядом ли виден список, открыта ли supporting pane, можно ли показать inspector, что произойдёт при back.

Практическое правило: если состояние нужно отправить ссылкой другому пользователю, оно вероятно относится к routing или content state. Если состояние описывает текущую рабочую поверхность, ширину панелей или временный слой, оно относится к shell state. Граница может отличаться в разных продуктах, но она должна быть явно описана.

Что нужно зафиксировать в каркасе

Shell state и content state

Shell state описывает поверхность: какие панели открыты, какой layout state активен, какая область в фокусе. Content state описывает данные внутри сценария: выбранный объект, заполненную форму, фильтр, сортировку, scroll position. Эти два слоя нельзя смешивать. Если layout хранится внутри карточки объекта, resize начинает менять бизнес-состояние. Если выбранный объект хранится только внутри панели, он может пропасть при скрытии панели.

Контракт для команды

Application shell contract полезен только тогда, когда он становится общим языком команды. Дизайнер проектирует состояния, разработчик реализует их как модель, тестировщик проверяет сценарии, а аналитик фиксирует ограничения в требованиях. Поэтому contract лучше описывать не только в коде, но и в проектной документации: роли панелей, таблицу состояний, правила back и список сохраняемых данных.

Для design system это тоже важно. Компоненты navigation rail, sidebar, split pane или inspector должны иметь не только визуальные варианты, но и условия применения. Иначе один продукт использует inspector как форму редактирования, другой — как диагностическую панель, а третий — как обычный detail, и пользователи получают разные правила в похожих сценариях.

Visibility rules

Visibility rules заранее отвечают на вопрос, что происходит с панелью, когда места стало меньше. Панель может остаться рядом, перейти в navigation stack, стать временным sheet или закрыться. Но это решение должно зависеть от роли панели, а не от случайного breakpoint.

• Главный контент не исчезает без явного перехода.
• Supporting pane можно скрыть, если его контекст можно восстановить.
• Inspector закрывается безопаснее, если изменения сохранены или подтверждены.
• Временный слой закрывается раньше, чем меняется основной экран.

Ошибки в application shell

Смешать shell state и данные. При скрытии панели пропадает выбранный объект или черновик формы.

Спрятать правила в breakpoint. Команда знает ширину, но не знает, почему исчезла именно эта панель.

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

Дублировать поведение на каждом экране. Разделы приложения начинают по-разному реагировать на один и тот же resize.

Связь с design system

Design system задаёт визуальные компоненты, но application shell задаёт правила их совместной жизни. Компонент sidebar сам по себе не решает, когда он превращается в compact navigation. Split pane не решает, какая колонка главная. Эти решения должны быть частью shell contract и использоваться повторно в продуктах команды.

Как внедрять постепенно

Если приложение уже существует, не обязательно переписывать shell целиком. Начать можно с одного повторяемого сценария: список и карточка объекта, таблица и форма, workspace и inspector. Сначала фиксируются текущие проблемы, затем описывается целевое поведение для трёх layout states, после этого команда переносит правила в общий shell-модуль или библиотеку компонентов.

Постепенный подход снижает риск: старые экраны продолжают работать, а новые получают единый контракт. Когда паттерн стабилизируется, его можно распространить на соседние разделы и включить в design system как рекомендуемую модель.

Пример contract-фрагмента

Как описывать contract в документации

Контракт application shell лучше фиксировать в короткой, проверяемой форме. Для каждого layout state указывается набор видимых панелей, primary area, secondary area, temporary layers, правила открытия и закрытия. Для каждой панели фиксируется роль, зависимость от выбранного объекта, допустимое скрытие и состояние, которое нужно восстановить.

Отдельно стоит описать события: resize, смена раздела, выбор объекта, открытие временного слоя, сохранение формы, отмена действия и back. Для каждого события нужно указать, меняется ли routing, меняется ли shell state, меняется ли content state и какие side effects запрещены. Такая таблица полезнее длинного описания, потому что превращается в checklist для разработки и QA.

Acceptance criteria

• Shell state отделён от content state.
• Для каждой панели есть роль и приоритет.
• Правила visibility описаны до реализации.
• Back behavior одинаково понятен на compact и expanded.
• Resize не сбрасывает выбранный объект, черновик и фильтры.
• Компоненты design system используют один и тот же contract.

Когда contract можно считать стабильным

Contract стабилен, если новый раздел приложения можно подключить к нему без изобретения отдельных правил. Команда должна понимать, какую роль играет каждая новая панель, где хранится её состояние и как она ведёт себя в compact, medium и expanded состояниях. Если для каждого раздела приходится заново объяснять back и resize, contract ещё не стал общим.

• Адаптивный интерфейс: как проектировать приложение под разные экраны
• Многопанельный интерфейс: когда показывать список и детали рядом
• Поведение адаптивного интерфейса при изменении размера экрана