DEV Community: Victor Geruso Gomes

Testes de Interface com Playwright e MCP no Windsurf

Victor Geruso Gomes — Fri, 09 Jan 2026 19:06:49 +0000

O desenvolvimento de testes End-to-End (E2E) sempre teve dois grandes gargalos: a fragilidade dos seletores e a manutenção constante. A integração do Playwright dentro do Windsurf IDE, potencializada pelo MCP, ataca esses problemas transformando o editor de código em um agente ativo capaz de navegar, testar e corrigir sua própria interface.

1. O Papel de Cada Peça

Para entender a magia, precisamos definir os atores:

Playwright: O framework de testes mais moderno da atualidade. Ele permite automação de navegadores (Chromium, Firefox, WebKit) com extrema velocidade e confiabilidade.
Windsurf IDE: O primeiro IDE "agêntico". Ele não apenas completa código; ele entende o contexto profundo do seu projeto.
MCP (Model Context Protocol): É a "cola" técnica. O MCP é o padrão que permite que a IA do Windsurf se conecte a ferramentas externas. No contexto de testes, o MCP permite que a IA não apenas escreva o código do teste, mas também execute comandos do Playwright, leia os relatórios de erro e inspecione o navegador.

2. Como o MCP Transforma o Workflow

A grande diferença de usar o Playwright no Windsurf (em comparação ao Copilot ou ChatGPT tradicional) é a capacidade de ação via MCP.

A. Criação de Testes Contextualizada

Ao invés de pedir "crie um teste de login", o Windsurf (via MCP) pode ler seus arquivos de componentes (ex: Login.tsx ou Button.vue). Ele entende os IDs, as classes e a lógica de negócio antes de escrever a primeira linha do teste.

Resultado: Testes que funcionam na primeira tentativa, pois usam os seletores corretos existentes no seu código.

B. O Ciclo "Escrever, Rodar, Corrigir"

Graças à integração de ferramentas do MCP, o Windsurf pode:

Escrever o arquivo de teste spec.ts.
Executar o comando npx playwright test no terminal integrado.
Ler a saída do terminal e o relatório de erro se o teste falhar.
Auto-corrigir: Se o Playwright reclamar que um elemento não estava visível, a IA analisa o erro e sugere (ou aplica) a correção, como adicionar um await expect(...).toBeVisible().

3. Vantagens Práticas no Dia a Dia

Funcionalidade	Benefício Direto
Self-Healing (Auto-cura)	Quando você altera o nome de um botão no front-end, o Windsurf detecta a quebra no teste e sugere a atualização do seletor automaticamente.
Geração de Page Objects	Peça para a IA analisar uma página e criar um Page Object Model (POM) completo para o Playwright. O MCP garante que ele siga a estrutura de pastas do seu projeto.
Depuração de "Flaky Tests"	Testes intermitentes são o pesadelo de QA. O Windsurf pode analisar logs de múltiplas execuções para identificar condições de corrida (race conditions) e sugerir esperas explícitas.

4. Exemplo de Prompt para o Windsurf

Para ver isso em ação, você pode usar um prompt "agêntico" no Cascade (o chat do Windsurf):

"Analise o arquivo CheckoutForm.tsx. Crie um teste E2E usando Playwright que simule um usuário preenchendo o cartão de crédito com dados inválidos e verifique se a mensagem de erro correta aparece. Em seguida, execute o teste e corrija qualquer erro que aparecer."

Conclusão

O uso de MCP com Playwright no Windsurf deixa de ser sobre "escrever scripts" e passa a ser sobre "gerenciar a qualidade". Você atua como o arquiteto dos testes, enquanto a IA cuida da implementação, execução e manutenção da infraestrutura, garantindo interfaces mais robustas com uma fração do esforço manual.

Análise comparativa dos principais serviços de TTS (Text To Speech)

Victor Geruso Gomes — Mon, 04 Aug 2025 15:40:22 +0000

A tecnologia Text-to-Speech (TTS) revolucionou a interação digital, permitindo que os aplicativos se comuniquem de forma mais natural e acessível. A capacidade de converter texto em fala com nuances e expressividade humanas se tornou um diferencial competitivo, impulsionando a demanda por soluções robustas em diversos setores, como e-learning, assistentes virtuais e atendimento ao cliente.

