Kenneth Freitas

Cada dia que passa, mais e mais soluções são incorporadas na web. Por mais que processos de discovery e análises sejam feitos para as mais diferentes plataformas (computadores, celulares, etc), atingir o ponto de ter algo realmente bom para um público diversificado é algo bem difícil. A fim de ajudar empresas e desenvolvedores a criarem melhores soluções, a Google criou a Web Vitals, um sistema único de métricas que tem como objetivo quantificar experiências de usuários como um todo nas aplicações. Seu core é dividido em 3 grandes premissas, são elas: Largest Contentful Paint (LCP):  Mede o desempenho do carregamento da página. Apesar de parecer como tempo de resposta do servidor, essa métrica na verdade ela mede o tempo necessário para carregar grandes conteúdos no site. Conteúdo, neste caso, são apenas itens que tem valor para usuário exemplo bloco de textos, imagens, vídeos e etc. Nesse cálculo entram vários fatores, como viewport, redirecionamento de imagens e etc. Mostrando qu...

Se tem uma coisa hoje que define o front-end moderno, é a componentização. Acabar com a duplicidade do código, criar páginas com recursos incríveis apenas encaixando componentes já prontos e claro ganhar velocidade na alteração do layout. Tem outros pontos positivos, mas já deu pra pegar a ideia. Mas até nesses três pontos citados, não são só flores. Um princípio que resume tudo na vida, SRP. Quando criamos componentes precisamos ficar muito atentos ao seu nível de abstração, pois aqueles pontos positivos podem virar negativos rapidinho. Faz de conta que vamos criar uma página web para um ecommerce que vem crescendo rapidamente, você escolhe suas tecnologias e começa a seguir o design. O designer criou vários componentes bonitinhos e construiu todos os elementos, páginas e etc, ótimo. Você, um cara sagaz, viu que de fato os itens foram replicados, logo você cria um componente para cada um e sai montando as páginas. Maravilhoso, job realizado, todos felizes, trabalho excelente, boa! Com...

 Bem, todo mundo aqui sabe como funciona o típico Cliente-Servidor, onde o cliente manda uma requisição e o servidor responde, de uma maneira simples e unidirecional, em que o cliente sempre precisará informar o que necessita. Porém, tem casos que precisamos fazer o caminho inverso, onde o servidor notifica o cliente. Por exemplo: Notificar algum processo mais demorado, mostrando o quanto já foi realizado ou avisar sobre novos conteúdos. Depois desses exemplos, você já pode estar pensando “Ah, websockets”, mas não. E porque não? Então, websockets é uma comunicação bidirecional entre o cliente e o servidor, ou seja, quando uma conexão http (GET 1.1 upgrade) é realizada pelo cliente, irá mandar a solicitação ao servidor para a troca de protocolo (ws ou wss), criando uma conexão direta entre eles dois. Isso seria um caso perfeito para um chat, por exemplo. Então, como eu faço para ter essa conexão unidirecional do servidor para o cliente? Aí que entra Server-Sent Events (SSE). Com SSE...

Na rotina do trabalho é muito comum se deparar com o código dos outros, seja no projeto, em code reviews ou testes em processos seletivos e é aí que ter seu próprio estilo de código é tão importante, além do mais o "fit" não tem que acontecer apenas com a "empresa", mas também com a equipe de desenvolvimento. Já falei, mas vou repetir, tem muita vaga em desenvolvimento, mas pode ter certeza que tem bem mais candidatos. O grande problema de longe é o fator técnico (muitas vezes as empresas até desistem e pegam o "melhorzinho", pois a vaga está aberta há muito tempo) e ter seu próprio estilo de codar diz muito sobre suas habilidades e proficiência em uma tecnologia. Mas afinal, o que é "ter um estilo de código"? Não estou falando de style guides (entra também), estou me referindo ao jeito de codar em si. Por exemplo, para iterar um array em Javascript, podemos usar:  - while - for - for in - for of - forEach - e outros métodos que fazem outras cois...

Um CSS mal arquitetado pode ser uma dor de cabeça. Como tudo nele é global, pequenas mudanças tornam-se complicadas. Claro que processadores como SASS facilitam muito, mas uma metodologia bem aplicada é o que realmente faz a diferença na escalabilidade e manutenibilidade do seu CSS. Das diversas metodologias que existem, vamos falar sobre o BEM (Block, Element, Modifier), que tem como objetivo organizar as classes por funções: Block: É um componente de UI (por exemplo, um formulário); Element: É um componente de um Block (por exemplo, um input, botão ou label de um formulário); Modifier: É uma mudança que ocorre na apresentação de um Block ou Element (por exemplo um botão ativo ou pressionado); Por convenção temos a seguinte sintaxe: .block /* -> Um Block. */ .block__element /* -> Um Element que pertence à um Block. */ .block--modifier /* -> Um Modifier de um Block. */ .block__element--modifier /* -> Um Modifier de um Element. */ A...

O Angular é mais uma ferramenta incrível para a criação de SPA, mas como todos nós sabemos uma conexão lenta pode deixar a experiência do usuário um tanto desagradável ao seu primeiro acesso, pois é nesse momento que ele vai baixar todo o bundle da aplicação (que às vezes fica bem pesadinho né). Para suprir isso temos uma técnica bem conhecida, que é deixar sua SPA “preguiçosa” que na real acelera e muito seu carregamento! Lazy Loading basicamente é separar os módulos da sua aplicação de maneira que eles são carregados apenas quando são chamados (resolvendo aquele problema inicial, pois o carregamento da página será apenas de um módulo e não a aplicação inteira). Fazer Lazy Loading em uma aplicação Angular é extremamente simples, basta fazer uma importação dinâmica do seu módulo no seu arquivo de roteamento através do atributo “loadChildren”. RouterModule.forRoot([ { path: 'clients', loadChildren: () => import('./clients/client.module...