Capítulo 32 — Frontend Web: React

32.1 Objetivo do Capítulo

Este capítulo detalha a arquitetura e os padrões de implementação do frontend web da Plataforma de Relacionamento Digital com o Cidadão. O frontend web engloba dois contextos distintos: o Portal Web do Cidadão (jornadas de autoatendimento) e o Painel do Gestor (funções administrativas e operacionais).

Ambos compartilham a mesma stack tecnológica (React, TypeScript, Tailwind CSS), o mesmo design system, a mesma base de componentes reutilizáveis e as mesmas estratégias de segurança, performance, acessibilidade e observabilidade. As diferenças residem no escopo funcional e nas permissões de acesso, não na arquitetura.

Este capítulo responde: como são organizados os componentes; como o estado é gerenciado; como a autenticação e o contexto de tenant são propagados; como as APIs são consumidas; como a acessibilidade e a performance são garantidas; como os testes cobertem o frontend; como a observabilidade funciona no cliente.

32.2 Papel do Frontend Web na Plataforma

O frontend web é um dos três canais de acesso à plataforma (web, mobile, integração). Sua responsabilidade é exclusivamente apresentação e experiência de uso. Toda lógica de negócio, autorização, persistência e processamento residem no backend.

Usuário no navegador
    │
Portal Web / Painel do Gestor (React)
    │
Consome APIs REST
    │
Backend (Java / Spring Boot)
    │
Executa lógica, persiste dados, integra sistemas

O frontend não é "interface para o usuário acessar dados". É uma aplicação de cliente rico que oferece jornadas completas: descoberta, autenticação, ação, acompanhamento, feedback.

32.3 Stack Tecnológico

32.3.1 React

A aplicação é construída em React 18+ com TypeScript. React oferece componentes reutilizáveis, state management por contexto, e ecossistema maduro de bibliotecas. TypeScript adiciona tipagem estática que reduz erros em tempo de desenvolvimento e melhora a autocompletar e a documentação do código.

32.3.2 TypeScript

Todos os componentes, hooks e serviços são escritos em TypeScript, não em JavaScript. Types são definidos para toda comunicação com API, para o estado da aplicação e para as propriedades dos componentes. Strict mode é ativado.

32.3.3 Tailwind CSS

Styling é feito com Tailwind CSS — utility-first CSS framework que oferece classes predefinidas para construir layouts e componentes sem escrever CSS customizado. Tokens de design (cores, tipografia, espaçamento) da plataforma são aplicados via configuração do Tailwind, garantindo consistência visual entre Portal e Painel.

32.3.4 Ferramentas de Build

Build é realizado com Vite ou equivalente moderno que oferece hot module replacement em desenvolvimento e otimizações de produção (minificação, tree-shaking, code splitting). TypeScript é compilado para JavaScript no build. CSS é processado e otimizado.

32.3.5 Dependências Principais

Bibliotecas essenciais: axios (cliente HTTP), react-query ou SWR (cache e sincronização com servidor), zustand ou Recoil (state management), react-router (roteamento), react-hook-form (gerenciamento de formulário), zod ou yup (validação), vitest e @testing-library/react (testes), sentry (error tracking).

32.4 Arquitetura de Componentes

32.4.1 Design System

O design system é o contrato visual e comportamental da plataforma. Define: paleta de cores, tipografia, espaçamento, componentes base (botão, campo de entrada, card, modal) e seus estados (normal, hover, foco, desabilitado, erro, carregamento).

O design system é compartilhado entre Portal Web, Painel do Gestor e Aplicativo Mobile (React Native com NativeWind). Componentes base — Button, Input, Card, Modal, Select — têm implementação idêntica nos três canais (exceto por abstrações específicas de cada plataforma).

32.4.2 Componentes Base (Design System)

Componentes base cobrem: Button (primário, secundário, terciário, tamanhos), Input (text, email, password, number), Textarea, Select, Checkbox, Radio, Toggle, Card, Modal, Toast, Alert, Loader, Avatar, Badge, Chips, Tabs, Accordion, Breadcrumb, Pagination, Dropdown.

