WEBVTT 00:00:00.000 --> 00:00:02.220 Legal, vamos mergulhar direto nisso. 00:00:02.220 --> 00:00:06.780 A equipe de marketing e produto da Leadlovers está com um baita desafio prático nas mãos. 00:00:06.780 --> 00:00:10.680 Escalar a criação de telas usando agentes de inteligência artificial. 00:00:10.680 --> 00:00:13.420 Só que a gente sabe bem o que acontece na trincheira. 00:00:13.420 --> 00:00:18.940 Quem comenda a tela para IA acaba recebendo o código React numa velocidade impressionante, 00:00:18.940 --> 00:00:20.580 mas junto vem o problema. 00:00:20.580 --> 00:00:25.740 A IA acerta a estrutura lindamente, só que vira e mexe a lalucina na atualidade 00:00:25.740 --> 00:00:28.180 e entrega um padrão de dois anos atrás. 00:00:28.180 --> 00:00:34.340 Então, esse panorama tático foi montado justinho para dar a régua exata do que aceitar e do que mandar de volta. 00:00:34.340 --> 00:00:37.340 A ideia é revisar qual quem entrega com total confiança. 00:00:37.340 --> 00:00:42.100 E para a gente não se perder, nossa agenda passa rapidinho por seis pontos-chave. 00:00:42.100 --> 00:00:47.820 O React 2026, os padrões e sinais de reprovação, a pergunta de onde mora a verdade, 00:00:47.820 --> 00:00:52.320 quando o efeito sobra, a trinca de cash, formulários e URL 00:00:52.320 --> 00:00:56.500 e para fechar, fronteira, segurança e o nosso checklist final. 00:00:56.500 --> 00:00:58.140 Bom, parte um. 00:00:58.140 --> 00:01:02.660 O React de 2026 é hora de dar tal terreno. 00:01:02.660 --> 00:01:08.180 O antídoto mais forte contra código defasado de IA é a gente saber exatamente a de estar pisando. 00:01:08.180 --> 00:01:14.420 Então, vamos colocar os fatos na mesa todos cravados nas documentações oficiais de agosto de 2026. 00:01:14.420 --> 00:01:19.420 Hoje, a versão estável do React é a 19.2, de outubro de 2025, 00:01:19.420 --> 00:01:23.860 com aquele patch 19.2.7, que saiu em junho de 2026. 00:01:23.900 --> 00:01:28.820 Isso quer dizer que React 19.3 ou 20 simplesmente não existem, tá? 00:01:28.820 --> 00:01:34.140 O React Compiler também já é versão 1.0 estável desde sete de outubro de 2025, 00:01:34.140 --> 00:01:37.900 fazendo sozinha aquela memorização que a gente cansava de fazer na mão. 00:01:37.900 --> 00:01:43.740 Para o Next.js, a versão estável da vez é a 16.3, lançada em 3 de agosto de 2026. 00:01:43.740 --> 00:01:45.820 Ah, e um detalhe curioso de bastidor. 00:01:45.820 --> 00:01:50.540 Desde 24 de fevereiro de 2026, o React não é mais da meta, não. 00:01:50.540 --> 00:01:53.460 Ele agora é governado pela React Foundation. 00:01:53.460 --> 00:01:55.900 Esses são os números que balizam a nossa realidade. 00:01:55.900 --> 00:01:59.980 E por falar em números, esse aqui é absolutamente inegociável. 00:01:59.980 --> 00:02:02.300 16.2.11. 00:02:02.300 --> 00:02:03.900 Por que isso importa tanto? 00:02:03.900 --> 00:02:07.540 Não é só para o seosismo de versão, é segurança purinha. 00:02:07.540 --> 00:02:15.100 Em 20 de julho de 2026, o Next.js soltou um patch crítico que corrigiu nove vulnerabilidades diferentes de uma vez só, 00:02:15.100 --> 00:02:18.540 sendo duas delas bem severas ali na parte da Server Reactions. 00:02:18.540 --> 00:02:22.020 Ou seja, essa versão 16.2.11 é o piso mínimo. 00:02:22.020 --> 00:02:25.900 O time tem que barrar qualquer pacote da IA que vem abaixo disso. 00:02:25.900 --> 00:02:27.020 Certo, parte 2. 00:02:27.020 --> 00:02:28.860 Padrões e sinais de reprovação. 00:02:28.860 --> 00:02:30.460 O nosso fluxo de leitura. 00:02:30.460 --> 00:02:33.940 Tirando a versão do caminho, a gente sobe para a camada visual. 00:02:33.940 --> 00:02:37.780 Aqui, revisar um componente é puro reconhecimento de padrão. 00:02:37.780 --> 00:02:40.700 O fluxo ideal tem só três passos bem diretos. 00:02:40.700 --> 00:02:41.980 Chegou código novo? 00:02:41.980 --> 00:02:42.740 Passo 1. 00:02:42.740 --> 00:02:45.140 Identifica qual padrão a IA tentou aplicar. 00:02:45.140 --> 00:02:46.020 Passo 2. 00:02:46.020 --> 00:02:48.300 Confere se o critério da arquitetura está batendo. 00:02:48.300 --> 00:02:49.140 Passo 3. 00:02:49.140 --> 00:02:51.460 Caça ativamente o sinal de reprovação. 00:02:51.460 --> 00:02:55.180 É um funil rápido, implacável e que não deixa erro bobo passar. 00:02:55.180 --> 00:02:57.140 E o que a gente está procurando exatamente? 00:02:57.140 --> 00:02:59.380 A gente mapeou cinco maiores vilões. 00:02:59.380 --> 00:03:02.180 Primeiro, o componente com props. 00:03:02.180 --> 00:03:06.180 Se a lista de propriedades não para de crescer a cada tela nova que entra, 00:03:06.180 --> 00:03:06.940 reprova. 00:03:06.940 --> 00:03:08.500 Abstração quebrou. 00:03:08.500 --> 00:03:11.180 Segundo, composição por children. 00:03:11.180 --> 00:03:13.940 Se tem um invólucro visual que serve só para dar espaçamento 00:03:13.940 --> 00:03:17.620 e ele está recebendo dado do que vai lá dentro, pode devolver. 00:03:17.620 --> 00:03:19.660 Terceiro, estado local. 00:03:19.660 --> 00:03:23.980 Se o código tenta alterar o dom na mão em vez de usar um bom e velho use-state 00:03:23.980 --> 00:03:28.060 para deixar o react cuidar da reconciliação, é reprovação na hora. 00:03:28.060 --> 00:03:30.700 Quarto, a famosa lista com o map. 00:03:30.700 --> 00:03:32.620 A documentação não perdoa. 00:03:32.620 --> 00:03:35.100 Se aqui da lista for um índice numérico do array, 00:03:35.100 --> 00:03:39.700 ou pior, um method random, o dom inteiro vai ser recriado destruindo a performance. 00:03:39.700 --> 00:03:40.660 Não passa. 00:03:40.660 --> 00:03:42.700 E quinto, campo controlado. 00:03:42.700 --> 00:03:45.060 Se o erro do formulário só acende na cor da borda, 00:03:45.060 --> 00:03:48.140 ou só valida quando clica em enviar, está incorreto. 00:03:48.140 --> 00:03:49.900 Avançando para parte 3. 00:03:49.900 --> 00:03:51.220 Onde mora a verdade? 00:03:51.220 --> 00:03:53.460 A nossa pergunta de 30 segundos. 00:03:53.460 --> 00:03:57.580 Saindo do visual, a gente esbarra no que realmente quebra a interface. 00:03:57.580 --> 00:03:59.260 A arquitetura de dados. 00:03:59.260 --> 00:04:02.100 E a gente tem uma defesa quase perfeita aqui. 00:04:02.100 --> 00:04:05.580 Antes de aprovar qualquer linha que tenha a palavra estate, 00:04:05.580 --> 00:04:08.180 faça essa pergunta de 30 segundos. 00:04:08.180 --> 00:04:10.660 Onde mora a verdade deste dado? 00:04:10.660 --> 00:04:14.420 Se a gente não soubesse para, se a informação pertence só aquele botãozinho, 00:04:14.420 --> 00:04:15.740 se pertence ao servidor, 00:04:15.740 --> 00:04:18.260 ou a sessão inteira, é batata. 00:04:18.260 --> 00:04:20.940 O produto vai acabar mostrando um saldo na página inicial 00:04:20.940 --> 00:04:24.060 e um número completamente diferente lá no carrinho. 00:04:24.060 --> 00:04:28.460 Na prática, em 2026, essa verdade tem 5 casas certas. 00:04:28.460 --> 00:04:32.460 Se o estado é local, tipo uma bin ativa, ele mora no use-state. 00:04:32.460 --> 00:04:35.580 Se é um estado derivado como o cálculo do total de uma compra, 00:04:35.580 --> 00:04:37.060 a gente não duplica estado. 00:04:37.060 --> 00:04:39.940 A gente só calcula na hora de renderizar, e ponto. 00:04:39.940 --> 00:04:43.860 Se é compartilhado pela aplicação, vai para o context ou para o Zustand. 00:04:43.900 --> 00:04:45.580 Agora, se for dado de servidor, 00:04:45.580 --> 00:04:48.540 isso definitivamente não pertence ao componente. 00:04:48.540 --> 00:04:51.700 Tem que morar numa ferramenta robusta, como o Time Stack Query. 00:04:51.700 --> 00:04:55.860 E o quinto lugar que a galera adora esquecer o estado da URL. 00:04:55.860 --> 00:04:57.140 Usando a biblioteca NUX, 00:04:57.140 --> 00:04:59.460 a gente garante que aquele filtro maroto de pesquisa 00:04:59.460 --> 00:05:01.020 funcione direto no link, 00:05:01.020 --> 00:05:04.700 para a pessoa poder copiar e compartilhar no chat sem quebrar nada. 00:05:04.700 --> 00:05:08.140 E olha só, a gente não está tirando essas ferramentas da cartola. 00:05:08.140 --> 00:05:13.500 Pegando os dados do registro NPM na semana de 9 a 15 de agosto de 2026, 00:05:13.500 --> 00:05:16.540 o mercado endossa isso de forma ex-magadora. 00:05:16.540 --> 00:05:21.580 O Time Stack Query passou de incríveis 55 milhões de download numa única semana. 00:05:21.580 --> 00:05:25.300 O Zustand vem logo colado ali, com mais de 44 milhões. 00:05:25.300 --> 00:05:27.900 JTi está mais atrás com 4 milhões e pouco. 00:05:27.900 --> 00:05:30.980 Então, essas ferramentas não são tendências de momento. 00:05:30.980 --> 00:05:35.620 Elas são a realidade corporativa absoluta que a gente precisa exigir na nossa pilha. 00:05:35.620 --> 00:05:37.300 Muito bem, parte 4. 00:05:37.300 --> 00:05:38.820 Quando o efeito sobra. 00:05:38.820 --> 00:05:40.620 O critério oficial. 00:05:40.620 --> 00:05:44.460 Chegamos no rook mais abusado e perigoso do ecossistema todo. 00:05:44.460 --> 00:05:48.860 Mas a boa nitícia é que a documentação oficial é muito taxativa sobre ele. 00:05:48.860 --> 00:05:53.220 O efeito é única e exclusivamente uma válvula de escape 00:05:53.220 --> 00:05:56.460 para sincronizar o componente com o sistema externo. 00:05:56.460 --> 00:05:59.260 Pode ser o dom do navegador, uma recissão de rede bruta 00:05:59.260 --> 00:06:01.660 ou um widget que nem é de react. 00:06:01.660 --> 00:06:03.100 A regra para o time é simples. 00:06:03.100 --> 00:06:04.700 Se a IA mandou um efeito, 00:06:04.700 --> 00:06:07.540 manda ela explicar e dar um nome do sistema externo. 00:06:07.540 --> 00:06:09.260 Não tem sistema externo válido? 00:06:09.260 --> 00:06:12.020 O código volta para a correção na mesma hora. 00:06:12.020 --> 00:06:15.300 E para não ter dúvida nenhuma na hora de revisar, olha a diferença. 00:06:15.300 --> 00:06:18.540 Se a lógica tem que acontecer porque rolou uma interação, 00:06:18.540 --> 00:06:20.460 tipo o clique de um mouse no botão, 00:06:20.460 --> 00:06:23.820 isso é responsabilidade do evento, o event handler. 00:06:23.820 --> 00:06:28.220 Agora, se a lógica tem que rodar só pelo simples fato da tela ter aparecido na cara do usuário, 00:06:28.220 --> 00:06:30.060 aí sim é um effect. 00:06:30.060 --> 00:06:32.300 IAs vivem tentando fazer formatação de dado 00:06:32.300 --> 00:06:34.980 e transformar listas inteiras lá dentro do effect. 00:06:34.980 --> 00:06:38.140 Quando detectarem isso, é só reprovar citando esse critério. 00:06:38.140 --> 00:06:39.620 Quase na reta final. 00:06:39.620 --> 00:06:40.740 Parte 5. 00:06:40.740 --> 00:06:43.500 Cache, formularios e URL. 00:06:43.500 --> 00:06:46.060 Nossas ferramentas de ecossistema. 00:06:46.060 --> 00:06:49.020 Isso nos puxa direto para um erro de principiante. 00:06:49.020 --> 00:06:51.260 Sabe quando a gente precisa buscar dados no servidor 00:06:51.260 --> 00:06:53.980 e o código parece remendado com fita adesiva? 00:06:53.980 --> 00:06:56.020 A própria documentação do tongue stack query 00:06:56.020 --> 00:06:59.540 dá uma alfinetada nisso criticando a tentativa de juntar manualmente 00:06:59.540 --> 00:07:02.100 estado de componente com o efeito colateral. 00:07:02.100 --> 00:07:03.820 É aquele cenário de terror, 00:07:03.820 --> 00:07:07.940 um fetch solto enfiado num use state dentro de um use effect. 00:07:07.940 --> 00:07:12.220 Isso destrói a camada de cache e reescreve a roda de um jeito terrível. 00:07:12.220 --> 00:07:13.700 Viu isso entregue pela IA? 00:07:13.700 --> 00:07:15.380 É reprovação total. 00:07:15.380 --> 00:07:17.260 Para garantir a qualidade corporativa, 00:07:17.260 --> 00:07:20.420 a nossa entrega tem que ter nomes e versões exatas. 00:07:20.420 --> 00:07:21.900 A equipe deve cobrar. 00:07:21.900 --> 00:07:25.020 tongue stack query versão 5.10.4 00:07:25.020 --> 00:07:26.940 para cuidar desse cache de servidor, 00:07:26.940 --> 00:07:29.620 lembrando de novo que não existe versão 6. 00:07:29.620 --> 00:07:31.060 Para formular os pesados, 00:07:31.060 --> 00:07:34.500 react hook forme na versão 7.850 00:07:34.500 --> 00:07:36.060 e aqui vai um detalhe vital. 00:07:36.100 --> 00:07:38.700 Tem que usar expressamente o modo on tote. 00:07:38.700 --> 00:07:40.940 Se deixar de fora, o teclado vai ficar travando 00:07:40.940 --> 00:07:43.540 e engasgando a cada letra digitada. 00:07:43.540 --> 00:07:47.580 E mais uma vez, o pacote nux na versão 2.9.6 00:07:47.580 --> 00:07:50.060 para marrar direitinho o estado na URL. 00:07:50.060 --> 00:07:51.340 O último parada, 00:07:51.340 --> 00:07:53.260 parte 6, fronteiras, 00:07:53.260 --> 00:07:55.700 segurança e o nosso check list 00:07:55.700 --> 00:07:58.060 com os critérios finais de aceite. 00:07:58.060 --> 00:07:59.500 A gente chegou nas linhas de segurança 00:07:59.500 --> 00:08:01.820 absolutas da nossa arquitetura. 00:08:01.820 --> 00:08:04.580 O next.js tem barreiras muito claras. 00:08:04.580 --> 00:08:07.180 A IA não pode sair espalhando use client 00:08:07.180 --> 00:08:08.420 no topo de tudo que arquivo 00:08:08.420 --> 00:08:10.420 só para mascarar erro de compilação. 00:08:10.420 --> 00:08:13.060 Essa marcação define uma fronteira estrita 00:08:13.060 --> 00:08:16.940 e exige propriedades que possam ser totalmente serializáveis. 00:08:16.940 --> 00:08:18.660 Já do outro lado, o use server, 00:08:18.660 --> 00:08:20.420 que define as nossas server functions, 00:08:20.420 --> 00:08:22.660 tem uma exigência pesada de segurança. 00:08:22.660 --> 00:08:24.940 Ele precisa obrigatoriamente autenticar a chamada, 00:08:24.940 --> 00:08:26.860 lendo de cookies ou de headers. 00:08:26.860 --> 00:08:28.220 A gente nunca, jamais, 00:08:28.220 --> 00:08:30.220 passa um token de segurança cru solto 00:08:30.220 --> 00:08:31.740 como parâmetro de função. 00:08:31.740 --> 00:08:34.020 Isso é blindagem básica para ir para o ar. 00:08:34.060 --> 00:08:36.620 Então, juntando tudo isso em um playbook prático 00:08:36.620 --> 00:08:38.580 para a equipe usar no próximo ticket, 00:08:38.580 --> 00:08:39.660 a receita é essa aqui. 00:08:39.660 --> 00:08:42.740 Primeiro, exigir sempre React 19.2 00:08:42.740 --> 00:08:46.020 e aquele piso mínimo do next 16.2.11. 00:08:46.020 --> 00:08:50.020 Segundo, rodar a checagem rigorosa dos 5 padrões visuais. 00:08:50.020 --> 00:08:51.980 Terceiro, cobrar a Thunstack Query 00:08:51.980 --> 00:08:53.780 para todo o dado de servidor. 00:08:53.780 --> 00:08:56.740 Quarto, se rolar tabela cheia de dados complexos, 00:08:56.740 --> 00:08:59.060 a IA tem que usar Thunstack Table V9 00:08:59.060 --> 00:09:01.700 declarando a função Table Features bem chuta, 00:09:01.700 --> 00:09:02.940 só para o que precisa, 00:09:02.940 --> 00:09:04.700 deixando os modos legais para trás. 00:09:04.700 --> 00:09:06.220 E, quinto, nos testes, 00:09:06.220 --> 00:09:08.100 a garantia é construir as verificações 00:09:08.100 --> 00:09:10.300 usando a consulta semântica Get By Role, 00:09:10.300 --> 00:09:11.660 que já denuncia de cara 00:09:11.660 --> 00:09:14.380 se a tela que a IA entregou é acessível ou não. 00:09:14.380 --> 00:09:16.580 Para fechar e já colocar e seguir a prova, 00:09:16.580 --> 00:09:17.820 fica o desafio. 00:09:17.820 --> 00:09:19.500 Pega agora o último arquivo 00:09:19.500 --> 00:09:21.020 que o agente de inteligência artificial 00:09:21.020 --> 00:09:22.900 entregou aí para o time da Lead Lovers. 00:09:22.900 --> 00:09:26.100 Abra o código e pergunta de forma bem sincera 00:09:26.100 --> 00:09:28.060 qual versão de React essa entrega 00:09:28.060 --> 00:09:29.580 realmente está assumindo. 00:09:29.580 --> 00:09:31.220 Procura por aqueles resquícios chatos 00:09:31.220 --> 00:09:32.740 de dois anos atrás, 00:09:32.740 --> 00:09:35.180 passa o pente fino com as regras de 2026 00:09:35.180 --> 00:09:36.460 que a gente conversou 00:09:36.460 --> 00:09:39.900 e repara no nível das revisões subindo de imediato. 00:09:39.900 --> 00:09:41.900 Um excelente trabalho para a equipe.