DUMB DEV Community: Nathana Facion

O que é Module Federation?

Nathana Facion — Thu, 01 Jan 2026 14:56:19 +0000

O Module Federation é uma das funcionalidades mais poderosas introduzidas no Webpack 5. Ele mudou a forma como pensamos em arquitetura de front-end, permitindo que diferentes aplicações compartilhem código de forma dinâmica em tempo de execução.

Aqui está uma explicação detalhada para você entender o conceito, as vantagens e como ele funciona na prática.

Imagine que você tem vários micro-frontends (pequenas aplicações independentes). Antes do Module Federation, para compartilhar um componente (como um botão ou um menu) entre eles, você precisava publicar esse componente como um pacote no NPM, instalá-lo em todas as aplicações e buildar tudo novamente.

Com o Module Federation, uma aplicação pode expor parte do seu código (componentes, funções, estados) e outra aplicação pode consumir esse código sem precisar instalar nada ou buildar novamente. O código é carregado diretamente do “servidor” da aplicação de origem no momento em que o usuário acessa o site.

Conceitos Chave:

Host: A aplicação “mestre” que recebe os módulos.
Remote: A aplicação “servidora” que expõe os módulos.
Exposes: A lista de arquivos que o Remote decide compartilhar.
Remotes: A lista de endereços que o Host usará para buscar o código.

Por que ele é revolucionário?

O Module Federation resolve os principais problemas de arquiteturas de
Micro-frontends:
Independência de Deploy: Você pode atualizar o menu no “Projeto A” e ele será atualizado automaticamente no “Projeto B” (o Host), sem que você precise mexer no código do Projeto B.

Compartilhamento de Dependências: Se o Host e o Remote usam o React, o Module Federation é inteligente o suficiente para carregar o React apenas uma vez, economizando banda e memória.

Performance: Diferente de usar iframes (que são pesados e isolados), o Module Federation compartilha o mesmo contexto de execução do JavaScript.

O post ficou grande, então o restante está no site abaixo:

https://nathanafacion.substack.com/p/o-que-e-module-federation

Dominando o package.json: Como preparar sua biblioteca para o ecossistema moderno

Nathana Facion — Tue, 30 Dec 2025 20:25:59 +0000

Você finalmente terminou aquela biblioteca utilitária ou componente que resolve um problemão. Agora, quer publicar no NPM. Mas aí vem a dúvida: como garantir que ela funcione para todo mundo?

Hoje em dia, o ecossistema JavaScript está dividido entre o antigo CommonJS (CJS) e o moderno ES Modules (ESM). Se você configurar errado, seu usuário vai dar de cara com o erro: Err: Module Not Found ou require is not defined.

Neste guia, vamos dissecar o package.json perfeito.

1. O Ponto de Entrada: main vs module

Antigamente, só precisávamos do campo main. Hoje, a história é outra:

*main: * Aponta para o arquivo no formato CommonJS. É o que permite que alguém use const suaLib = require('sua-lib'). Geralmente gerado em .js puro.

module: Aponta para o arquivo no formato ES Modules. É o que permite o uso de import { funcionalidade } from 'sua-lib'. Geralmente gerado em .mjs.

Por que ter os dois? Porque você quer que sua biblioteca seja “Universal”. Se o seu usuário estiver em um projeto Legado, o main salva ele. Se estiver em um projeto moderno (como Vite ou Next.js), o module garante performance e suporte a Tree Shaking (remover código que não está sendo usado).

2. A Magia do campo exports

Este é o campo mais moderno e poderoso. Ele funciona como um “roteador” de módulos.

JSON

"exports": {
  ".": {
    "types": "./dist/index.d.ts",
    "import": "./dist/index.mjs",
    "require": "./dist/index.js"
  }
}

A ordem importa: Sempre coloque types primeiro para que o TypeScript reconheça as definições antes de tentar ler o código.

Encapsulamento: O campo exports impede que os usuários acessem arquivos internos da sua biblioteca que não deveriam ser mexidos. Se não estiver no exports, o usuário não consegue importar.