Este artigo apresenta uma análise comparativa dos principais serviços de TTS disponíveis no mercado: AWS Polly, Google Cloud Text-to-Speech (TTS) e OpenAI Audio TTS. O objetivo é fornecer uma recomendação informada para auxiliar na tomada de decisão tecnológica.

Principais Descobertas

Qualidade da Voz: O Google Cloud TTS, com suas vozes WaveNet e Chirp 3 HD, geralmente oferece um realismo e expressividade superiores. A OpenAI, embora inovadora, tem enfrentado inconsistências de qualidade, como flutuações de volume e distorção.
Preço: AWS Polly e Google Cloud TTS utilizam modelos de precificação transparentes baseados em caracteres, com planos gratuitos que facilitam a experimentação. A OpenAI adota uma estrutura de precificação baseada em tokens ou minutos de áudio, o que pode tornar a estimativa de custos menos intuitiva.

Análise Detalhada dos Sistemas TTS

AWS Polly

O AWS Polly utiliza tecnologias avançadas de deep learning para sintetizar fala natural.

Prós Técnicos:

Tecnologias de Voz Avançadas: Oferece motores de voz como o Neural Text-to-Speech (NTTS) para vozes mais expressivas e naturais, além de vozes Standard, Long-Form e Generative para diferentes casos de uso.
Suporte Robusto a SSML: Permite controle granular sobre a saída de áudio com tags SSML, ajustando pitch, volume, taxa de fala, ênfase e adicionando pausas personalizadas.
Speech Marks para Sincronização Precisa: Fornece informações detalhadas de temporização para cada palavra ou frase, ideal para sincronização labial, destaque de texto em tempo real (karaokê, e-learning) ou outras experiências multimídia.
Integração Nativa com o Ecossistema AWS: Integra-se com outros serviços AWS como Lambda e S3, simplificando a arquitetura e o deployment para quem já usa AWS.
Personalização de Lexicon: Permite definir dicionários de pronúncia personalizados para melhorar a pronúncia de palavras específicas, nomes próprios e termos técnicos.

Contras Técnicos:

Limitações de SSML em Certos Tipos de Voz: Alguns tags avançados de SSML podem não estar disponíveis para todos os tipos de voz.
Limites de Caracteres e Duração de Áudio: Limite de 3000 caracteres faturáveis por requisição e saída de áudio limitada a 10 minutos, exigindo divisão do conteúdo para textos mais longos.
Throttling e Limites de Concorrência: Aplica quotas e limites de taxa (e.g., 8 transações por segundo para vozes Neurais), exigindo tratamento de erros e retries em aplicações de alta demanda.
Complexidade Inicial de Setup: A configuração inicial pode ser complexa e demorada, envolvendo permissões IAM e funções Lambda.

Google Cloud Text-to-Speech (TTS)

Reconhecido por sua tecnologia avançada de machine learning e redes neurais para gerar fala de alta qualidade.

Prós Técnicos:

Vozes de Alta Qualidade (WaveNet, Neural2, Chirp 3 HD): As vozes WaveNet são geradas por modelos treinados com áudio humano real, resultando em ênfase e inflexão mais humanas. As vozes Neural2 e Chirp 3 HD são otimizadas para conversas espontâneas e naturais.
Controle SSML Abrangente: Oferece personalização fina da fala com SSML, controlando pausas, tom e pronúncia.
Recursos Avançados de Voz: Suporta funcionalidades como diálogo multi-speaker. Menciona capacidades de clonagem de voz, uma característica não disponível no AWS Polly.
Integração com o Ecossistema Google Cloud: Integra-se com outros produtos e serviços do Google Cloud, otimizando fluxos de trabalho.
Escalabilidade da API: Projetada para fácil implementação e escalabilidade, adaptando-se à demanda.

Contras Técnicos:

Dependência de Conectividade: Exige conexão com a internet, o que pode ser uma limitação para aplicações offline ou em ambientes com conectividade instável.
Limitações de Personalização Profunda da Voz: A personalização profunda para características vocais únicas pode ser restrita comparada a ferramentas mais especializadas.
Inconsistências de Pronúncia Ocasionais: Pode pronunciar incorretamente palavras incomuns ou nomes próprios, exigindo ajustes manuais via SSML ou lexicons.
Limites de Conteúdo e Requisições: Limites para o comprimento do áudio em requisições síncronas (aproximadamente 1 minuto) e assíncronas (aproximadamente 480 minutos), além de um limite de 10 MB para arquivos de áudio locais.