Cada componente tem: variante visual (tipo, tamanho, estado), propriedades (disabled, loading, error, required), validação de tipos em TypeScript, testes unitários, histórico em Storybook.

32.4.3 Componentes de Domínio

Componentes de domínio são compostos a partir de componentes base e encapsulam lógica de apresentação específica de funcionalidades: FormField (Input + Label + Error), ServiceCard (exibe serviço do catálogo), RequestCard (exibe protocolo de solicitação), DocumentUpload (upload com validação), DatePicker (seletor de data), TimePicker (seletor de hora), AddressAutocomplete (busca de endereço com integração a serviço externo).

Componentes de domínio não contêm regra de negócio — apenas apresentação e validação de entrada. Regra de negócio é sempre o backend.

32.4.4 Páginas e Rotas

Páginas são compostas de componentes de domínio e Base. Cada rota da aplicação é uma página: /catalog (catálogo), /services/{id} (detalhe do serviço), /auth/login (autenticação), /requests (lista de solicitações), /requests/{id} (detalhe), /profile (perfil do usuário), /admin (área administrativa para gestores).

Roteamento é feito com react-router v6. Rota autenticada verifica se o usuário tem sessão válida; caso contrário, redireciona para login. Rota de gestor verifica perfil — cidadão com perfil ATTENDANT não acessa /admin.

32.5 State Management

32.5.1 Estado Local vs. Estado Global

Estado local (useState) é usado para estado de componente efêmero: valor de input enquanto o usuário digita, aberto/fechado de modal, loading durante chamada de API no componente.

Estado global (Context + Hook ou Zustand) é usado para estado transversal: usuário autenticado, tenant atual, perfis e permissões, configurações do tenant.

Estado no servidor (react-query, SWR) é usado para dados que vêm do backend: lista de solicitações, detalhe de serviço, catálogo. O cache local de dados do servidor é mantido sincronizado com o servidor via polling, invalidação após mutação ou websocket.

32.5.2 Contexto de Autenticação

O contexto AuthContext armazena: usuário autenticado (id, name, email, perfis, unidades), token de acesso, tenant atual, função para login/logout. O contexto é preenchido na inicialização da aplicação validando token persistido (cookie seguro ou estado do navegador).

32.5.3 Contexto de Tenant

O contexto TenantContext armazena: tenant selecionado (id, name, colors, logo), configurações do tenant (políticas de senha, timeout de sessão, canais habilitados), status de integração com sistemas externos.

O tenant é derivado da identidade autenticada — o usuário não escolhe o tenant via dropdown. A aplicação determina quais tenants o usuário tem acesso e apresenta as opções de alternância se o usuário tem vínculo com múltiplos tenants.

32.5.4 Mutações e Revalidação

Quando o usuário submete um formulário ou executa uma ação, a aplicação envia a requisição ao backend e, se bem-sucedida, invalida o cache local de dados relacionados. Por exemplo, após criar uma solicitação, o cache da lista de solicitações é invalidado e recarregado automaticamente.

32.6 Consumo de APIs

32.6.1 Cliente HTTP

Requisições ao backend são feitas com axios configurado com interceptadores para: adicionar token de autenticação em headers, propagar correlationId, tratar respostas com erro, fazer retry em caso de falha de rede ou 5xx com backoff exponencial.

Timeout é configurado por tipo de operação: leitura (10s), criação/atualização (15s), upload de arquivo (60s).

32.6.2 Cache e Sincronização

React Query (ou SWR) é usado para cache de dados do servidor. Cada query é identificada por chave única: ['services'], ['requests', { tenantId, page: 0 }]. O cache é invalidado quando: (a) o TTL expira (padrão 5 minutos para dados quentes), (b) uma mutação relacionada é bem-sucedida, (c) o usuário foca a janela (background refetch).

32.6.3 Tratamento de Erros