3. TypeScript e o campo types

Mesmo que você não tenha escrito sua lib em TypeScript, o arquivo .d.ts é obrigatório para uma boa experiência do desenvolvedor (DX). Sem ele, o usuário não tem o “autocompletar” no VS Code. Ele fica “no escuro” sem saber quais funções sua biblioteca oferece ou quais parâmetros elas recebem.

4. O que realmente vai para o NPM? (files)

Por padrão, quando você roda npm publish, o NPM envia quase tudo da sua pasta. Isso é ruim por dois motivos:

O pacote fica pesado (incluindo testes, arquivos de configuração e código fonte original).

Expõe sua lógica de desenvolvimento desnecessariamente.

Use o campo files para criar uma “lista branca”:


JSON

"files": [
  "dist"
]

Isso diz ao NPM: “Só leve o que estiver na pasta dist”.

5. Como automatizar tudo isso?

Não tente escrever os arquivos da pasta dist na mão. A dica de ouro é usar o tsup. Ele é um “bundler” que não precisa de configuração.

Passo a passo rápido:

Instale: npm install tsup -D

No package.json, adicione o script: "build": "tsup src/index.ts --format cjs,esm --dts"

Ao rodar npm run build, o tsup vai:

Ler seu arquivo fonte.

Gerar o .js (CommonJS).
Gerar o .mjs (ES Module).
Gerar o .d.ts (Tipagens).

Conclusão

Configurar o package.json corretamente é a diferença entre uma biblioteca profissional e uma que gera issues no GitHub em 5 minutos. Com essa estrutura, você garante que qualquer desenvolvedor, independente da tecnologia que use, consiga integrar sua solução sem atrito.

🚀 O melhor dos dois mundos: Entenda o Partial Pre-Rendering (PPR)

Nathana Facion — Mon, 29 Dec 2025 20:00:57 +0000

Você já teve que escolher entre a velocidade de uma página estática e a flexibilidade de um conteúdo dinâmico? Com o Partial Pre-Rendering (PPR), essa escolha ficou no passado.

💡 O que é o PPR?
Basicamente, o PPR permite que você combine conteúdo estático (que carrega instantaneamente) e conteúdo dinâmico (que depende de dados do usuário ou do banco) na mesma rota, sem sacrificar a performance.
Imagine uma página de produto:

A casca (Shell): Título, descrição e imagens são pré-renderizados e servidos via CDN (ultra rápido).

O conteúdo dinâmico: O carrinho de compras e as recomendações personalizadas são "encaixados" assim que ficam prontos.

🎯 Por que isso importa?
Melhor UX: O usuário vê a página imediatamente, reduzindo o bounce rate.

SEO: O conteúdo principal está lá para os bots de busca desde o milissegundo zero.

Simplicidade: Você não precisa mais decidir entre force-static ou force-
dynamic para a página toda. O PPR ainda está em estágio experimental (preview), mas já mostra como será o futuro do desenvolvimento web focado em performance extrema.

🛠️ Exemplo Prático (Next.js)
Antigamente, se você tivesse um componente dinâmico, a página inteira poderia perder o benefício do cache estático. Com PPR e React Suspense, o código fica assim:

💎 Conhecem o useImmer ?

Nathana Facion — Sat, 27 Dec 2025 23:04:21 +0000

O use-immer simplifica a vida no React. Ele permite que você "mute" o estado diretamente em uma função de atualização, e a biblioteca Immer, de forma mágica, garante a imutabilidade por baixo dos panos. Basicamente ele substitui o useState.

O Problema (Estado Aninhado):
Imagine atualizar a rua dentro de um objeto complexo: usuario.contato.endereco.rua

😫 O Jeito "Raiz" (com useState)

Para garantir a imutabilidade, você é obrigado a copiar cada nível do objeto usando ...spread:

// Usando useState (precisa de muito ...spread)

setUsuario(prev => ({
    ...prev, // Cópia Nível 1
    contato: {
       ...prev.contato, // Cópia Nível 2
       endereco: {
          ...prev.contato.endereco, // Cópia Nível 3
          rua: 'Rua B' // Finalmente, a mudança
       }
    }
}));

