O que estudar para ser um programador de Frontend? 👨🎨 Parte 2
Hello world 👋 como estão desde... ontem? 😁
Bom, depois de ontem termos falado de controlos de versões, algumas libs (ou libraries), CSS pre-processors, frameworks de CSS, hoje vamos abordar mais tópicos, e conforme o tópico se estenda, vou ver se me fico por aqui com este tema ou se tenho que fazer uma Parte 3 😜
Próximo: Build tools
Vamos passar para um tema mais complexo, para mim pelo menos foi um pouco tramado de os perceber na altura que estive a aprender. Mas com muita prática consegui perceber o poder deles, embora seja mais complicado explicar a teoria. Portanto vou mostrar exemplos à medida que vou explicando. E peço a ti feedback, se concordas ou não com o que é dito. Allright? Então vamos lá.
O que venho falar então são as Build Tools. Esta divide-se em 3 grupos (como mostra a image do roadmap.sh):
Explicando então cada grupo:
1. Task Runners

Grunt e Gulp. 2 Task runners
Task runners são nada mais nada menos, que scripts que depois de adicionado no package.json, corremos no nosso projeto. Tanto para ambiente de desenvolvimento (dev), como para fazer o build do projeto (gerar todo o conjunto de ficheiros, onde normalmente é criado uma folder dist, e fica dentro desse bundle), este fica preparado para ser usado em prod (produção). Para visualizarem melhor, vou mostrar uma imagem abaixo que explica exatamente ao que me refiro.
Isto é o package.json do meu portfólio. Para correr em ambiente de desenvolvimento, uso: "npm run dev"
Ok, indo agora com calma. Quando queremos iniciar um projeto, como sabem existem os package managers que nos ajudam a iniciar o nosso projeto e onde podemos fazer o "download" de cada library/framework que queremos (ou seja, à uns anos atrás tinhamos que fazer download de um zip e extrair para uma folder específica, hoje em dia já não!), mas antes de começarmos a instalar packages, iniciamos o npm init ou yarn init.
E este exemplo que dei em cima, é o que faz exatamente um task runner. Quando temos propriedades no nosso objeto scripts, normalmente corremos com npm run [''nome_da_propriedade"] , podemos por qualquer nome na propriedade, não tem que ser necessariamente dev ou build. Mas por norma, esses scripts mantém-se, assim outros programadores podem correr o teu projeto. Caso alteres, não te esqueças de documentar esses mesmo scripts, para que programadores da tua equipa ou fora desta, possam correr o teu projeto.
Estes exemplos de npm run ... são os npm scripts.
Tanto o Grunt como o Gulp, eu usava bastante no passado quando estava no início desta aventura de programação. Mas... ao longo deste artigo já vais perceber porquê de ter deixado.
Com estes task runners, conseguiamos optimizar imagens, eliminar console.log statements (removam todos os vossos console.logs para produção! Quem nunca, right?!), minificar código, corrigir erros de syntax, entre outras tarefas; tudo isto conseguimos através de alguns comandos.
2. Module Bundlers
Neste tema, sei apenas 2, que tenho usado até agora, o Webpack e o Rollup, ambos idênticos mas com propósitos diferentes. Em resumo, o bundler é uma ferramenta que importa módulos (outros códigos Javascript) e que funcionam no nosso browser.
O que acontece é que cada bundler faz uma análise ao nosso código, e que o resultado deste, é apenas um ficheiro, ou seja:

Sem Module bundler

Com Module Bundler
Numa maneira não muito complexa, é isto que acontece. Uns termos agora mais técnicos: o bundler vai então pegar no nosso ficheiro (que é conhecido como entry point) com uma parte do nosso código, e vai gerar para um novo ficheiro (artifact), fazendo isto de uma maneira recursiva. Também pode fazer com que vá buscar dependências das dependências (dependência são os packages que instalamos com um package manager).
Pronto! Temos então o ficheiro final, e o nosso browser já sabe que código é aquele que foi gerado! Todo este código pode passar por várias transformações com algumas configurações, como por exemplo, usando Babel, TypeScript ou Flow.
Mas não vamos tocar muito neste assunto, este assunto é complexo, e eu pretendo agilizá-lo para que tu percebas toda a evolução do Frontend! Portanto passemos agora a explicar o Webpack!

O Webpack é um dos bundlers mais conhecidos! É bastante usado por causa do seu sistema de loaders (que instalamos com o npm ou yarn), ele é capaz de gerar bundlers de qualquer tipo de assets, ou seja, imagens, CSS, HTML, SASS, LESS e por aí fora. Apenas precisamos de usar loaders para cada caso específico, o que nos faz esse trabalho automaticamente. Não temos que correr comandos específicos, como temos que fazer com o Grunt e Gulp, daí ter deixado de usar, tanto eu como muitos programadores.
Este bundler é usado em frameworks de Javascript, como React e Vue! Frameworks de Javascript fica para outro dia 😜

Este aprendi à pouco tempo, portanto alguma asneira que escreva aqui, developers mais experientes, avisem-me que eu tratarei de explicar melhor à malta, ok? 😁 Obrigado!
O Rollup faz um trabalho muito parecido ao Webpack, mas tem uma outra técnica importante: Tree-shaking.
Tree-quem?
Tree-Shaking! Esta foi a minha reacção quando vi esta palavra, e explicando de uma forma simples, apenas importa parte do código que estás a usar no teu projeto. Um exemplo disso:
O tree-shaking!
Com este destructuring (se não sabes o que é isto, tens que estudar Javascript, portanto, força!) apenas usamos 2 funções do nosso package lodash, assim não torna tão pesado, quando o nosso bundler gerar apenas 1 ficheiro. Portanto, isto é o que o Rollup consegue fazer, técnica que só existe após o webpack2.
3. Linters e Formatters

Prettier + Eslint
Muitas equipas de programação, usam Linters e Formatters, para obter mais qualidade no seu código, manter um padrão de código, de modo a ficar mais fácil de ler e perceber entre equipas de programadores.
Ok, indo por partes, são ferramentas que lêem os nossos ficheiros um a um, procura por erros de syntax que são regras impostas pela equipa ou pelo developer, que sejam consideradas má prática. E cada erro, é reportado no final.
O Eslint é quem manda os erros/warnings sobre o teu código, enquanto que o Prettier é o que realiza a formatação de acordo com regras também definidas pelo programador.
E como podem ver, isto é um tema que nunca mais acaba! Amanhã vem o próximo tema, onde vou falar de frameworks (é sempre um tema que motiva a malta). Mas, mais uma vez, atenção, tens que estudar bem as bases antes de te aventurares em frameworks. Portanto vou trazer um outro título, seguindo sempre o roadmap. Prometo!
Obrigado a ti por teres lido até ao fim, alguma estupidez que tenha partilhado aqui, por favor, avisa-me (sim não é fácil explicar todos os conceitos, aproveito o blog assim dou uma revisão nos mesmos, e como explico na teoria)
Fiz um update ao site, algumas imagens podem ver um símbolo no canto superior direito, que ao clicar, podem expandir a imagem, a pedido de algumas pessoas.
Malta, aproveitem o cofinamento para começarem a estudar, porque não? Se tiveres alguma dúvida, contacta-me. Podes mesmo enviar-me um e-mail, não me importo! Goodbye world! 👋