Erros de API são capturados e apresentados ao usuário com clareza: "Não foi possível carregar o catálogo. Tente novamente." (erro de rede), "Você não tem permissão para acessar este serviço." (403), "O serviço está temporariamente indisponível." (5xx). Stack trace e detalhes técnicos nunca são expostos ao usuário final.

32.6.4 Upload de Arquivo

Upload de arquivo é uma chamada multipart/form-data. Antes do envio, a aplicação valida: formato (extensão), tamanho (máximo 10MB por arquivo), quantidade (máximo N arquivos por solicitação). Durante o upload, indicador de progresso é exibido. Após o upload, confirmação é exibida.

32.7 Autenticação e Autorização

32.7.1 Autenticação Local

Fluxo de login local: usuário fornece e-mail e senha → chamada de API POST /auth/login → backend valida e retorna token de acesso e refresh token → cliente armazena tokens de forma segura → token é incluído em requisições subsequentes via header Authorization: Bearer {token}.

Token expirado: quando uma requisição retorna 401, a aplicação tenta usar o refresh token para obter novo access token. Se o refresh token também tiver expirado, o usuário é redirecionado para login.

32.7.2 Autenticação via GOV.BR

Fluxo GOV.BR: botão "Entrar com GOV.BR" → redirecionamento para GOV.BR com authorization code flow + PKCE → cidadão autentica no GOV.BR → redirecionamento de volta ao portal com authorization code → backend valida o código com GOV.BR, cria ou localiza identidade da plataforma, retorna token → client armazena token.

A estratégia de armazenamento de token (cookie HttpOnly vs. estado em memória com refresh via cookie) é definida pela ADR-190 e aplicada uniformemente.

32.7.3 Autorização no Frontend

O frontend não é mecanismo de autorização — é mecanismo de experiência de usuário. Se o usuário não tem permissão para executar uma ação, o botão que aciona a ação fica oculto ou desabilitado. Mas se o usuário conseguir chamar a API diretamente (ex.: via console do navegador), o backend re-valida a permissão e nega a operação.

Permissões do usuário autenticado são carregadas no contexto de autenticação durante o login. O frontend consulta o contexto para decidir se exibe um elemento da interface — a decisão final de autorização é sempre do backend.

32.8 Formulários Dinâmicos

32.8.1 Renderização a partir de Schema

O formulário que o cidadão preenche na abertura de solicitação é renderizado dinamicamente a partir de um schema JSON retornado pelo backend. O schema define: campos (nome, tipo, obrigatório, validação), ordem, agrupamento em seções, condicionais (campo A aparece se campo B = X), valores padrão, dicas de ajuda.

O frontend não tem templates de formulário embutidos. Quando o backend publica um novo serviço com formulário diferente, o portal renderiza corretamente sem deploy.

32.8.2 Validação

Validação é em dois níveis: (a) cliente — conforme o schema, o frontend valida tipos, tamanho, formato (email, CPF), obrigatoriedade; (b) backend — backend re-valida toda submissão independentemente do que o cliente enviou.

Erros de validação são exibidos no campo correspondente com mensagem clara (ex.: "Insira um e-mail válido").

32.8.3 Campos Condicionais

Um campo pode ser condicionalmente visível com base no valor de outro campo. O schema define: dependsOn: "fieldName" e showWhen: { "fieldName": "value" }. O frontend avalia a condição e renderiza ou oculta o campo dinamicamente.

32.8.4 Progresso Multipágina

Formulários grandes são divididos em múltiplas páginas. O frontend armazena os dados preenchidos em estado local (não envia para o servidor até a confirmação final). Indicador de progresso mostra qual página o usuário está. Voltar edita dados já preenchidos; avançar valida a página atual.

32.9 Gestão de Documentos

32.9.1 Upload e Reuso

No contexto de uma solicitação, quando um documento é exigido, o cidadão pode: (a) enviar novo arquivo, (b) selecionar documento que já enviou anteriormente se o tipo for compatível. A reutilização economiza tempo e reduz a quantidade de upload de dados.

