Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Antes do surgimento de frameworks como React, Angular ou Vue, desenvolvedores usavam métodos bem mais manuais para controlar o estado da aplicação.
Normalmente, tudo era feito com objetos simples, variáveis globais ou closures bem elaboradas, além de manipulação direta do DOM com getElementById, innerHTML e eventos. Era uma rotina que exigia muita atenção para evitar bugs difíceis de rastrear.
Um padrão comum era criar uma estrutura centralizada que guardava o estado, como um objeto global, e funções específicas para alterar esse estado. Sempre que um valor mudava, a atualização na tela tinha que ser feita manualmente, o que tornava o código propenso a erros e difícil de manter.
A questão é: como vocês lidavam com a monitorização de mudanças e atualização de componentes na época? Alguma técnica que ajudava a evitar retrabalho ou a manter o controle do fluxo de dados? O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
Hoje, a gente tem o Redux, Vuex e outras soluções que padronizam esse processo, mas na prática, o controle era bem mais artesanal. Essa prática antiga influencia até hoje na nossa forma de pensar arquitetura de software, mesmo com ferramentas modernas. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois.
Na época, a gente geralmente usava uma variável global e funções que manipulavam ela junto com funções de renderização, o famoso 'manual refresh'. Não tinha como evitar o retrabalho, era tudo na base da observação e testes constantes. Acho que essa experiência ajuda a entender melhor o que as libs atuais trazem de benefício.
Acho que o grande lance era mesmo centralizar o estado, mesmo que de forma manual, e fazer a atualização dos componentes de forma controlada. Depois, veio o pattern de observer, que facilitou muito. Hoje, dá pra fazer isso com hooks e context, mas a base manual ajudou muito a entender o fluxo.
No meu time, a gente costumava usar eventos customizados pra disparar atualizações. Ainda assim, era uma mão na roda lidar com sincronização de vários componentes. Como vocês faziam pra evitar que o DOM ficasse fora de sincronia?
Pô, na moral, isso me faz pensar na expectativa do usuário.
A minha dúvida é se tinha alguma estratégia pra evitar que o estado ficava disperso, ou seja, cada parte do código manipulava uma variável diferente e o sincronismo era difícil.