O que é terceiro estado e por que ele aparece no seu projeto
A gente chama de terceiro estado qualquer estado ou configuração que não pertence ao core da sua aplicação e que foi introduzido por uma dependência externa, um plugin, um middleware ou um serviço de terceiros. É o que sobra quando você tira seu código do meio. Esse conceito parece simples até o momento em que você precisa rastreá-lo em production e percebe que ele está espalhado por variáveis de ambiente, arquivos de configuração, sessões e caches distribuídos. No dia a dia, eu trabalho com aplicações que têm múltiplos provedores de autenticação, gateways de pagamento e SDKs de terceiros. A parte chatosa não é implementar cada um desses serviços. É saber exatamente qual estado está sendo carregado de onde e o que acontece quando dois terceiros sobrescrevem a mesma variável no mesmo pipeline.
Como identificar o terceiro estado no seu código
A primeira coisa que eu faço é rodar uma análise estática procurando por imports ou require que não sejam internos ao projeto. Isso elimina a maioria dos casos óbvios. Depois, eu mapeio onde esses módulos externos escrevem variáveis no escopo global ou em stores compartilhados. É nesse mapeamento que a maioria dos problemas nasce. Eu costumo montar uma tabela simples com três colunas: nome do dependency, chave ou constante exposta e fallback padrão. Esse documento vira a fonte da verdade quando algo quebra em produção e ninguém lembra quem mudou aquilo.
Terceiro estado na prática
Na prática, o terceiro estado se manifesta de formas que ninguém avisa nos READMEs. Um provedor de analytics pode injetar dados no objeto window antes do seu framework inicializar. Um SDK de pagamentos pode alterar headers globais sem documentar. Um middleware de CORS pode sobrescrever respostas antes delas chegarem ao seu controller. O estado não fica confinado. Ele transborda. Quando eu vejo uma aplicação cheia de efeitos colaterais vindos de bibliotecas externas, eu tratamento tudo como estado de terceiros e isolo esses pontos em camadas claras, em vez de confiar que o módulo vai se comportar como esperado.
Como gerenciar terceiro estado de forma previsível
O método que eu uso divide o problema em três etapas: descoberta, isolamento e controle. Na descoberta, eu executo uma lista de verificação rápida. Eu verifico configurações padrão, variáveis de ambiente que cada dependência lê automaticamente e hooks que módulos instalam sem pedir permissão. Em projetos Node, por exemplo, bibliotecas como dotenv, Winston e até alguns ORM criam estado global se você não especificar opções restritivas. Em React, provedores contextuais e bibliotecas de estado internacional vêm com instâncias default que sobrescrevem outras implementações.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No isolamento, eu crio um wrapper ou um adapter ao redor de cada dependência. Em vez de importar o módulo diretamente nos componentes ou módulos do negócio, eu importo meu wrapper. Dentro dele, eu configuro explicitamente todas as opções que o módulo usa e exponho apenas interfaces controladas. Esse wrapper também captura logs de inicialização e falhas, o que facilita a depuração posterior. No controle, eu defino fallbacks explícitos para cada variável de estado que um terceiro pode modificar. Se um SDK espera uma chave no objeto config e ela não existe, eu fornecemos um valor padrão previsível. Se eu não definir esse fallback, a aplicação entra em um estado ambíguo e as exceções acontecem tarde demais, já em produção.
Um caso real que eu encontrei recentemente
Eu tive um projeto em que o terceiro estado apareceu porque um cliente integrava duas bibliotecas de geolocalização: uma para dados cadastrais e outra para rotas. Cada uma lia a coordenada do usuário a partir de fontes diferentes e armazenava em campos separados dentro de um store central. Quando um usuário estava em roaming, a biblioteca de rotas retornava uma coordenada mais precisa, mas a de dados cadastrais mantinha a antiga. O resultado era um estado duplicado onde metade da aplicação usava coordenadas diferentes da outra metade. O workaround que eu usei foi simples. Eu removi a dependência da segunda biblioteca da carga inicial e criei uma função de reconciliação que comparava os dois valores a cada atualização. Se a diferença entre as coordenadas fosse menor que um threshold que eu defini por proximidade geográfica, eu mantinha o valor mais recente. Se fosse maior, eu registrava um log de alerta e usava o valor da biblioteca de dados cadastrais como fonte primária. Isso reduziu inconsistências em cerca de cinquenta por cento nos testes e eliminou os relatórios de erros de geolocalização nos primeiros quinze dias de deploy.
O que começar a fazer hoje
Se você quer aplicar isso rapidamente, comece com um inventário das dependências de terceiros que mais geram estados. Anote quais variáveis cada uma influencia e em quais ambientes elas mudam de comportamento. Depois, escreva adapters para pelo menos as três mais problemáticas. Teste com valores padrão e com valores ausentes para confirmar que sua aplicação não quebra quando a variável some. Eu recomendo ainda documentar esses mapeamentos em um arquivo de arquitetura. Quando alguém novo entra no time, ele precisa saber exatamente onde o estado de terceiros mora e como cada módulo externo interfere nele.
Limitações e o que você não deve esperar
Gerenciar terceiro estado não elimina todos os problemas de integração. Dependeções muito antigas, bibliotecas sem documentação clara e SDKs que fazem side effects agressivos continuam sendo fontes de instabilidade. Em projetos grandes, o overhead de manter adapters e a carga adicional de testes aumenta consideravelmente. Às vezes, a melhor decisão é simplesmente trocar o terceiro estado por uma solução própria ou por um serviço mais estável. Se você perceber que a complexidade de gerenciamento supera o benefício, considere substituir a dependência crítica. Nem sempre vale a pena manter uma camada extra de abstração se o módulo externo já mudou de comportamento três vezes no último ano e a equipe passa mais tempo corrigindo efeitos colaterais do que desenvolvendo funcionalidade.
O terceiro estado vai continuar existindo enquanto houver bibliotecas externas e serviços integrados. O importante é tratá-lo como algo previsível e documentado, em vez de assumir que ele se resolve sozinho.