32.9.2 Validação de Formato e Tamanho

Antes do envio, o cliente valida: extensão do arquivo (apenas formatos permitidos), tamanho (máximo 10MB), quantidade (máximo N arquivos). Se validação falhar, mensagem de erro explícita guia o usuário (ex.: "Arquivo muito grande. Máximo 10MB").

32.9.3 Progresso de Upload

Durante o upload, indicador de barra de progresso mostra percentual carregado. Se a conexão cair, há opção de retry. Se o upload falhar após múltiplas tentativas, mensagem de erro permite ao usuário decidir se tenta novamente ou contata suporte.

32.10 Acessibilidade (WCAG 2.1 — Nível AA)

32.10.1 Componentes Acessíveis

Componentes base do design system são construídos com acessibilidade integrada: botões têm labels e atributos aria; campos de entrada têm labels associados; modais gerenciam foco; cores não são o único indicador visual (há ícones ou texto também).

32.10.2 Navegação por Teclado

Toda funcionalidade é acessível por teclado: Tab navega entre elementos focáveis, Enter ativa botões, Esc fecha modais. Ordem de foco segue a ordem lógica de leitura. Nenhuma armadilha de foco: o usuário pode sair de qualquer componente com teclado.

32.10.3 Leitores de Tela

Estrutura semântica do HTML permite leitores de tela (NVDA, JAWS, VoiceOver) navegarem e compreenderem a página: headings indicam estrutura (h1, h2...), landmarks (<main>, <nav>, <aside>) delimitam regiões, labels associam texto a campos, aria-label fornece texto alternativo para ícones, aria-live comunica atualizações dinâmicas.

32.10.4 Contraste e Redimensionamento

Contraste mínimo de 4,5:1 entre texto e background é mantido em toda a interface. Usuário pode redimensionar até 200% sem perder conteúdo ou funcionalidade.

32.10.5 Testes de Acessibilidade

Acessibilidade é verificada por: (a) ferramentas automatizadas (WAVE, axe) no CI; (b) testes manuais com leitor de tela em navegadores representativos; (c) revisão de design e componentes com especialista em acessibilidade.

32.11 Performance e Core Web Vitals

32.11.1 Métricas

O portal monitora os Core Web Vitals que impactam a experiência real do cidadão:

• LCP (Largest Contentful Paint): tempo até o maior elemento da página estar visível. Meta: ≤ 2,5 segundos.
• INP (Interaction to Next Paint): latência da resposta a uma interação do usuário. Meta: ≤ 200ms.
• CLS (Cumulative Layout Shift): mudanças não esperadas no layout. Meta: ≤ 0,1.

32.11.2 Code Splitting

O bundle de produção é dividido por rota: o portal carrega apenas o código da rota atual. Rotas posteriores na navegação são pré-carregadas em background. Componentes pesados (editor de formulário, visualizador de PDF) são lazy-loaded apenas quando necessários.

32.11.3 Caching de Recursos Estáticos

Recursos estáticos (CSS, JavaScript, fontes) têm versionamento via hash no nome: app.a3f2d1.js. O navegador faz cache agressivo (Expires longínquo). Quando o código muda, hash muda, novo arquivo é baixado.

32.11.4 Otimizações de Imagem

Imagens são servidas em formatos modernos (WebP com fallback para PNG/JPEG). Tamanho é otimizado para o viewport do dispositivo (srcset). Imagens lazy-load quando entram no viewport (exceto hero images que carregam eagerly).

32.11.5 Prefetch e Preconnect

Rotas próximas na navegação são pré-carregadas em background. Domínios de terceiros utilizados (fonts, CDN) têm preconnect no <head> para reduzir latência de DNS.

32.12 Segurança no Cliente

32.12.1 Armazenamento Seguro de Tokens

Tokens de acesso são armazenados de forma segura conforme a ADR-190. Opção A: cookie HttpOnly com SameSite=Strict (protegido contra CSRF, não acessível por JavaScript). Opção B: token em memória com refresh token em cookie HttpOnly (refresh token usado para obter novo access token quando necessário).

