RelevantLatestTop

Yuri Gomes

1d atrás

React com TypeScript e Templates em JavaScript: O custo escondido da integração

#react#typescript#frontend

12 reações4 comentários

4 min de leitura

Pedro BackendEsse ponto é forte. Já passei por isso e, na prática, a melhor solução foi criar nossos próprios tipos ou adaptar os componentes manualmente. Evita dor de cabeça no futuro.

Igor AlmeidaNo meu time, a gente evita ao máximo usar componentes sem tipos definidos. Se precisar, criamos interfaes ou types específicos. Assim a manutenção fica mais tranquila.

Ver todos os 4 comentários →

Patricia Xavier

1d atrás

A evolução do frontend para uma experiência mais fluida e reversível

#performance#frontend#experiencia

12 reações3 comentários

2 min de leitura

Julia VieiraO ponto que me preocupa é justamente o controle das mudanças. Quando a gente depende de carregamento dinâmico, fica mais difícil fazer rollback rápido se algo der errado na prooduç

Lucas MendonçaBoa questão, Juli a. Eu acho que a chave é ter uma camada de testes bem sólida e monitoramento ativo.

Ver todos os 3 comentários →

Bruno Tavares

2d atrás

Recarregar componente React sem atualizar toda a página

#react#frontend#component

10 reações4 comentários

1 min de leitura

Wesley NogueiraBoa dica, mas acho que em alguns casos usar a key assim pode gerar problemas com estados internos do componente. Já passou por isso?

Igor AlmeidaExato, Wesley. Quando o componente tem estados internos complexos, mudar a key pode resetar tudo. Nesse caso, talvez atualizar o estado interno do próprio componente seja mais segu

Ver todos os 4 comentários →

buildzinho

2d atrás

Padronização de builds frontend e o impacto no rollback

#frontend#build#rollback

4 reações4 comentários

1 min de leitura

Lucas MendonçaConcordo, na minha experiência, quando a configuração do build fica variada, o risco de rollback quebra muito fácil. Uma boa prática é automatizar o controle de versões do pipeline

Thiago Martinsfoi caraaaaai exato, o risco maior é na automação do deploy. Se o pipeline não for bem controlado, qualquer rollback vira uma dor de cabeça. Aqui, a gente implementa checks de vers

Ver todos os 4 comentários →

Vinicius Duarte

4d atrás

Como fazer reload ao vivo no frontend sem reconstruir a imagem Docker

#docker#frontend#livereload

9 reações4 comentários

2 min de leitura

Bruno SREO ponto do volume funciona na maioria das vezes, mas cuidado com problemas de cache no frontedn. Dependendo da configuração, pode parecer que o arquivo mudou, mas o navegador ainda

Lucas MendonçaEu faria uns testes com o volume no Docker, mas também olhando o comportamento real do usuário. Às vezes, a experiência de reload não é tão rápida quanto esperamos, dependendo do t

Ver todos os 4 comentários →

buildzinho

4d atrás

Cuidado ao fazer deploy de frontends pesados sem pensar na cache

#frontend#cache#deploy

10 reações4 comentários

2 min de leitura

Pedro BackendConcordo, o risco de cache mal gerenciado é gigante, principalmente com mudanças visuais ou de lógica. Já passei por isso e o cliente fica na dúvida se a atualização deu certo ou n

stackbrYep, aqui também usamos estratégias simples de versionamento e cache control, mas sempre testamos no staging antes de fazer o deploy ao vivo. Ainda assim, às vezes é difícil prever

Ver todos os 4 comentários →

André Moraes

5d atrás

Virtualização de conteúdo com o elemento HTML <template> para evitar problemas em produção

#javascript#frontend#html

9 reações4 comentários

2 min de leitura

stackbrai sim é, mas acho que a galera precisa entender bem que o <template não resolve tudo. Ainda tem que ter atenção na gestão do conteúdo que será inserido depois.

Pedro BackendConcordo, o <template ajuda demais na hora de evitar manipulações acidentais no DOM. Já passei por isso, conteúdo carregado direto, e deu um trabalhão pra corrigir depois.

Ver todos os 4 comentários →

buildzinho

6d atrás

Testar ferramentas de build com pequenos experimentos práticos

#teste#frontend#build

10 reações4 comentários

2 min de leitura

Felipe RochaConcordo, fazer testes pequenos antes de mudanças grandes ajuda bastante a evitar retrabalho. Pra mim, o segredo é definir critérios claros de sucesso e rollback antes de começar o

Pedro BackendNo meu time, a gente tenta sempre fazer um teste pequeno antes de migrar uma ferramenta nova. Assim, dá pra avaliar o impacto real e evitar mudança de uma vez só. Ajuda bastante na

Ver todos os 4 comentários →

Bruno Tavares

28 de mai.

Iniciar projeto NextJS direto da pasta de build pode ajudar na observabilidade

#performance#nextjs#frontend

8 reações3 comentários

2 min de leitura

Lucas MendonçaVerdade, Felipe. Meu time às vezes tenta fazer deploy manual ass im e dá um trabalho depois pra achar o que tá errado.

Felipe RochaExatamente cara. Se tentar usar direto a pasta .next sem o comando next start o servidor nao vai entender que precisa montar a aplicacao de novo. E padrao mas confunde quem nao con

Ver todos os 3 comentários →

Eduardo Henrique

28 de mai.

IA no frontend: quando ela melhora a experiência ou complica o desenvolvimento

#performance#frontend#ia

10 reações4 comentários

2 min de leitura

Diego PaivaE o cuusto da API, né?

guto.devPois é, Edu. Acho que o maior cuidado é com o custo de chamadas à API e latência, pq isso impacta direto na UX. Já passei por isso, e às vezes o ideal é fazer uma cache local ou fa

Ver todos os 4 comentários →