OpenAI Audio TTS

Representa a incursão da OpenAI na síntese de fala, aproveitando seus modelos avançados de IA.

Prós Técnicos:

Modelos de Ponta (TTS-1 e TTS-1-HD): Impulsionado por modelos avançados de machine learning, focados em "ótima qualidade", "máxima precisão" e capacidade de lidar com "tons emocionais variados".
Geração em Tempo Real e Streaming: A API é capaz de gerar áudio em tempo real e suporta streaming, crucial para aplicações conversacionais e interativas de baixa latência.
Flexibilidade de Arquitetura: Oferece arquitetura multimodal speech-to-speech (S2S) para interações de baixa latência e uma arquitetura "chained" para maior controle e transparência.

Contras Técnicos:

Problemas de Qualidade: Foi constatado que acontecem "regressões notáveis" com o modelo gpt-40-mini-tts, incluindo flutuações de volume, longas pausas aleatórias, repetição de texto e distorção de áudio.
Suporte a Idiomas Menos Explícito: A documentação não apresenta uma lista explícita e detalhada de idiomas e sotaques suportados, o que pode gerar incerteza para projetos multilíngues.
Controle SSML Menos Detalhado na Documentação: Os dados não fornecem detalhes extensivos sobre o suporte a SSML, sugerindo um controle menos granular sobre a fala ou documentação menos madura.
Limites de Taxa (Rate Limits): A API impõe limites de taxa (RPM, RPD, TPM, TPD) que podem exigir implementação de lógica de exponential backoff para evitar erros.

Comparação de Preços

Cada Serviço possui diversos modelos a serem escolhidos desde os mais roboticos até o mais naturais sendo os modelos iniciais mais baratos porem com uma entrega menos natural. Já os mais naturais com foco em detalhes e tonalidades de voz, pussuem mais qualidade na entrega, porem mais caros.

O AWS Polly e o Google TTS tem um faixas de preços parecidas. Os dois após o Tire Gratuito que é de 1 Milhão de Caracteres, passam a cobrar respectivamente entre $30 USD - $160 USD (dependendo do Modelo escolhido) a cada 1 Milhão de caracteres.

Já o da OpenAI ele tem um preço mais baixo, cobrado a cada 1 Milhão de Token (que dependendo do idioma é cada palavra do texto) de entrada, que custa ~$0.60 USD e de saída ~$0.015 USD por minuto gerado, porém a qualidade dos seus modelos são bem mais baixas.

Os valores aqui mencionados são dos modelos mais naturais não levamos em consideração o valor dos mais inferiores, que possuem menos tratamentos.

Realismo dos Resultados (Qualidade da Voz)

O realismo e a naturalidade da voz sintetizada são primordiais para a satisfação do usuário.

O AWS Polly, Elogiado por suas vozes neurais realistas, que são difíceis de distinguir de vozes humanas. Oferece dezenas de vozes em mais de 30 idiomas. No entanto, avaliações de MOS (Mean Opinion Score) indicam pontuações ligeiramente inferiores ao Google Cloud TTS em algumas categorias que é Amplamente reconhecido por suas vozes de alta qualidade, especialmente as vozes WaveNet, que resultam em ênfase e inflexão mais humanas. As vozes Chirp 3 HD geram conversas espontâneas e naturais. Geralmente oferece maior qualidade de voz em categorias como ficção e não-ficção em comparação com o AWS Polly. Já O OpenAI Audio TTS Promete gerar fala "humana" que lida com nuances de tom. No entanto, os resultados indicam problemas de qualidade, como flutuações de volume e distorção. Testes comparativos de pronúncia de homógrafos mostraram que o OpenAI TTS teve mais falhas que o AWS Polly.

Quantidade de Idiomas Suportados

A abrangência de idiomas é fundamental para aplicações globais. O AWS Polly, Suporta mais de 30 idiomas e oferece mais de 60 vozes. A documentação lista especificamente uma vasta gama de idiomas e suas variantes regionais, oferecendo clareza para o desenvolvimento multilíngue.

O Google Cloud Text-to-Speech (TTS), Oferece suporte a uma ampla gama de idiomas e vozes, com documentação detalhada listando idiomas, códigos BCP-47 e tipos de voz. É elogiado por seu suporte multilíngue.