Tokens nunca são armazenados em localStorage sem criptografia.

32.12.2 Content Security Policy (CSP)

CSP é configurada via header HTTP para restringir fontes de scripts, estilos, imagens e frames:

script-src: apenas scripts internos (hash) ou de domínios explicitamente permitidos
style-src: apenas estilos inline (nonce) ou de domínios permitidos
img-src: qualquer domínio (restritivo demais prejudicaria ícones de terceiros)
frame-src: apenas domínios de confiança (GOV.BR, SEI, etc.)

eval() e new Function() são proibidos. Inline scripts sem nonce são bloqueados.

32.12.3 Proteção contra XSS

Saída renderizada pelo React é sanitizada automaticamente (React escapa HTML por padrão). dangerouslySetInnerHTML é usado apenas para conteúdo controlado (ex.: descrição do serviço do catálogo com HTML formatado) após validação e sanitização explícita (DOMPurify).

Conteúdo gerado por IA (resposta do assistente) é sempre tratado como dado e sanitizado antes de renderizar — nunca como markup não validado.

32.12.4 Proteção contra CSRF

A estratégia de proteção CSRF é alinhada ao mecanismo de autenticação:

• Se usando cookie com token em Authorization header: não vulnerável ao CSRF clássico (headers Custom não são inclusos automaticamente em requisições cross-origin).
• Se usando cookie para armazenar sessão: CSRF token é incluído em headers personalizados (ou duplo-submit com SameSite).

32.12.5 Source Maps e Segredos

Source maps de produção não são expostos publicamente. Se algum secret (API key, URL interna) for acidentalmente incluído no código, é buscado do servidor em tempo de execução via API segura — nunca hardcoded.

32.13 Observabilidade no Frontend

32.13.1 Error Tracking

Erros de runtime no frontend são capturados por SDK (ex.: Sentry) e enviados ao backend de observabilidade com contexto: tipo de erro, mensagem, stack trace sanitizado, URL da página, tenant, usuário (sem dados pessoais), navegador. Erros são agrupados por tipo e contexto para detecção de regressões.

32.13.2 Real User Monitoring (RUM)

Telemetria de experiência real do cidadão é coletada: Core Web Vitals (LCP, INP, CLS), First Paint, Load time, tempo entre interações e respostas de API. Dados são enviados ao backend sem incluir payload sensível ou dados pessoais.

32.13.3 Session Replay

Em ambiente de produção, session replay está desabilitado por padrão por questões de privacidade. Em ambiente de staging, session replay pode ser ativado para debug de problemas com consentimento explícito.

32.13.4 Logging Estruturado

Eventos importantes no frontend são logados em estrutura JSON: navegação, autenticação, ações do usuário, erros. Logs incluem: timestamp, evento, tenant, usuário (sem dados pessoais), correlationId. Logs são enviados ao backend de observabilidade.

32.14 Testes no Frontend

32.14.1 Testes Unitários

Componentes individuais são testados com Vitest + @testing-library/react. Teste de componente valida: renderização correta, respostas a eventos de usuário (click, input), chamadas de callbacks, estados condicionais. Testes não devem testar detalhes de implementação (ex.: nome de classe CSS específico), mas comportamento observável.

32.14.2 Testes de Integração

Testes de integração cobrem fluxos completos: login → visualizar catálogo → abrir solicitação → confirmação. Testes utilizam Testcontainers para backend isolado ou servidor de staging. Assertions verificam: redirecionamentos, chamadas de API, mudanças de estado, renderização de resposta.

32.14.3 Testes de Acessibilidade

Testes automatizados com axe, WAVE detectam violações comuns (contraste, labels ausentes). Testes manuais com leitor de tela cobrem fluxos principais: login, preenchimento de formulário, submissão.

32.14.4 Testes de Performance