😎 O Jeito "que Brilha demais" (com use-immer)

Aqui, você recebe um rascunho (draft) e o trata como se fosse uma variável normal, mutando-o diretamente:
JavaScript

// Usando use-immer (simples e direto)

updateUsuario(draft => {
    // Apenas acesse e mude a propriedade, como em JS puro!
    draft.contato.endereco.rua = 'Rua B';
});

🙏 Conclusão: O use-immer elimina o código repetitivo e a chance de erros, tornando a atualização de estados profundos no React muito mais limpa e fácil de ler.

🚀 Adeus useMemo e useCallback Manuais! A Revolução do React Compiler Chegou

Nathana Facion — Sat, 27 Dec 2025 23:01:32 +0000

Estou super animada com o novo React Compiler! Para quem trabalha com React, sabe que otimizar re-renders com useMemo, useCallback e React.memo é essencial, mas muitas vezes é repetitivo e fácil de errar.
O React Compiler, lançado no React 19, muda o jogo: ele automatiza a memoização (o equivalente a useMemo/useCallback) durante o build time. O resultado?

✅ Performance Aprimorada: Otimizações automáticas que reduzem re-renders desnecessários.
✅ Código Mais Limpo: Menos boilerplate de hooks de memoização.
✅ Foco no Desenvolvimento: Podemos nos concentrar mais na lógica de negócios e menos em micro-otimizações de renderização.

Isso não é apenas código mais limpo; é uma mudança na forma como pensamos a performance no React. O Compiler está aqui para garantir que escrevamos "React puro" e ainda assim tenhamos apps rápidos por padrão!

Exemplo Prático de Como o Código Fica Mais Limpo:
Antes do Compiler (Obrigatório useCallback)

💎 Porque string & {} é o truque de UX/DX do TypeScript que você precisa!

Nathana Facion — Sat, 27 Dec 2025 23:00:21 +0000

📌 Muitas vezes, queremos um tipo que aceite literais específicos (para sugestão) e qualquer outra string (para flexibilidade).

O Problema:

Se você escreve type MyType = 'A' | 'B' | string, o TypeScript é "inteligente demais" e simplifica para apenas string, removendo as sugestões de 'A' e 'B'.

A Solução:

Usamos o (string & {}).
Essa interseção com o objeto vazio ({}) impede que o TS colapse a união para apenas string. Ele preserva a lista de literais para o IntelliSense, mantendo a porta aberta para qualquer outra string.

✨ Resultado final: Você ganha sugestão de código (IntelliSense) para os casos mais comuns, sem abrir mão da flexibilidade total da string. É um ganho enorme para a experiência do desenvolvedor!

🌟 O que é o eslint-plugin-jsx-a11y?

Nathana Facion — Sat, 27 Dec 2025 22:56:50 +0000

É um plugin do ESLint que faz uma análise estática do seu código JSX para identificar e aplicar um conjunto de regras de acessibilidade. Ele ajuda a detectar problemas potenciais antes mesmo de o código ser renderizado no navegador.

🔑 Por que ele é Importante?

O plugin ajuda a prevenir erros de acessibilidade comuns que podem excluir usuários com deficiência. Ao integrar o a11y ao seu fluxo de linting, você garante:
_Desenvolvimento Preventivo: _Corrige problemas no momento em que está escrevendo o código, o que é muito mais eficiente do que corrigir depois.
Educação Contínua: Ele atua como um guia, ensinando as melhores práticas de acessibilidade para elementos React/JSX.
Conformidade: Ajuda seu código a seguir diretrizes importantes de acessibilidade, como as WCAG (Web Content Accessibility Guidelines).

💡 Exemplos de Problemas que Ele Detecta