E o OpenAI Audio TTS, Afirma que seus modelos "são capazes de produzir resultados de alta qualidade em múltiplas línguas". No entanto, a documentação não apresenta uma lista explícita e detalhada de idiomas e sotaques suportados, o que pode gerar incerteza e exigir testes extensivos para projetos multilíngues, porem em testes foi constatado que a maioria dos idiomas são definidos de forma automatica detectados no texto enviado, facilitando a configuração no momento da utilização.

Conclusão e Recomendação

A escolha do sistema TTS ideal depende de um balanço entre qualidade de voz, custo, facilidade de integração e os requisitos específicos do projeto.

O Google Cloud Text-to-Speech se destaca pela qualidade superior de suas vozes e uma estrutura de preços competitiva com um free tier generoso. É a melhor opção para projetos onde a qualidade de voz é a prioridade máxima e a aplicação opera em um ambiente com conectividade estável.

O AWS Polly oferece uma solução robusta e flexível, com diversas vozes e suporte abrangente a SSML, além da funcionalidade de Speech Marks para sincronização precisa. Sua integração nativa com o ecossistema AWS é uma grande vantagem para equipes já familiarizadas com a plataforma.

O OpenAI Audio TTS representa a inovação no campo da síntese de fala, com modelos de ponta que prometem lidar com nuances emocionais e oferecer geração em tempo real. No entanto, ainda enfrenta desafios em termos de consistência da qualidade de voz. É mais adequado para quem busca explorar as últimas capacidades de IA e está disposto a lidar com uma tecnologia em evolução.

Em resumo, para a maioria dos projetos que buscam uma combinação ideal de satisfação dos resultados (qualidade), preço e facilidade no consumo, o Google Cloud Text-to-Speech se posiciona como a escolha mais vantajosa no momento atual. Para usuários AWS existentes, o AWS Polly oferece uma alternativa sólida com integração nativa e recursos valiosos. O OpenAI Audio TTS é mais adequado para quem prioriza a exploração de novas tecnologias e está preparado para os desafios de uma plataforma em rápido desenvolvimento.

O Laboratório e o [FAILED]

Victor Geruso Gomes — Fri, 20 Jun 2025 19:33:36 +0000

Olha só que aventura! A alguns dias, resolvi bancar o cientista maluco e me meti num laboratório com o Ollama no meu Ubuntu. A ideia era legal: instalar um modelo de IA. e testar alguns prompts voltados para desenvolvimento, O problema? Exagerei na dose e acabei com o codellama:70b da Meta.

Juro que não pensei nas consequências! Instalei essa belezinha direto no container Docker do Ollama. Resultado? Um modelo de 39GB tentando se espremer num SSD de 124GB que já tinha coisa... Nem preciso dizer que a conta não fechou, né? Meu PC morreu na hora! Sim, eu sei, foi uma loucura tentar rodar uma IA de 70 bilhões de parâmetros num SSD tão pequeno! 😵‍💫

Quando tentei reiniciar meu bixano, a tragédia: [FAILED] Filed to start gdm.service - GNOME Display Manager. Minha interface Gnome simplesmente se recusou a voltar à vida por falta de espaço em disco para o cache. Mas calma que a solução foi mais satisfatória do que eu esperava!

Resgatando o sistema

Para ressuscitar o paciente, na tela de erro que é basicamente um terminal, basta dar um CTRL + ALT + F2. Ele vai pedir seu login e senha. Depois de logar, você terá um terminal livre para executar os comandos e resolver o problema.

Aqui é onde a mágica acontece, meus amigos! Vamos entrar em ação com alguns comandos shell:

1- Pare o container Ollama (se estiver rodando):

docker stop [ID do container]

2- Remova o container Ollama:

docker rm [ID do container]

3- Elimine o volume do Ollama: Isso é crucial, pois o modelo assassino ainda está ocupando espaço no disco!

docker volume rm ollama

Isso vai liberar um espaço e tanto (no meu caso, mais de 40GB!).

4- Faça uma boa atualização no sistema: Com o espaço liberado, é hora de dar um banho de loja no seu sistema! Isso vai trazer de volta umas bibliotecas que o Linux "matou" por causa do disco cheio.

sudo apt update && sudo apt full-upgrade

Não se esqueça de digitar Y quando ele perguntar!

5- Reinicie e seja feliz! Depois da atualização, é só mandar ver:

sudo reboot

E pronto! Sua interface estará ressuscitada e você poderá ser feliz novamente! 😉