Bundle size é monitorado no CI — alertar se crescer além de threshold. Scores de Lighthouse (Performance, Accessibility, Best Practices, SEO) são verificados automaticamente — rejeitar PR se score cair abaixo de 80.

32.14.5 Cobertura de Testes

Meta de cobertura: 80% de linhas. Código crítico (autenticação, autorização, validação de entrada) tem cobertura ≥ 95%. Testes de UI auxiliar (tooltip, modal animação) podem ter cobertura menor.

32.15 Design System e Governança de UI

32.15.1 Componentes Base

O design system oferece componentes reutilizáveis: Button, Input, Select, Checkbox, Radio, Modal, Popover, Tooltip, Tabs, Accordion, Table, Card, Alert, Badge, Pagination, Breadcrumb, Spinner, Toast, Stepper. Cada componente tem: múltiplas variantes (tamanho, cor, estado), acessibilidade integrada, testes, documentação e exemplos no Storybook.

32.15.2 Tokens de Design

Cores, tipografia, espaçamento, bordas, sombras, transitions e z-index são definidos como tokens centralizados. Tokens são exportados em múltiplos formatos: CSS variables, JSON, SCSS. Quando o design system evolui, todos os componentes que utilizam os tokens herdam as mudanças automaticamente.

32.15.3 Personalização por Tenant

A identidade visual do tenant (cores primárias, logomarca, fonte) é aplicada via tokens injetados dinamicamente na inicialização do portal. Um único build serve todos os tenants — apenas os tokens mudam. Tokens são carregados do backend via API e armazenados em CSS variables.

32.15.4 Governança

Mudanças no design system passam por processo de revisão (ADR para decisões significativas, testes de regressão visual, aprovação de designer). Versão do design system é rastreada. Componentes deprecated geram alerta em desenvolvimento — transição for de planejamento antes de remover.

32.16 Internacionalização (i18n)

32.16.1 Estrutura

Conteúdo de interface (rótulos, mensagens de erro, ajuda) é externalizado em arquivos de tradução por idioma. Padrão: português do Brasil (pt-BR) é o idioma padrão. Suporte a outros idiomas é adicionado sem alterar componentes — apenas novos arquivos de tradução.

Arquivos de tradução: src/i18n/pt-BR.json, src/i18n/en-US.json, etc.

32.16.2 Interpolação e Pluralização

Strings podem incluir variáveis: "requestSubmitted": "Solicitação {{protocol}} enviada com sucesso". Plurais são tratados conforme a linguagem: "items": { "zero": "nenhum item", "one": "um item", "other": "{{count}} itens" }.

32.16.3 Conteúdo Gerado pelo Tenant

Conteúdo que o tenant define (nome do serviço, descrição, política de privacidade) é responsabilidade do tenant — a plataforma oferece o mecanismo, não o conteúdo traduzido. Se o tenant quer serviços em português e inglês, o tenant fornece conteúdo em ambos os idiomas.

32.17 Evolução e Versionamento

32.17.1 Versionamento de API

A plataforma utiliza versionamento de API para suportar múltiplas versões de clientes. URLs contêm versão: /api/v1/requests, /api/v2/requests. Versão antiga é mantida por período definido (ex.: 12 meses) com depreciação comunicada com antecedência. Migração para nova versão é gradual.

32.17.2 Feature Flags

Feature flags permitem ativar ou desativar funcionalidades por tenant, por percentual de usuários ou por condição de ambiente, sem deploy. Flags são avaliadas no backend — não apenas em JavaScript como único controle. Frontend consulta estado da flag e renderiza UI ou exibe fallback.

32.17.3 Deploy Contínuo

O portal tem deploy contínuo a múltiplos ambientes: desenvolvimento, staging, produção. Cada ambiente tem: build próprio, CDN próprio, configuração de backend diferente (dev usa backend de dev, prod usa backend de produção). Rollback é possível revertendo tag no repositório.

32.18 Integração com Assistente de IA

