---
url: https://nsh.dev/ru/docs/goals
description: "Цели Native Shell: нативные представления и взаимодействие, дизайн под управлением приложения, общие компоненты, а также Rust и TSX на одном движке."
---

# Цели и принципы проектирования

Native Shell предоставляет нативные представления и взаимодействие на iOS, Android, macOS, Windows, Linux и в вебе. Визуальный дизайн остаётся за приложением. Одна модель компонентов подходит для целых приложений, встраиваемых функций и динамически доставляемого UI.

<a id="native-foundations-app-owned-design"></a>

## Нативный фундамент, дизайн во власти приложения

NSH опирается на представления, текст и инфраструктуру ввода каждой платформы и адаптирует взаимодействие под устройство: навигацию с клавиатуры, ввод указателем и касаниями, редактирование текста, прокрутку и доступность ([Введение](https://nsh.dev/translations/ru/docs.md#what-native-means)).

Приложение определяет цвета, типографику, отступы, формы, обратную связь состояний и анимацию. Экран настроек может следовать бренду приложения на iOS и Android, а ввод и навигация при этом соответствуют соглашениям каждого устройства. Дизайнеры развивают этот визуальный язык через стили и части компонентов.

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

<a id="native-integration-in-practice"></a>

## Нативная интеграция на практике

Нативный фундамент включает отрисовку, анимацию по кадрам, ввод и семантику доступности. На iOS и Android [Input](https://nsh.dev/translations/ru/elements/input.md) использует платформенные текстовые поля: платформа берёт на себя редактирование, меню выделения, методы ввода и поддерживаемые службы автозаполнения. Приложение описывает поле через `autoComplete`, например `current-password` или `postal-code`, а система предлагает доступные подсказки в соответствии со своими настройками и службами ([Формы и клавиатура](https://nsh.dev/translations/ru/docs/forms-and-keyboard.md)). Стилизация поля не мешает сохранить эту системную интеграцию.

Это архитектурное отличие от отрисовки текстового поля целиком внутри собственного рендерера: собственный рендерер должен сам обеспечивать интеграцию с системным редактированием и службами доступности, тогда как NSH использует платформенные текстовые элементы там, где их предоставляет бэкенд. Интеграция каждого бэкенда описана в его документации, включая собственный редактор NSH на Windows и бэкенд встраивания GPUI ([Платформы](https://nsh.dev/translations/ru/docs/platforms.md)).

Разделение поведения компонентов и визуального дизайна в [GPUI Kit](https://gpui-kit.com) повлияло на слои NSH. NSH развивает этот принцип, опираясь на инфраструктуру представлений и ввода платформ. Нативная интеграция и дизайн, принадлежащий приложению, работают вместе на протяжении всей этой модели.

<a id="one-component-model-across-platforms"></a>

## Одна модель компонентов на всех платформах

Переключатель означает одно и то же на телефоне, на десктопе и в вебе. [`nsh/base`](https://nsh.dev/translations/ru/modules/nsh-base.md) обеспечивает состояние, обработку ввода, фокус и доступность; приложение стилизует дорожку, бегунок и состояния [Switch](https://nsh.dev/translations/ru/elements/switch.md). Кнопки, флажки и радиокнопки следуют тому же принципу.

| Ответственность | Где находится | Пример |
|---|---|---|
| Отрисовка, раскладка, реактивность и окружение | `nsh-core`, `nsh` и модули рантайма | Представления, текст, сигналы, стили |
| Общее поведение и доступная структура | `nsh-base`, в TSX импортируется как `nsh/base` | `Button`, `Checkbox`, `Switch`, `Tabs` |
| Визуальный дизайн и стилизованные компоненты | Приложение или библиотека сообщества | Брендированные элементы управления, карточки, строки форм |
| Платформенно-специфичные возможности | `nsh/mobile`, `nsh/desktop` | Панель навигации на мобильных, элементы управления окном на десктопе |

У общих элементов управления есть единый кроссплатформенный дом в `nsh/base`. Платформенные модули ограничены назначением и семантикой платформы. [`TabBar`](https://nsh.dev/translations/ru/modules/nsh-mobile.md#tabbar) обслуживает навигацию верхнего уровня на мобильных; [`Tabs`](https://nsh.dev/translations/ru/elements/tabs.md) переключает содержимое вкладок на всех платформах. Их роли различны. `nsh/mobile` принимает возможности с мобильно-специфичной семантикой взаимодействия; различия во внешнем виде, размере, оттенке или анимации общего элемента управления относятся к его общему компоненту и стилизации приложения. Уведомление или тост с общей ролью следует сначала проектировать вокруг одного кроссплатформенного контракта, а представление адаптировать внутри.

Общий компонент может адаптировать взаимодействие внутри: меню открывается как всплывающее окно на десктопе и как sheet на телефоне, при этом приложение использует один API и задаёт внешний вид. Системно управляемые представления, такие как заголовки навигации и алерты, следуют документированным правилам представления платформы. Приложения могут предоставлять собственные нативные компоненты и службы через [интерфейсы встраивания](https://nsh.dev/translations/ru/docs/native-components.md).

<a id="the-unstyled-foundation-and-the-component-library-layer"></a>

## Нестилизованный фундамент и слой библиотеки компонентов

NSH владеет примитивами и нестилизованным фундаментом (`nsh-core` и `nsh-base`). Приложения и сторонние библиотеки владеют слоем стилизованной библиотеки компонентов — той ролью, которую `gpui-component` играет в [GPUI Kit](https://gpui-kit.com). Такое разделение даёт каждому продукту контроль над собственным визуальным языком и позволяет переиспользовать самые сложные части реализации компонентов.

Опыт, стоящий за этим выбором, пришёл из [GPUI Kit](https://gpui-kit.com). Его стилизованные компоненты выросли из работы над Longbridge Pro. По мере того как приложениям требовались всё более разные дизайны, давление кастомизации вынуждало пользователей форкать компоненты. Выделение общего фундамента в `gpui-base` сделало поведение переиспользуемым во всех этих дизайнах. Стилизованные компоненты остаются полезными как дизайн-референс и для приложений, потребности которых укладываются в их поверхность кастомизации; фундамент даёт остальным приложениям прямой контроль над представлением.

NSH применяет этот урок с самого начала. `nsh/base` владеет сложным поведением, взаимодействием, реактивным состоянием, фокусом, доступностью и адаптивным представлением, а тесты находятся на том слое, который отвечает за каждое поведение. Сюда входят и более крупные структуры, такие как [Dock](https://nsh.dev/translations/ru/elements/dock.md). Приложения строят разнообразные дизайны на этом фундаменте через стили, состояния, слоты и части. Вклад в компоненты следует той же границе: визуальные значения по умолчанию и брендированные варианты принадлежат компонентам приложения или сторонних авторов. Документированные системно управляемые представления и значения по умолчанию для чтения `TextView` сохраняют свои специфические контракты ([Архитектура](https://nsh.dev/translations/ru/docs/architecture.md#three-layers)).

<a id="what-the-gallery-demonstrates"></a>

### Что демонстрирует Gallery

Демо на сайте и Gallery — это стилизованные примеры приложений. Их градиенты, тени, скруглённые углы, переходы и движение показывают возможности кастомизации NSH и служат примерами исходного кода. Эти решения относятся к демо и Gallery; переиспользуемые базовые компоненты предоставляют лежащие под ними поведение и части. Приложения могут позаимствовать примеры или построить другой визуальный язык.

Независимо распространяемая стилизованная библиотека относилась бы к слою приложений и сообщества, описанному выше. Стилизация Gallery иллюстрирует одно из направлений дизайна; пригодность его для конкретного продукта — дизайнерское решение этого продукта.

<a id="rust-and-tsx-on-one-engine"></a>

## Rust и TSX на одном движке

Приложения на Rust, экраны на TSX и смешанные проекты используют общие примитивы, базовые компоненты, сигналы и раскладку. Rust обеспечивает скомпилированную логику приложения и переиспользуемые нативные компоненты. TSX поддерживает быстрые итерации и модули, доставляемые во время выполнения ([Сборка на Rust](https://nsh.dev/translations/ru/docs/rust.md)).

Движок обновляет привязки, зависящие от изменённых сигналов, и группирует операции над представлениями. Раскладка текста, нативные анимации и ввод принадлежат движку и его платформенным бэкендам ([Архитектура](https://nsh.dev/translations/ru/docs/architecture.md)). Производительность оценивается на воспроизводимых рабочих нагрузках приложений ([Производительность](https://nsh.dev/translations/ru/docs/performance.md)).

<a id="embedding-dynamic-delivery-and-ai"></a>

## Встраивание, динамическая доставка и ИИ

Существующее нативное приложение размещает представление NSH там, где должна находиться функция, и предоставляет собственные нативные компоненты и службы хоста. Автономные приложения используют тот же рантайм и ту же модель компонентов ([Платформы](https://nsh.dev/translations/ru/docs/platforms.md)).

Динамически доставляемые модули TSX владеют своим состоянием, логикой и раскладкой. Подписанные пакеты определяют, каким издателям хост доверяет; ограничения песочницы и возможности определяют, что модулям разрешено делать. И доверие, и разрешения выбирает хост ([Подписанные пакеты](https://nsh.dev/translations/ru/docs/signed-packages.md), [Песочница и возможности](https://nsh.dev/translations/ru/docs/sandbox-and-capabilities.md)).

UI, сгенерированный ИИ, следует этому контракту: генерировать TSX по объявленным API, проверить и протестировать его, собрать и подписать модуль, затем верифицировать и запустить по политике хоста. Сгенерированные объявления, документация, читаемая моделями, и тесты через CLI делают этот процесс прозрачным и воспроизводимым ([Тестирование и трассировка](https://nsh.dev/translations/ru/docs/testing-and-trace.md)).

<a id="how-these-goals-guide-additions"></a>

## Как эти цели направляют добавление нового

1. Определите пользовательское поведение и является ли оно общим для платформ.
2. Размещайте общее поведение в существующем примитиве или базовом компоненте, открывая состояние и части для кастомизации приложением.
3. Размещайте возможности с платформенно-специфичной семантикой в их платформенном модуле, документируя применимость и сочетание с общим UI.
4. Стилизованные компоненты создавайте в приложении или библиотеке сообщества.
5. Проверяйте поведение, доступность, раскладку и ввод на затронутых платформах и документируйте публичный контракт на обоих языках.

Эти принципы сохраняют гибкость визуального дизайна, согласованность API общих компонентов и явность платформенной интеграции по мере роста NSH.