O plugin possui uma grande lista de regras, mas aqui estão alguns dos problemas mais comuns que ele verifica:
img sem alt: Alerta quando uma imagem não tem o atributo alt (texto alternativo), crucial para leitores de tela.
onClick sem onKeyPress/onKeyDown: Verifica se elementos interativos que usam onClick também podem ser acionados pelo teclado.
Controles de formulário sem label associado: Garante que inputs e outros controles estejam corretamente ligados a um elemento (usando htmlFor).
U*so incorreto de funções ARIA:* Valida a sintaxe e o uso dos atributos aria-.
_a (links) sem conteúdo visível:*_ Checa se links têm texto ou uma descrição ARIA.

_🤝 Complemento a Outras Ferramentas
_É importante notar que o eslint-plugin-jsx-a11y faz uma análise estática do código-fonte (JSX). Ele não testa o HTML final renderizado na página.
Por isso, ele é frequentemente usado em conjunto com ferramentas de teste de acessibilidade em tempo de execução, como:
react-axe (ou @axe-core/react): Que audita o DOM final.
jest-axe: Para testes unitários de acessibilidade após a renderização.

Resumindo: O eslint-plugin-jsx-a11y é a sua primeira linha de defesa para garantir que a acessibilidade seja parte integrante do seu processo de desenvolvimento em React.

🔑 O que é useId no React?

Nathana Facion — Sat, 27 Dec 2025 22:54:51 +0000

O useId é um Hook do React (disponível a partir da versão 18) que é usado para gerar identificadores únicos e estáveis dentro de um componente. Ele retorna uma string que é garantida ser exclusiva para aquela instância específica do componente.

🎯 Para que Serve o useId?
O principal objetivo do useId é ajudar na acessibilidade (Accessibility), especialmente para conectar elementos DOM que precisam de um ID único para funcionar corretamente.

Conexão de Elementos (Acessibilidade) É o uso mais comum. No HTML, para associar uma label (rótulo) a um campo de formulário (input), você precisa que o atributo htmlFor da label seja igual ao atributo id do input. Problema: Se você simplesmente codificar o ID, por exemplo, , e esse componente for renderizado várias vezes na mesma página (como em uma lista ou dentro de outros componentes), você terá IDs duplicados, o que é inválido no HTML e prejudica leitores de tela e a acessibilidade. Solução com useId: O useId gera um ID diferente para cada instância do seu componente, garantindo que a associação entre label e input funcione corretamente em qualquer cenário. JavaScript


import { useId } from 'react';

function PasswordField() {
 // Gera um ID único e estável para esta instância
 const passwordId = useId(); 

 return (
   <>
     <label htmlFor={passwordId}>Senha:</label>
     <input id={passwordId} type="password" />
   </>
 );
}

Compatibilidade com Server-Side Rendering (SSR)
Este é um grande benefício. O useId garante que o ID gerado seja o mesmo tanto na primeira renderização no servidor quanto na renderização subsequente no cliente (o processo chamado de hidratação).
Isso evita problemas de incompatibilidade (mismatches) que podem ocorrer quando IDs são gerados aleatoriamente ou de forma não determinística, garantindo que o seu HTML seja consistente.
Outros Atributos ARIA
Ele também é útil para outros atributos de acessibilidade do ARIA (Accessible Rich Internet Applications), como:
aria-labelledby
aria-describedby

❌ Quando Não Usar useId?
É importante notar que o useId não deve ser usado para:
Gerar keys para listas: As chaves (keys) em listas (quando se usa .map()) devem ser baseadas nos dados subjacentes (por exemplo, um ID do banco de dados). O useId não garante chaves estáveis no caso de reordenação de listas, o que poderia levar a bugs de estado.
Gerar IDs globalmente únicos (UUIDs): Embora seja único dentro da árvore React, o formato do ID é determinístico para garantir a consistência Server/Client, e não se destina a ser um identificador globalmente aleatório, como um UUID

🚀 O Poder da Teoria dos Conjuntos na Programação: Lodash como Aliado na União e Diferença de Dados

Nathana Facion — Sat, 27 Dec 2025 22:49:44 +0000

No desenvolvimento em JavaScript, a manipulação de coleções de dados (arrays) é uma constante. Adotar uma mentalidade baseada na Teoria dos Conjuntos pode ser um divisor de águas, simplificando nosso código e aumentando sua clareza.