O assistente de IA está disponível no portal via ícone flutuante ou área dedicada. No canal web, suporta texto (entrada e saída). Resposta do assistente é renderizada com: formatação (negrito, itálico, listas), links de navegação (ex.: "ir para catálogo de X"), citações de fontes (ex.: "Conforme a base de conhecimento: ...").

Continuidade entre assistente e atendente humano preserva contexto: quando o cidadão solicita falar com humano, o atendente visualiza todo histórico do chat com IA — o cidadão não repete o que já explicou.

Detalhamento completo no Capítulo 22 (Atendimento Digital e Copiloto de IA).

32.19 Rastreabilidade com o Anexo III

32.20 Benefícios do Frontend Web em React

• Canal web acessível: cidadão acessa via navegador sem necessidade de app instalado.
• Responsivo: adapta-se a telas de qualquer tamanho sem degradação de funcionalidade.
• Acessível: WCAG 2.1 nível AA com suporte a tecnologias assistivas.
• Performático: Core Web Vitals monitorados e otimizados; carregamento rápido mesmo em conexões lentas.
• Seguro: tokens gerenciados com segurança; CSP, proteção XSS, CSRF; autorização re-validada no backend.
• Personalizado: identidade visual do tenant aplicada dinamicamente sem bifurcação de código.
• Internacionalizado: suporte a múltiplos idiomas sem alterar componentes.
• Observável: erro tracking, RUM, session logging conectados ao backend; debugging simplificado.
• Testável: componentes isolados, testes unitários, integração, acessibilidade, performance.
• Evolutivo: design system compartilhado; componentes base facilitam novas funcionalidades; feature flags permitem rollout gradual.

32.21 Riscos e Mitigações

32.22 Decisões Arquiteturais

32.23 Considerações Finais

O Frontend Web em React é o rosto visual da plataforma para o cidadão quando acessa por navegador. A qualidade da implementação — performance, acessibilidade, clareza nas jornadas, segurança no cliente — determina, em grande medida, a percepção do cidadão sobre a qualidade do serviço público.

Arquitetado para ser um cliente rico e responsivo que consome APIs bem definidas, o React não replica regras de negócio. Isso permite que o portal evolua independentemente dos serviços de domínio e que a segurança e a conformidade não dependam da disciplina do código frontend — são garantias do backend.

A separação clara entre apresentação (React) e lógica (backend Java/Spring) garante coesão arquitetural: cada camada tem responsabilidade bem delimitada, testes bem definidos e escalabilidade horizontal sem complexidade desnecessária.

O Capítulo 33 detalha o Aplicativo Mobile em React Native.

32.24 Controle de Versão

32.25 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 1 — itens 1.1, 1.2, 1.6, 1.10, 1.11 cobertos conforme seção 32.19; implementação das jornadas cidadão via portal React.
• [ANX-IV] — Capacidades técnicas: canal web em React, responsividade sem degradação funcional, acessibilidade WCAG 2.1 + eMAG, performance (Core Web Vitals), observabilidade frontend, design system compartilhado.
• [ANX-V] Item 2.1 — Manutenibilidade com design system centralizado, componentes reutilizáveis, padrões claros, testes integrados.
• [ANX-V] Item 2.2 — Acessibilidade: WCAG 2.1 nível AA, eMAG, testes automatizados + manuais com leitores de tela, acessibilidade integrada desde o design system.
• [ANX-V] Item 2.3 — Proteção do usuário: CSP, gestão segura de tokens, autorização re-validada no backend, LGPD aplicada (privacidade, consentimentos, portabilidade).
• [ANX-V] Item 2.5 — Evolução facilitada: design system permite novas funcionalidades sem refatoração; feature flags permitem rollout gradual; versionamento de API permite múltiplas versões de clientes.
• [PNR] — Portal Web como canal primário de autoatendimento digital, integrado às capacidades de CRM, BPM, ECM/GED, IA e comunicação da plataforma.
• [EDITAL] — Edital CP001/2026: canal web do cidadão em React com jornadas completas, acessibilidade, performance, integração ao GOV.BR e ao ecossistema PRODEMGE.