Como eu estruturo meus projetos vanilla JS
Tags: javascript, programming, portugues
Published: 2023-12-03 14:30:38

_**Nota:** apenas traduzi o texto abaixo e postei aqui._

Uma das perguntas que recebo com frequência é como estruturo e organizo meus projetos vanilla JS. Hoje vou mostrar como.

## Estrutura dentro de um script

A primeira coisa que faço com qualquer script novo é encapsular ele em uma function para mantê-lo fora do escopo global.

Se for algo que desejo executar explicitamente mais tarde ou em um horário específico, envolvo-o em uma `named function` que posso chamar mais tarde.

```javascript
var myScript = function () {
    // Algum código bonito...
};

// Mais tarde...
myScript();
```


Caso contrário, eu encapsulo ela em uma _Immediately Invoked Function Expression_, ou **IIFE**.

```javascript
(function () {
    // Algum código bonito...
})();
```

Dentro do meu script, divido meu código em três seções distintas:

- Variáveis
- Métodos
- inicializações e event listeners


Isso ajuda a manter meu código previsível e organizado.

```javascript
(function () {
    //
    // Variáveis
    //
    var elem = document.querySelector('#app');


    //
    // Métodos
    //
    var handleClicks = function (event) {
        console.log(event.target);
    };


    //
    // Inicializações & Event Listeners
    //
    elem.addEventListener('click', handleClicks);
})();
```

## Código Modular

Muitas pessoas presumem que, como não uso `frameworks` e `module bundlers`, mantenho todo o meu código em um arquivo JavaScript gigante.

Eu não. Isso seria uma loucura!

Tenho um diretório `/js` em meu projeto onde guardo todos os meus scripts individuais. Eu uso **Gulp**, um `JavaScript task runner` de linha de comando, para combinar arquivos (chamado concatenação) e minificar eles.

Aqui está meu `Gulp Boilerplate`. Se você prefere GUIs ou simplesmente não se sente confortável com linha de comando (já não me sentia confortável há muito tempo), [CodeKit](https://codekitapp.com/) e [Prepros](https://prepros.io) fazem a mesma coisa e são ambos muito bons.

## Splitting de código

Eu não carrego apenas todos os scripts em todas as páginas.

No meu diretório `/js`, tenho alguns arquivos individuais e alguns subdiretórios. Quaisquer scripts que estejam dentro de uma pasta no meu diretório `/js` são concatenados em um arquivo com o nome dessa pasta. Arquivos individuais são minificados, mas mantidos separados.

Por exemplo, `/js/main/mailchimp.js` e `/js/main/heading-links.js` são combinados em `main.js`, enquanto `/js/search.js` é minificado, mas permanece `search.js`.

Meu arquivo `main.js` contém o código que uso em todas (ou na maioria) das páginas do meu site. Ele é carregado em todos os lugares.

Os outros arquivos individuais são normalmente usados em apenas uma ou duas "views". Eu uso [loadJS()](https://github.com/filamentgroup/loadJS) do **Filament Group** para carregar condicionalmente esses scripts apenas nas páginas que precisam deles.

É uma maneira superleve e fácil de "code-splitting" sem mexer com um `module bundler` complicado.

## Tornando o JS inline

Quando se trata de desempenho na web, 14kb é um número mágico. Esse é o número aproximado de bytes em uma única HTTP request de ida e volta.

Servers enviam arquivos para o navegador em pequenos "packets", em vez de tudo de uma vez. Se você tiver um arquivo JavaScript de 20 KB, serão necessárias duas viagens de ida e volta para chegar ao navegador.

Quanto mais "round trips", mais lento será o site (geralmente falando).

Depois de "minifying" e "gzipping" meu código, meu JavaScript combinado de _CSS_, _HTML_ e _main.js_ para uma página típica em meus sites geralmente tem apenas 14 KB ou menos.

Se eu tornar inline meu CSS e JavaScript diretamente no HTML, isso significa que posso enviar a página inteira em uma única HTTP request e ela começará a ser renderizada imediatamente.

Se os arquivos combinados forem maiores que 14 KB, é melhor carregá-los externamente para que sejam armazenados em cache pelo navegador. Mas para mim, "inlining" é o motivo pelo qual meus sites parecem tão incrivelmente rápidos.

## Fonte

Newsletter de [Go Make Things](https://gomakethings.com/)