📖 O Conceito de Conjunto (Set)
Em programação, um Conjunto é essencialmente uma coleção de elementos distintos. As operações de conjuntos, como União e Diferença, nos permitem resolver problemas de gerenciamento de dados de forma elegante:
União: Combina listas, eliminando automaticamente quaisquer duplicatas.
Diferença: Encontra elementos que estão em uma lista, mas não na outra.

Vamos ver como o Lodash nos ajuda a aplicar isso, na prática, comparando-o com o código JavaScript "puro".

Exemplo 1: União (Combinando Listas sem Duplicatas)
Imagine que você precisa consolidar uma lista de usuariosAtivos e novosUsuarios.

Objetivo: Obter uma lista única de todos os usuários.
JavaScript Normal (Manual):

const A = [1, 2, 3];
const B = [3, 4, 5];

// Usamos o Set nativo para desduplicar

const uniao = [...new Set([...A, ...B])];

// Resultado: [1, 2, 3, 4, 5]

Com Lodash (_.union):

const A = [1, 2, 3];
const B = [3, 4, 5];
const uniao = _.union(A, B); 
// Resultado: [1, 2, 3, 4, 5]

O Ganho: O Lodash reduz a operação complexa de concatenação e desduplicação a uma única função, tornando a intenção do código imediata. A legibilidade é máxima.

Exemplo 2: Diferença (Encontrando Exclusividades)
Queremos saber quais usuários estão apenas na Lista A (ativos) e não na Lista B (novos), ou seja, quem é exclusivo de A.
Objetivo: Elementos em A que não estão em B.

JavaScript Normal (Manual):

const A = [1, 2, 3, 6]; 
const B = [3, 4, 5];
// Usamos filter e includes, com complexidade O(N*M)
const diferenca = A.filter(item => !B.includes(item));

// Resultado: [1, 2, 6]

Com Lodash (_.difference):

const A = [1, 2, 3, 6]; 
const B = [3, 4, 5];
const diferenca = _.difference(A, B); 
// Resultado: [1, 2, 6]

O Ganho: Além da simplicidade sintática, _.difference é frequentemente implementado de forma mais eficiente (utilizando hash maps internamente) do que a solução filter + includes manual, oferecendo melhor performance em grandes conjuntos de dados. Ele transforma uma lógica imperativa (filter) em uma declaração de conjunto (difference).

🏆 Conclusão: Por Que Mudar a Mentalidade?
Adotar a mentalidade de conjuntos e utilizar utilitários como o Lodash nos permite escrever um código mais declarativo. Em vez de dizer como o código deve ser executado (loops e filtros), dizemos o que queremos que ele faça (_.union, _.difference). Isso resulta em:
💡 Maior Clareza: A função descreve a intenção.
💡Menos Bugs: Utilizamos funções testadas e otimizadas.
💡Melhor Performance: Aproveitamos implementações otimizadas de bibliotecas.

🚀 Maximizando a Performance de Tabelas: 4 Estratégias Essenciais no Frontend!

Nathana Facion — Sat, 27 Dec 2025 22:46:56 +0000

Lidar com grandes volumes de dados em aplicações web pode ser um desafio de performance. Ninguém gosta de uma tabela lenta ou travando, certo?

Aqui estão 4 técnicas fundamentais que todo desenvolvedor deve conhecer para carregar tabelas de forma eficiente e garantir uma excelente experiência do usuário (UX):

1️⃣ Tabela Virtualizada (Virtualization)
A Virtualização foca na Otimização da Renderização no frontend.
O que faz: Em vez de renderizar todos os elementos da lista ou tabela no DOM, ela renderiza apenas as linhas visíveis na tela (e algumas acima/abaixo para suavizar o scroll).
➡️ Vantagem: Reduz drasticamente o número de nós do DOM. O resultado é um scroll mais suave e alta performance de UI, mesmo com datasets de milhares de itens.
➡️Melhor Uso: Cenários onde o dataset completo está disponível (ou sendo carregado em pedaços grandes), mas a lentidão é causada pela renderização excessiva no navegador.