E aí, gostou das dicas? Já passou por algo parecido? Me conta nos comentários!

Pare de instalar bancos de dados

Victor Geruso Gomes — Sat, 16 Mar 2024 04:31:22 +0000

Sim, pare de usar bancos de dados instalados na raiz do seu sistema, para melhor gerenciamento, use-os com o Docker. Neste artigo irei mostrar como executar e gerenciar máquinas virtuais de três conhecidos bancos de dados e usa-los de forma local.

O que é o Docker?

O Docker é um software que gera a implantação de aplicativos em maquinas virtuais (containers), permitindo o uso desse, em diferentes ambientes complexos. No Docker, conteinerizar um sistema, permite que o mesmo seja usado em diversos ambientes, poupando o usuário de resolver problemas de compatibilidade, dando a possibilidade do uso padronizado no Windows, no Mac OS e no Linux, pois o mesmo aplicativo é sempre executado da mesma forma.

Raiz vs Docker

Na raiz o usuário precisa instalar uma versão especifica do banco desejado de forma padrão, deixando o ambiente local engessado, podendo causar um problema grande caso o mesmo necessite de uma versão diferente do SGBD em algum outro projeto.

Já com o Docker o mesmo SGBD de versões diferentes podem rodar cada um em um container especifico, facilitando a troca da versão quando necessária. Acredite, isso facilita muito e evita a dor de cabeça de ter que desinstalar uma versão do banco para instalar uma outra.

A prática

Se você já tem um banco instalado na sua raiz não precisa desinstala-lo se não quiser, só na hora de gerar seu container, basta mudar a porta local no comando, o pré requisito para este artigo é simples, tenha o Docker instalado na sua máquina.

Antes de qualquer comando precisamos aprender um pouco sobre a composição de um comando básico para rodar um container.

Para transformar uma imagem num container precisamos apenas rodar:

docker run [nome da imagem]:[versao da imagem]

Entre o comando e o nome da imagem, existem flags importantes que são muito usadas para melhorar ainda mais a montagem da VM.

--name [nome do container]: cria um nome personalizado para o container;
-e [variavel de ambiente]=[valor]: seta uma variável de ambiente no sistema;
-p [porta local]:[porta padrão do container]: cria uma ponte entre a porta padrão do container, com uma porta local livre;
-d: essa flag indica que o container irá rodar em segundo plano;

MySQL

Vamos para o comando que roda o container para o MySQL, um dos bancos mais populares, Para isso, basta rodar o comando:

docker run --name mysql-latest -p 3306:3306 -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql:latest

Com esse comando, é criado um container onde, startado, pode ser acessado pelo endereço, mysql://localhost:3306.

PostgreSQL

Vamos para o comando que roda o container para o PostgreSQL, banco de dados Open Source muito popular, para isso, basta rodar o comando:

docker run --name postgres-latest -p 5432:5432 -e POSTGRES_PASSWORD=mysecretpassword -d postgres:latest

Com esse comando é criado um container onde, startado, pode ser acessado pelo endereço, postgres://localhost:5432.

MongoDB

Vamos agora para o MongoDB, que diferente dos últimos, é um banco de dados não relacional orientado a documentos, para isso, basta rodar o comando:

docker run --name mongo-latest -p 27017:27017 -e MONGO_INITDB_ROOT_USERNAME=root -e MONGO_INITDB_ROOT_PASSWORD=mysecretpassword -d mongo:latest

Com esse comando, é criado um container onde, startado, pode ser acessado pelo endereço, mongodb://localhost:27017.

Os containers startados, podem ser vistos em docker ps.

Conclusão

Neste artigo vimos uma forma simples de usar os bancos mais usados hoje em dia com o Docker, virtualizando os mesmos, e facilitando o dia a dia na hora de desenvolver ou manter seus projetos, esta ferramenta de virtualização, não faz esse tipo de processo somente com bancos de dados, mas ele gera muitas possibilidades com todo e qualquer tipo de projeto, basta pesquisar na ferramenta Docker Hub, essa plataforma consiste em um banco de imagens para o Docker, com diversas ferramentas e apps essenciais para nossa área.

Pare de abusar do .map()!

Victor Geruso Gomes — Mon, 25 Oct 2021 17:34:53 +0000

Tradução de "Stop abusing .map()!"

De vez em quando, quando faço revisão de código ou visito o StackOverflow, encontro trechos de código semelhantes a este:

