Objetivos e princípios de design

Native Shell fornece views e interação nativas em iOS, Android, macOS, Windows, Linux e na web. O app é dono do seu design visual. Um único modelo de componentes atende apps completos, funcionalidades incorporadas e UI entregue dinamicamente.

#Fundações nativas, design controlado pelo app

O NSH se baseia nas views, no texto e na infraestrutura de entrada de cada plataforma, e adapta a interação ao dispositivo: navegação por teclado, entrada por ponteiro e toque, edição de texto, rolagem e acessibilidade (Introdução).

O app define cores, tipografia, espaçamento, formas, feedback de estado e animação. Uma tela de configurações pode seguir a marca do app no iOS e no Android, enquanto a entrada e a navegação seguem as convenções de cada dispositivo. Designers refinam essa linguagem visual por meio de estilos e partes de componentes.

Uma view nativa é a base de renderização. Um controle com o estilo do sistema é uma escolha visual e comportamental específica. Os controles comuns do NSH expõem comportamento compartilhado e partes personalizáveis, para que as aplicações possam construir seus próprios design systems.

#Integração nativa na prática

A fundação nativa inclui renderização, animação orientada a quadros, entrada e semântica de acessibilidade. No iOS e no Android, Input usa campos de texto da plataforma: a plataforma cuida da edição, dos menus de seleção, dos métodos de entrada e dos serviços de preenchimento automático compatíveis. O app descreve o campo por meio de autoComplete, por exemplo current-password ou postal-code, e o sistema fornece as sugestões disponíveis de acordo com suas configurações e serviços (Formulários e teclado). Estilizar o campo é compatível com manter essa integração com o sistema.

Essa é uma distinção arquitetural em relação a desenhar um campo de texto inteiramente dentro de um renderizador personalizado: um renderizador personalizado fornece sua própria integração com os serviços de edição e acessibilidade do sistema, enquanto o NSH usa controles de texto da plataforma onde o seu backend os oferece. A documentação de cada backend define sua integração, incluindo o editor próprio do NSH no Windows e o backend de incorporação GPUI (Plataformas).

A separação entre comportamento de componente e design visual do GPUI Kit inspira as camadas do NSH. O NSH expande esse princípio com a infraestrutura de views e de entrada da plataforma. Integração nativa e design controlado pelo app funcionam em conjunto ao longo de todo este modelo.

#Um modelo de componentes em todas as plataformas

Um switch significa a mesma coisa em um celular, em um desktop e na web. nsh/base fornece estado, tratamento de entrada, foco e acessibilidade; o app estiliza a trilha, o thumb e os estados do Switch. Botões, checkboxes e radios seguem o mesmo princípio.

Responsabilidade	Local	Exemplo
Renderização, layout, reatividade e ambiente	nsh-core, nsh e módulos de runtime	Views, texto, signals, estilos
Comportamento compartilhado e estrutura acessível	nsh-base, importado como nsh/base em TSX	Button, Checkbox, Switch, Tabs
Design visual e componentes estilizados	O app ou uma biblioteca da comunidade	Controles com a marca, cards, linhas de formulário
Capacidades específicas de plataforma	nsh/mobile, nsh/desktop	Barra de navegação mobile, controles de janela no desktop

Os controles comuns têm um único lar multiplataforma em nsh/base. Os módulos de plataforma têm escopo definido por finalidade e semântica da plataforma. TabBar atende à navegação de nível superior no mobile; Tabs alterna conteúdo em abas entre plataformas. Seus papéis são distintos. nsh/mobile aceita capacidades com semântica de interação específica de mobile; diferenças na aparência, no tamanho, na cor ou na animação de um controle comum pertencem ao componente compartilhado e à estilização do app. Uma notificação ou um toast com papel compartilhado deve ser projetado primeiro em torno de um único contrato multiplataforma, com a apresentação adaptada internamente.

Um componente compartilhado pode adaptar sua interação internamente: um menu abre como popup no desktop e como sheet no celular, enquanto o app usa uma única API e fornece a sua aparência. Apresentações gerenciadas pelo sistema, como cabeçalhos de navegação e alertas, seguem as regras de apresentação documentadas de cada plataforma. Os apps podem expor seus próprios componentes e serviços nativos por meio das interfaces de incorporação.

#A fundação sem estilo e a camada de biblioteca de componentes

