Trechos do capítulo "Tabelas e data grids" (e a parte de análise no navegador) alexandrecaramaschi.com/educacao/frontends-com-vibecoding Onze trechos: oito pedidos prontos para colar no agente e três arquivos de configuração. A página explica cada decisão em português; aqui está só o material bruto, para quem vai executar. ================================================================================ ### O que faz: pede ao agente que rode o teste de bibliotecas de tabela com o formato real das suas colunas ### Onde entra: conversa com o agente, antes de escolher a biblioteca do projeto ### Cuidado: o resultado só vale com os SEUS tipos de célula e o SEU volume; ranking genérico não decide nada Contexto: preciso escolher a biblioteca de data grid para uma tabela de campanhas com [N] colunas, sendo [descreva: 3 de moeda, 1 de sparkline, 1 de badge de status, 2 de texto longo]. O volume real chega a [X] linhas. Tarefa: 1. Clone github.com/hckhanh/benchmark-table-libraries e leia como ele mede mount, FPS de scroll e heap. 2. Substitua o gerador de dados dele pelo SHAPE das minhas colunas acima (mesma quantidade e mesmos tipos de célula). 3. Rode com 10 mil, 100 mil e 1 milhão de linhas e me devolva uma TABELA de resultados: biblioteca x volume x mount(ms) x FPS x heap(MB). 4. A partir dos MEUS números, recomende: DOM virtualizado, Canvas ou server-side row model, e justifique em duas frases. Critérios de aceite: - Os números vêm da execução real na minha máquina, não de estimativa. - A recomendação cita o heap e o FPS medidos, não um ranking genérico. - Se 100 mil linhas ainda couberem em DOM com FPS >= 30, diga para eu NÃO migrar para Canvas ainda (complexidade que não paga o custo). ================================================================================ ### O que faz: manda registrar só os recursos que a tela usa e provar em kilobytes o quanto o corte economizou ### Onde entra: tela de tabela já construída, antes de padronizar a configuração no projeto ### Cuidado: exige conferir qual é a linha estável e qual está em teste, com a data da consulta, em vez de assumir de memória Antes de escrever qualquer código: consulte a documentação e o registro de pacotes para descobrir qual é a linha ESTÁVEL corrente da biblioteca de tabela deste projeto e qual linha está em versão de teste. Cite os números que você encontrou, com a data da consulta. Depois, nesta tela: 1. Registre explicitamente apenas os recursos que ela usa (ordenação e paginação). Não importe filtro, agrupamento nem tabela dinâmica. 2. Rode o analisador de pacote antes e depois e me mostre, em kilobytes, quanto o corte economizou no arquivo desta rota. 3. Extraia a configuração comum para uma base reutilizável, de onde as outras tabelas do produto herdem o mesmo comportamento. Critérios de aceite: - Você declarou a linha estável e a linha de teste com a data da consulta, em vez de assumir de memória. - O relatório de pacote traz o número antes e depois, não uma estimativa. - O comportamento visível (ordenar coluna, paginar) fica idêntico ao anterior. - Se a versão que você precisaria usar estiver em teste, diga isso em vez de adotá-la em silêncio. ================================================================================ ### O que faz: constrói a mesma tabela nos dois caminhos de desenho e audita a acessibilidade dos dois ### Onde entra: decisão entre desenhar como imagem (Canvas) e tabela do próprio documento ### Cuidado: os relatórios precisam ser gerados pelo auditor, não descritos de memória Monte a MESMA tabela de campanhas (as mesmas 8 colunas, os mesmos dados) em DUAS implementações, em rotas separadas: A) Glide Data Grid (Canvas) B) Highcharts Grid Lite (tabela HTML semântica) Depois, para cada uma: 1. Rode o auditor de acessibilidade do Chrome MCP (a11y) e cole o relatório. 2. Navegue por teclado (Tab, setas) e descreva o que um leitor de tela anuncia ao entrar na tabela e ao mover entre células. Entregue uma comparação honesta: onde o Glide precisa de camada ARIA extra e onde o Grid Lite entrega a11y sem esforço, e em que cenário cada um vence. Critérios de aceite: - Os dois relatórios de a11y são reais, gerados pelo auditor, não descritos de memória. - A conclusão liga a escolha ao REQUISITO (volume x acessibilidade), e diz explicitamente que a decisão NÃO é pela biblioteca mais moderna. ================================================================================ ### O que faz: registra um servidor de contexto do fornecedor da biblioteca, para o agente consultar a interface real ### Onde entra: arquivo .mcp.json na raiz do projeto ### Cuidado: nome de pacote é o primeiro item que um modelo inventa; copie da documentação oficial do fornecedor // .mcp.json na raiz do projeto. O comando e o nome do pacote precisam vir // da documentação OFICIAL do fornecedor da biblioteca: nome de pacote é o // primeiro item que um modelo inventa quando não encontra a informação. { "mcpServers": { "grid-do-fornecedor": { "command": "npx", "args": ["-y", ""] } } } ================================================================================ ### O que faz: experimento de controle que expõe o quanto o agente inventa quando não consulta a documentação ### Onde entra: configuração de entrega em fatias pelo servidor num grid corporativo ### Cuidado: gere primeiro a versão consultada e só depois a de memória, senão você contamina a comparação Adicione a este grid a entrega em fatias pelo servidor com agregação: o servidor pagina, ordena e agrega; o cliente pede apenas a janela visível. Experimento de controle, nesta ordem: 1. Primeiro gere a configuração consultando a documentação oficial da versão instalada (ou o servidor de contexto do fornecedor, se existir). 2. Depois gere a mesma configuração sem consultar nada, só com o que você lembra da interface. Compare as duas: quantas opções diferem, quantas a segunda inventou ou errou, e qual das duas compila e roda. Critérios de aceite: - A primeira versão cita propriedades que existem na documentação da versão instalada, com a data da consulta. - Você aponta explicitamente onde a segunda versão inventou, se inventou. - A entrega em fatias funciona: rolar carrega blocos sob demanda, e a linha de totais bate com a soma calculada no servidor. ================================================================================ ### O que faz: monta um explorador que lê arquivo colunar comprimido dentro do próprio navegador, sem servidor de dados ### Onde entra: exploração de conjunto grande, ou caso em que o dado não deve sair da máquina de quem lê ### Cuidado: carregar o arquivo inteiro na memória antes de entregar ao motor joga fora a leitura por partes, que é o motivo da escolha Este exercício pede terminal e código. Monte uma página estática que leia um arquivo colunar comprimido dentro do próprio navegador, sem nenhum servidor de dados: - Um histograma, um mapa e uma tabela, os três com filtro cruzado ligado: selecionar uma faixa num deles refiltra os outros dois. - O arquivo é lido por partes; NÃO carregue o conjunto inteiro na memória da página. - Estado de carregamento visível enquanto o motor analítico inicializa. Critérios de aceite: 1. Abrir o arquivo local já mostra os três elementos. 2. Selecionar uma faixa atualiza os outros dois em menos de 200 milissegundos, medido e não estimado. 3. O consumo de memória da aba não cresce proporcional ao número de linhas do arquivo; confirme na ferramenta de desenvolvedor e anexe o número. 4. Explique em três linhas, em comentário, por que essa arquitetura sustenta um volume em que a abordagem de carregar tudo na memória travaria. ================================================================================ ### O que faz: liga um painel a um fluxo contínuo de eventos sem redesenhar a tela inteira a cada atualização ### Onde entra: tela de operação com cotação, telemetria ou fila de eventos ### Cuidado: recriar a tabela a cada mensagem, ou deixar o estado dos dados no React, é o que faz o computador esquentar Este exercício pede terminal, código e uma fonte de eventos ao vivo. Conecte um a este WebSocket de ticks e configure um pivot por símbolo com heatmap: - Os updates chegam pelo WebSocket em Arrow; alimente a table do Perspective incrementalmente (NÃO recrie a table a cada mensagem). - Pivot: linhas por símbolo, colunas com preço médio e volume, células em heatmap. - O componente React ao redor NÃO deve re-renderizar a cada tick; o estado dos dados vive dentro do Perspective. Critérios de aceite: 1. Com ~10 ticks/segundo, o React DevTools não mostra renders em cascata do componente pai a cada tick. 2. O pivot atualiza suave, sem piscar a tela inteira. 3. prefers-reduced-motion respeitado em qualquer transição do heatmap. ================================================================================ ### O que faz: consulta a fonte no momento de publicar e grava um retrato estático do dado ### Onde entra: rotina de carga de dados de um projeto de relatório (Observable Framework) ### Cuidado: a credencial vive em variável de ambiente; o arquivo roda no build, nunca na visita de quem lê // Observable Framework: data loader ga4.json.js roda NO BUILD. // O nome do arquivo termina em .json.js -> o Framework executa e captura o // stdout como o snapshot estático ga4.json, servido depois como dado pronto. import { BetaAnalyticsDataClient } from "@google-analytics/data"; const client = new BetaAnalyticsDataClient(); const [report] = await client.runReport({ property: `properties/${process.env.GA4_PROPERTY_ID}`, dateRanges: [{ startDate: "28daysAgo", endDate: "yesterday" }], dimensions: [{ name: "date" }], metrics: [{ name: "activeUsers" }, { name: "sessions" }], }); // process.stdout recebe o JSON: vira snapshot no build, zero API no runtime. process.stdout.write( JSON.stringify( report.rows?.map((r) => ({ date: r.dimensionValues?.[0].value, usuarios: Number(r.metricValues?.[0].value), sessoes: Number(r.metricValues?.[1].value), })) ?? [], ), ); ================================================================================ ### O que faz: pede um relatório calculado antes de publicar, que a página final apenas lê ### Onde entra: relatório cujo número muda no máximo uma vez por dia ### Cuidado: credencial sempre em variável de ambiente, nunca escrita no código Este exercício pede terminal e credenciais de leitura das suas fontes. Crie um projeto de relatório em que: - Uma rotina consulta a fonte de dados NO MOMENTO DE PUBLICAR e grava um arquivo estático com o retrato do dado (use variáveis de ambiente para as credenciais, nunca valores no código). - Uma página lê esse retrato e mostra os indicadores principais mais um gráfico de linha, com tema claro e escuro automáticos. Critérios de aceite: 1. A publicação gera páginas estáticas; a página final não consulta a fonte. 2. Trocar o tema do sistema alterna claro e escuro sem recarregar. 3. O contraste do texto sobre o fundo passa o nível AA nos dois temas. 4. Documente a diferença entre este modelo e o de consultar a fonte a cada visita, com o custo de cada um. ================================================================================ ### O que faz: relatório escrito como texto com blocos de consulta intercalados, com a explicação ao lado do número ### Onde entra: página de relatório versionada no repositório (Evidence) ### Cuidado: a separação por cliente precisa viver no servidor; o filtro na consulta é ilustração, não controle de acesso --- title: Relatório mensal de {params.cliente} --- ```sql receita_mes select data_ref, sum(valor) as receita from faturas where cliente_id = '${params.cliente}' -- RLS: cada cliente vê só a sua linha group by data_ref order by data_ref ``` A receita reflete faturas emitidas até {inputs.freshness}. Fonte: tabela `faturas` (sistema de billing). Owner do KPI: Financeiro. Definição: soma de `valor` das faturas com status = emitida. ================================================================================ ### O que faz: gera um relatório por cliente com separação de dados e proveniência ao lado de cada número ### Onde entra: portal em que cada cliente vê apenas a própria linha ### Cuidado: teste o caso de alguém alterar o endereço à mão; a regra de separação mora no servidor, não na tela Este exercício pede terminal, código e acesso a um banco de teste. Gere um relatório a partir destas cinco consultas, com acesso separado por cliente: - Cada página exibe os dados de UM cliente, escolhido pelo endereço. - A regra de separação garante que um cliente jamais veja a linha de outro, e essa regra vive no servidor, não na tela. - Cada número exibido traz, ao lado, origem, data de apuração, responsável e a definição da métrica. Critérios de aceite: 1. Trocar o cliente no endereço troca os dados, sem vazamento cruzado, e você testou o caso de alguém alterar o endereço à mão. 2. As cinco consultas rodam e alimentam os componentes sem erro de estrutura. 3. Cada indicador exibe os quatro itens de proveniência. 4. Documente o que precisaria mudar para hospedar isso na própria empresa.