Документация
Цели и принципы проектирования
Native Shell предоставляет нативные представления и взаимодействие на iOS, Android, macOS, Windows, Linux и в вебе. Визуальный дизайн остаётся за приложением. Одна модель компонентов подходит для целых приложений, встраиваемых функций и динамически доставляемого UI.
#Нативный фундамент, дизайн во власти приложения
NSH опирается на представления, текст и инфраструктуру ввода каждой платформы и адаптирует взаимодействие под устройство: навигацию с клавиатуры, ввод указателем и касаниями, редактирование текста, прокрутку и доступность (Введение).
Приложение определяет цвета, типографику, отступы, формы, обратную связь состояний и анимацию. Экран настроек может следовать бренду приложения на iOS и Android, а ввод и навигация при этом соответствуют соглашениям каждого устройства. Дизайнеры развивают этот визуальный язык через стили и части компонентов.
Нативное представление — основа отрисовки. Системный стиль элемента управления — лишь один из вариантов внешнего вида и поведения. Общие элементы управления NSH предоставляют единое поведение и настраиваемые части, чтобы приложения могли строить собственные дизайн-системы.
#Нативная интеграция на практике
Нативный фундамент включает отрисовку, анимацию по кадрам, ввод и семантику доступности. На iOS и Android Input использует платформенные текстовые поля: платформа берёт на себя редактирование, меню выделения, методы ввода и поддерживаемые службы автозаполнения. Приложение описывает поле через autoComplete, например current-password или postal-code, а система предлагает доступные подсказки в соответствии со своими настройками и службами (Формы и клавиатура). Стилизация поля не мешает сохранить эту системную интеграцию.
Это архитектурное отличие от отрисовки текстового поля целиком внутри собственного рендерера: собственный рендерер должен сам обеспечивать интеграцию с системным редактированием и службами доступности, тогда как NSH использует платформенные текстовые элементы там, где их предоставляет бэкенд. Интеграция каждого бэкенда описана в его документации, включая собственный редактор NSH на Windows и бэкенд встраивания GPUI (Платформы).
Разделение поведения компонентов и визуального дизайна в GPUI Kit повлияло на слои NSH. NSH развивает этот принцип, опираясь на инфраструктуру представлений и ввода платформ. Нативная интеграция и дизайн, принадлежащий приложению, работают вместе на протяжении всей этой модели.
#Одна модель компонентов на всех платформах
Переключатель означает одно и то же на телефоне, на десктопе и в вебе. nsh/base обеспечивает состояние, обработку ввода, фокус и доступность; приложение стилизует дорожку, бегунок и состояния Switch. Кнопки, флажки и радиокнопки следуют тому же принципу.
| Ответственность | Где находится | Пример |
|---|---|---|
| Отрисовка, раскладка, реактивность и окружение | nsh-core, nsh и модули рантайма | Представления, текст, сигналы, стили |
| Общее поведение и доступная структура | nsh-base, в TSX импортируется как nsh/base | Button, Checkbox, Switch, Tabs |
| Визуальный дизайн и стилизованные компоненты | Приложение или библиотека сообщества | Брендированные элементы управления, карточки, строки форм |
| Платформенно-специфичные возможности | nsh/mobile, nsh/desktop | Панель навигации на мобильных, элементы управления окном на десктопе |
У общих элементов управления есть единый кроссплатформенный дом в nsh/base. Платформенные модули ограничены назначением и семантикой платформы. TabBar обслуживает навигацию верхнего уровня на мобильных; Tabs переключает содержимое вкладок на всех платформах. Их роли различны. nsh/mobile принимает возможности с мобильно-специфичной семантикой взаимодействия; различия во внешнем виде, размере, оттенке или анимации общего элемента управления относятся к его общему компоненту и стилизации приложения. Уведомление или тост с общей ролью следует сначала проектировать вокруг одного кроссплатформенного контракта, а представление адаптировать внутри.
Общий компонент может адаптировать взаимодействие внутри: меню открывается как всплывающее окно на десктопе и как sheet на телефоне, при этом приложение использует один API и задаёт внешний вид. Системно управляемые представления, такие как заголовки навигации и алерты, следуют документированным правилам представления платформы. Приложения могут предоставлять собственные нативные компоненты и службы через интерфейсы встраивания.
#Нестилизованный фундамент и слой библиотеки компонентов
NSH владеет примитивами и нестилизованным фундаментом (nsh-core и nsh-base). Приложения и сторонние библиотеки владеют слоем стилизованной библиотеки компонентов — той ролью, которую gpui-component играет в GPUI Kit. Такое разделение даёт каждому продукту контроль над собственным визуальным языком и позволяет переиспользовать самые сложные части реализации компонентов.
Опыт, стоящий за этим выбором, пришёл из GPUI Kit. Его стилизованные компоненты выросли из работы над Longbridge Pro. По мере того как приложениям требовались всё более разные дизайны, давление кастомизации вынуждало пользователей форкать компоненты. Выделение общего фундамента в gpui-base сделало поведение переиспользуемым во всех этих дизайнах. Стилизованные компоненты остаются полезными как дизайн-референс и для приложений, потребности которых укладываются в их поверхность кастомизации; фундамент даёт остальным приложениям прямой контроль над представлением.
NSH применяет этот урок с самого начала. nsh/base владеет сложным поведением, взаимодействием, реактивным состоянием, фокусом, доступностью и адаптивным представлением, а тесты находятся на том слое, который отвечает за каждое поведение. Сюда входят и более крупные структуры, такие как Dock. Приложения строят разнообразные дизайны на этом фундаменте через стили, состояния, слоты и части. Вклад в компоненты следует той же границе: визуальные значения по умолчанию и брендированные варианты принадлежат компонентам приложения или сторонних авторов. Документированные системно управляемые представления и значения по умолчанию для чтения TextView сохраняют свои специфические контракты (Архитектура).
#Что демонстрирует Gallery
Демо на сайте и Gallery — это стилизованные примеры приложений. Их градиенты, тени, скруглённые углы, переходы и движение показывают возможности кастомизации NSH и служат примерами исходного кода. Эти решения относятся к демо и Gallery; переиспользуемые базовые компоненты предоставляют лежащие под ними поведение и части. Приложения могут позаимствовать примеры или построить другой визуальный язык.
Независимо распространяемая стилизованная библиотека относилась бы к слою приложений и сообщества, описанному выше. Стилизация Gallery иллюстрирует одно из направлений дизайна; пригодность его для конкретного продукта — дизайнерское решение этого продукта.
#Rust и TSX на одном движке
Приложения на Rust, экраны на TSX и смешанные проекты используют общие примитивы, базовые компоненты, сигналы и раскладку. Rust обеспечивает скомпилированную логику приложения и переиспользуемые нативные компоненты. TSX поддерживает быстрые итерации и модули, доставляемые во время выполнения (Сборка на Rust).
Движок обновляет привязки, зависящие от изменённых сигналов, и группирует операции над представлениями. Раскладка текста, нативные анимации и ввод принадлежат движку и его платформенным бэкендам (Архитектура). Производительность оценивается на воспроизводимых рабочих нагрузках приложений (Производительность).
#Встраивание, динамическая доставка и ИИ
Существующее нативное приложение размещает представление NSH там, где должна находиться функция, и предоставляет собственные нативные компоненты и службы хоста. Автономные приложения используют тот же рантайм и ту же модель компонентов (Платформы).
Динамически доставляемые модули TSX владеют своим состоянием, логикой и раскладкой. Подписанные пакеты определяют, каким издателям хост доверяет; ограничения песочницы и возможности определяют, что модулям разрешено делать. И доверие, и разрешения выбирает хост (Подписанные пакеты, Песочница и возможности).
UI, сгенерированный ИИ, следует этому контракту: генерировать TSX по объявленным API, проверить и протестировать его, собрать и подписать модуль, затем верифицировать и запустить по политике хоста. Сгенерированные объявления, документация, читаемая моделями, и тесты через CLI делают этот процесс прозрачным и воспроизводимым (Тестирование и трассировка).
#Как эти цели направляют добавление нового
- Определите пользовательское поведение и является ли оно общим для платформ.
- Размещайте общее поведение в существующем примитиве или базовом компоненте, открывая состояние и части для кастомизации приложением.
- Размещайте возможности с платформенно-специфичной семантикой в их платформенном модуле, документируя применимость и сочетание с общим UI.
- Стилизованные компоненты создавайте в приложении или библиотеке сообщества.
- Проверяйте поведение, доступность, раскладку и ввод на затронутых платформах и документируйте публичный контракт на обоих языках.
Эти принципы сохраняют гибкость визуального дизайна, согласованность API общих компонентов и явность платформенной интеграции по мере роста NSH.