O NSH é dono das primitivas e da fundação sem estilo (nsh-core e nsh-base). Aplicações e bibliotecas de terceiros são donas da camada estilizada de biblioteca de componentes, o papel que gpui-component desempenha no GPUI Kit. Essa divisão dá a cada produto controle sobre sua linguagem visual, ao mesmo tempo em que reaproveita as partes difíceis da implementação de componentes.

A experiência por trás dessa escolha vem do GPUI Kit. Seus componentes estilizados surgiram do trabalho no Longbridge Pro. À medida que os aplicativos exigiam designs cada vez mais diferentes, a pressão por personalização levou os usuários a fazer forks dos componentes. Extrair a fundação compartilhada para gpui-base tornou o comportamento reutilizável entre esses designs. Os componentes estilizados continuam úteis como referência de design e para aplicações cujas necessidades cabem na sua superfície de personalização; a fundação dá às demais aplicações controle direto sobre a apresentação.

O NSH aplica essa lição desde o início. nsh/base é dono de comportamento complexo, interação, estado reativo, foco, acessibilidade e apresentação adaptativa, com testes na camada responsável por cada comportamento. Isso inclui estruturas maiores, como Dock. As aplicações constroem designs diversos sobre essa fundação por meio de estilos, estados, slots e partes. As contribuições de componentes seguem a mesma fronteira: padrões visuais e variantes com a marca pertencem a componentes da aplicação ou de terceiros. As apresentações gerenciadas pelo sistema documentadas e os padrões de leitura de TextView mantêm seus contratos específicos (Arquitetura).

#O que a Gallery demonstra

As demos do site e a Gallery são aplicativos de exemplo estilizados. Seus gradientes, sombras, cantos arredondados, transições e movimentos exercitam as capacidades de personalização do NSH e fornecem exemplos de código-fonte. Essas escolhas pertencem às demos e à Gallery; os componentes base reutilizáveis expõem o comportamento e as partes que ficam por baixo delas. As aplicações podem aproveitar os exemplos ou construir uma linguagem visual diferente.

Uma biblioteca estilizada distribuída de forma independente pertenceria à camada de aplicação/comunidade descrita acima. A estilização da Gallery ilustra uma direção de design; a adequação a um produto específico é uma decisão de design desse produto.

#Rust e TSX em um único motor

Apps em Rust, telas em TSX e projetos mistos compartilham primitivas, componentes base, signals e layout. Rust oferece lógica de aplicação compilada e componentes nativos reutilizáveis. TSX permite iteração rápida e módulos entregues em tempo de execução (Criando com Rust).

O motor atualiza os bindings que dependem de signals alterados e agrupa em lote as operações de view. O layout de texto, as animações nativas e a entrada pertencem ao motor e aos seus backends de plataforma (Arquitetura). O desempenho é avaliado com cargas de trabalho de aplicações reproduzíveis (Desempenho).

#Incorporação, entrega dinâmica e IA

Um app nativo existente coloca uma view do NSH onde uma funcionalidade deve ficar e expõe seus próprios componentes nativos e serviços do host. Apps independentes usam o mesmo runtime e o mesmo modelo de componentes (Plataformas).

Módulos TSX entregues dinamicamente são donos do seu estado, da sua lógica e do seu layout. Pacotes assinados estabelecem em quais publicadores o host confia; limites de sandbox e capacidades definem o que os módulos podem fazer. O host escolhe tanto a confiança quanto as permissões (Pacotes assinados, Sandbox e capacidades).

A UI gerada por IA segue esse contrato: gerar TSX com base em APIs declaradas, verificá-lo e testá-lo, compilar e assinar o módulo, e então verificá-lo e executá-lo sob a política do host. Declarações geradas, documentação legível por modelos e testes via CLI tornam o fluxo de trabalho inspecionável e repetível (Testes e rastreamento).

#Como esses objetivos orientam novas adições

1. Estabeleça o comportamento do usuário e se ele é compartilhado entre plataformas.
2. Coloque o comportamento compartilhado na primitiva ou no componente base existente, expondo estado e partes para a personalização pelo app.
3. Coloque capacidades com semântica específica de plataforma no módulo da respectiva plataforma, documentando a aplicabilidade e a composição com a UI compartilhada.
4. Construa componentes estilizados no app ou na biblioteca da comunidade.
5. Verifique comportamento, acessibilidade, layout e entrada nas plataformas afetadas, e documente o contrato público nos dois idiomas.

Esses princípios mantêm o design visual flexível, as APIs de componentes compartilhados coerentes e a integração com a plataforma explícita à medida que o NSH cresce.