2️⃣ Paginação (Pagination)
A Paginação foca na Otimização da Carga de Dados entre o frontend e o backend.
➡️O que faz: Quebra um grande conjunto de dados em pedaços menores (páginas) no servidor.
➡️Vantagem: Quando o usuário solicita uma página, apenas um subconjunto de dados (ex.: 20 linhas) é retornado pela API. Isso reduz a carga de rede e a carga do servidor, pois o banco de dados só busca o necessário.
Melhor Uso: Tabelas com milhões de registros, onde carregar todos os dados de uma vez seria impraticável.

3️⃣ Tabela em Memória (Client-side Processing)
Esta técnica foca na Velocidade de Interação após o carregamento inicial.
O que faz: O conjunto completo de dados é carregado na memória do navegador.
➡️Vantagem: Permite que operações como filtragem, ordenação e pesquisa sejam executadas instantaneamente no lado do cliente (sem novas requisições à API).
➡️Melhor Uso: Datasets pequenos a médios (ex.: até 5.000 ou 10.000 registros, dependendo da complexidade dos dados), onde o custo de carregar o conjunto completo é aceitável em troca de interatividade imediata.

4️⃣ React Query (ou TanStack Query)
React Query é uma ferramenta essencial que suporta todas as técnicas acima.
O que é: É uma biblioteca de gerenciamento de estado de servidor (não de estado de UI), lidando com fetching, caching, sincronização e atualização de dados remotos.
➡️Relevância para Tabelas:
Facilita a implementação de paginação (mantendo o cache de páginas anteriores).
➡️Fornece os dados brutos de forma eficiente para a virtualização.
Lida com status de requisição (loading, error), tornando o código mais limpo e robusto

🌞 Dominando padrões de composição em React para código mais limpo e reuso de lógica!

Nathana Facion — Sat, 27 Dec 2025 22:44:39 +0000

Recentemente, apliquei o padrão Higher-Order Component (HOC) para desacoplar a lógica de autenticação da renderização dos componentes.

🚀 O que isso resolve?
Com um HOC como o withAuth, conseguimos centralizar a regra de segurança em um único lugar. Qualquer componente que precise de autenticação é simplesmente "envolvido" pelo HOC, que decide se o usuário tem permissão para acessar o conteúdo.

➡️ Exemplo Prático - Proteção de Componentes:

// O HOC injeta a lógica de autenticação/redirecionamento
export default withAuth(UserDashboard);
💡 Essa técnica não só protege rotas de forma declarativa, como também elimina a duplicação de código de verificação de usuário em dezenas de componentes. Um passo crucial para a construção de aplicações React escaláveis e de alta manutenção.

🧠 Otimização no React: O Que, Quando e Por Quê

Nathana Facion — Sat, 27 Dec 2025 22:42:59 +0000

React.memo (Memoriza um Componente)
💡 O que faz: Envolve um componente funcional. Se as props do componente filho forem as mesmas da renderização anterior, o React pula completamente a re-renderização desse componente. É o "porteiro" do componente.
🏆 Quando usar: Quando você tem um componente que é lento e re-renderiza frequentemente sem que suas props realmente mudem.
useMemo (Memoriza um Valor)
💡 O que faz: Memoriza o resultado (o valor) de uma função de cálculo. O cálculo só é refeito se as variáveis listadas no seu array de dependências mudarem.
🏆 Quando usar: Quando você tem um cálculo pesado ou complexo (ex: filtros, somas grandes, ordenação) dentro do seu componente, e quer evitar que ele seja re-executado em toda renderização.
useCallback (Memoriza uma Função)
💡 O que faz: Memoriza a referência da função em si. Evita que o JavaScript crie uma nova função em um endereço de memória diferente a cada renderização.
🏆 Quando usar: Quase exclusivamente quando você precisa passar uma função como prop para um componente filho otimizado com React.memo. Ele garante que o filho não re-renderize desnecessariamente, pois a prop (a função) mantém a mesma referência