Como você pode ver, é apenas uma iteração simples onde, para cada elemento do fruitIds array, adicionamos active classes a um determinado elemento HTML em um DOM.

Muitos programadores (especialmente os novos) não notaram nada de errado com o código acima. No entanto, há um grande problema aqui, o uso de .map(). Deixe-me explicar.

O que há de errado no .map()?

Bem, não há nada de errado com esse método de array específico. Na verdade, acho que é muito útil e envolve um dos padrões de interação, o mapeamento.

Em palavras simples, o mapeamento é uma operação que aplica uma função a cada elemento de uma coleção e retorna uma nova coleção com elementos alterados pela função mencionada. Por exemplo, se temos uma matriz de números const nums = [1, 2, 3, 4]; e gostaríamos de receber uma nova matriz de números duplicados, poderíamos mapear a matriz original para uma nova como esta (em JavaScript):

A biggerNums matriz consistiria em números da nums matriz original multiplicados por 2.

Observe como o .map() é usado, atribuímos o resultado deste método a uma nova variável chamada biggerNums. Também mencionei anteriormente que o mapeamento é uma operação que retorna uma nova coleção de elementos. E esta é a razão pela qual o trecho de código mostrado no início deste artigo está errado. O .map() retorna um novo array - sempre - e se não precisarmos desse array, não devemos usar .map() em primeiro lugar. Neste caso particular (iteração simples), um método de array diferente deve ser usado .forEach() - que é projetado especificamente para tais casos. Ele não retorna uma nova coleção, ele simplesmente percorre uma matriz e invoca uma função de retorno de chamada para cada elemento, permitindo que você faça algo para cada um deles.

Portanto, a versão correta do snippet mencionado deve ser assim:

Não precisamos de um novo array, então simplesmente iteramos sobre o fruitIds array e adicionamos a active classe a um elemento HTML para cada um dos itens do array.

Ok, mas por que eu deveria me importar? .map() é mais curto e mais fácil de escrever do que .forEach(). O que poderia dar errado?

Consequências do abuso do .map()

Uma das piores consequências do abuso do .map() é o fato de ele retornar uma nova matriz redundante. Para ser mais específico, ele retorna um novo array do mesmo tamanho daquele em que este método foi chamado. Isso significa que se tivermos um array de 1000 elementos, .map() retornará um novo array de 1000 elementos, todas às vezes.

Em JavaScript, todas as funções retornam um valor. Mesmo se não usarmos a palavra chave return, a função retornará undefined implicitamente. É assim que a linguagem foi projetada. Esta regra também se aplica a callbacks, eles também são funções.

Dito isso, vamos voltar ao exemplo original:

O que acontece aqui? Uma matriz que IDs de frutas é criada e, em seguida, mapeada para outra matriz do mesmo tamanho. Mesmo que a matriz retornada por .map() nõa seja usada, ela ocorre na memória. Esta nova matriz (não utilizada) tem a seguinte aparência:

É porque o callback passado para o .map() não possui a palavra chave return e como sabemos, se não houver return, undefined é retornado implicitamente.

É muito ruim? Muito mal. Neste exemplo específico, isso não trará consequências sérias, há apenas 3 itens no array, portanto, criar outro array de três elementos não causará problemas. No entanto, o problema surge quando lidamos com grandes matrizes de dados complexos. Se quisermos iterar em um array de cinco mil objetos e abusarmos do .map(), criamos outro array de cinco mil elementos undefineds. Assim, acabamos armazenando 10.000 elementos na memória, dos quais metade é redundante. É uma prática muito inadequada e, em alguns cenários, pode até levar à sobrecarga do aplicativo. É por isso que devemos escolher os métodos certos para as tarefas certas.

Resumo

Existem muitas práticas que são essencialmente ruins, mas as consequências negativas começarão a ser visíveis apenas a lidar com conjuntos de dados maiores. Uma dessas práticas é abuso do .map(). Ao operar em matrizes pequenas, não causará nenhum dano. Mas quando cometemos esse erro com um array maior, ele começa a sobrecarregar nosso aplicativo e pode ser muito difícil de depurar.

É por isso que nunca devemos deixar passar e sempre que vemos esse abuso, devemos cuidar disso. Espero que agora você entenda o porquê.

Texto original: https://dev.to/catchmareck/stop-abusing-map-51mj