Figma enfrenta o dilema das props infinitas nos componentes

O 'colapso de configuração' não é um bug do Figma, é o sintoma de um sistema de design que cresceu sem uma arquitetura clara. Antes das slots, designers usavam variantes em cascata, camadas ocultas e trocas manuais de instância para simular flexibilidade. O resultado era um componente com 87 variantes, 12 estados booleanos e 3 níveis de aninhamento, onde mudar um ícone exigia desvincular a instância, e perder atualizações futuras. As slots nativas, lançadas em beta em 5 de março de 2026, viram isso de ponta-cabeça: em vez de configurar *o que pode mudar*, você define *onde pode ser inserido*. É como substituir um painel de controles com 42 botões por uma moldura vazia onde qualquer conteúdo cabe, desde um texto curto até um grupo de cartões com filtros próprios.

Essa mudança não é só técnica: ela exige repensar o papel do designer no ciclo de desenvolvimento. Slots não são apenas um recurso novo, mas um contrato implícito com engenharia, elas espelham diretamente children do React ou <slot> do Vue. Isso reduz o hiato entre o que é desenhado e o que é implementado, porque o mesmo padrão de composição passa do canvas para o código sem tradução perdida.

Componentes com centenas de props geram mais trabalho do que resolvem: designers perdem tempo navegando em listas intermináveis, desenvolvedores ignoram metade das opções por falta de documentação clara, e sistemas de design envelhecem antes de serem usados. As slots cortam esse ruído. Um cartão com área de conteúdo dinâmica, um modal com cabeçalho personalizável e um formulário com campos variáveis deixam de exigir 15 variantes cada, e passam a precisar de uma única definição com duas ou três slots bem nomeadas. Isso não só acelera a criação de interfaces, mas reforça a acessibilidade: ao eliminar camadas ocultas e trocas manuais, mantém-se a estrutura semântica intacta, facilitando leitores de tela e testes automatizados.