51 |
52 |
53 |
54 |
58 |
59 |
60 | 
16 | projetoWorkflow 17 | |-> .git 18 | |-> deploy 19 | |-> source 20 | |-> javascript 21 | |-> vendor 22 | |-> sass 23 | |- index.html 24 | |- .gitignore 25 | |- package.json 26 |27 | 28 | 29 | Faça uma pequena edição no seu arquivo package.json para ficar semelhante à: 30 | 31 | ```javascript 32 | 33 | { 34 | "name": "projetoWorkflow", 35 | "version": "1.0.0", 36 | "description": "Exemplo de um projeto", 37 | "author": "Daniel Tapias Morales" 38 | } 39 | 40 | 41 | ``` 42 | 43 | 44 | 45 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") 46 | 47 | 48 | ##Explicação sobre o processo de build 49 | 50 | O build, ou deploy, nada mais é do que preparar os arquivos para serem enviados para produção (subir no servidor e torná-lo disponível na internet). Esse processo pode envolver uma série de tarefas, e pode variar de projeto para projeto. Os exemplos mais comuns e simples de entender são: 51 | 52 | * autoprefixer nos arquivos css, ou seja, incluir os prefixos dos browsers, quando necessário. 53 | * concatenar arquivos javascript. 54 | * minificar arquivos, aumentando a performance do site/aplicação. 55 | * Copiar arquivos estáticos (como midias ou fontes) no diretório de deploy. 56 | 57 | Há muitos outros processos legais que poderíamos ver nesse guia, mas focarei no mais fundamental para seu entendimento. 58 | 59 | Dito isto, quero detalhar alguns pontos sobre a estrutura de diretórios criada acima: 60 | 61 | * O arquivo package.json, como sabemos, é onde listamos as nossas dependências do projeto. 62 | * O arquivo .gitignore é usado para dizer ao Git quais arquivos não devem ser versionados. 63 | * Não deveremos mexer dentro da pasta "deploy". Os arquivos desta pasta serão criados pelo nosso *builder*, no nosso caso, será o GruntJS. 64 | * A pasta source/javascript terá mais de um arquivo .js. Porém, esses arquivos serão concatenados num único arquivo e minificados no momento do build. 65 | * Por enquanto, a pasta source/sass conterá um arquivo css simples. Este arquivo será autoprefixado apenas. Nos próximos tópicos faremos as alterações necessárias para podermos trabalhar com o pre-processador SASS. 66 | * A pasta source/vendor conterá, para exemplificar, um arquivo de terceiro, o modernizr. Se este arquivo estiver minificado (normalmente está) ele simplesmente será copiado para o devido lugar dentro de "deploy". Esse mesmo processo poderia ser criado para uma pasta "images", por exemplo. Não criarei imagens em nosso projeto para manter as coisas simples. 67 | * Antes de cada build, iremos apagar (automaticamente, claro) todos os arquivos que estiverem dentro de "deploy". Esse processo é importante para evitarmos "sujeiras" de builds anteriores. 68 | 69 | 70 | Já temos o entendimento necessário para instalarmos o GruntJS, mas isso é assunto para o próximo tópico. -------------------------------------------------------------------------------- /automatizacao-de-tarefas/executando-tarefas.md: -------------------------------------------------------------------------------- 1 | #Executando Tarefas 2 | 3 | ## Autoprefixer 4 | 5 | A nossa primeira tarefa será incluir, automaticamente, os vendors prefixers no nosso arquivo css. Vale saber que este plugin utiliza as informações disponíveis no [caniuse](http://caniuse.com/) para decidir qual vendor incluir no arquivo css. Para isso, o autoprefixer se baseia sempre nas duas últimas versões de cada browser (mas isso é configurável). 6 | 7 | Abra o seu Gruntfile no editor de código e substitua: 8 | 9 | ```javascript 10 | 11 | autoprefixer: { 12 | 13 | }, 14 | 15 | ``` 16 | 17 | por: 18 | 19 | ```javascript 20 | 21 | autoprefixer: { 22 | dist: { 23 | files: { 24 | 'deploy/css/main.css': 'source/sass/main.css', 25 | }, 26 | }, 27 | }, 28 | 29 | 30 | ``` 31 | 32 | A configuração desse arquivo é tão simples que acredito ser auto-explicativa. 33 | 34 | Você pode verificar outras opções de configurações na própria página do plugin. [https://www.npmjs.com/package/grunt-autoprefixer](https://www.npmjs.com/package/grunt-autoprefixer) 35 | 36 | 37 | Você pode testar se o autoprefixer está funcionando digitando no terminal: 38 | 39 | ```javascript 40 | $ grunt autoprefixer 41 | 42 | ``` 43 | 44 | Você deverá ver uma mensagem "Done, without errors", indicando que correu tudo bem. 45 | 46 | Abra o seu css gerado na pasta de deploy e veja os prefixos do linear gradiente. Veja que eu os escrevi como manda a especificação (to top) e o autoprefixer incluiu o gradiente como fazíamos antes da especificação (bottom). 47 | 48 | Repare também que nada mudou com o text-shadow, isso porque o autoprefixer não cria fallbacks. Ele simplesmente acidiona os prefixos, se estes existirem. 49 | 50 | 51 | ## Minificando o CSS 52 | Depois que o CSS foi gerado, nós podemos reduzir um pouco o tamanho desse arquivo, minificando-o. Na prática, nesse exemplo simples o resultado será imperceptível (alguns bytes), mas se você estiver trabalhando num projeto maior, mesmo que consiga reduzir alguns kbytes valerá a pena devido à simplicidade desse processo. 53 | 54 | Para esta tarefa, usaremos o plugin [cssmin](https://www.npmjs.com/package/grunt-contrib-cssmin). 55 | 56 | 57 | Substitua no lugar adequado no seu Gruntfile 58 | 59 | ```javascript 60 | 61 | cssmin: { 62 | dist: { 63 | files: { 64 | 'deploy/css/main.css': 'deploy/css/main.css' 65 | } 66 | } 67 | }, 68 | 69 | 70 | 71 | ``` 72 | 73 | Repare que nós estamos minificando o arquivo que foi prefixado anteriormente, já na pasta deploy. OK! 74 | 75 | Rode no terminal ``` $ grunt cssmin ``` e veja o que acontece 76 | 77 | 78 | ##Minificando e concatenando seus javascripts 79 | 80 | A nossa próxima tarefa é minificarmos e concatenarmos nossos arquivos javascript. Para isso, vamos usar o [uglify](https://www.npmjs.com/package/grunt-contrib-uglify). 81 | 82 | Da mesma forma que fizemos anteriormente, altere o seu Gruntfile, incluindo no lugar adequado o seguinte código: 83 | 84 | ```javascript 85 | 86 | uglify: { 87 | options: { 88 | mangle: true 89 | }, 90 | 91 | dist: { 92 | files: { 93 | 'deploy/javascript/app.min.js': [ 94 | 'source/javascript/incrementButton.js', 95 | 'source/javascript/date.js' 96 | ] 97 | } 98 | }, 99 | } 100 | 101 | 102 | ``` 103 | 104 | Moleza. A propriedade do objeto files é o arquivo que será gerado. O valor dessa propriedade é um array de arquivos, ou seja, o uglify irá concatenar cada um dos arquivos descritos na array num único arquivo. 105 | 106 | O opção true para o mangle faz com que a minificação seja mais pesada, alterando, quando possível, o nome de algumas variáveis para reduzir ainda mais o tamanho do arquivo. 107 | 108 | Para ver o uglify em ação, você pode digitar no terminal: 109 | 110 | ```$ grunt uglify``` 111 | 112 | Sempre abra o arquivo gerado no seu editor de código para ver o resultado. 113 | 114 | Um detalhe importante: boa prática não minificar arquivos já minificados, como bibliotecas de terceiros. 115 | 116 | 117 | 118 | ## Copiando arquivos estáticos 119 | 120 | Uma tarefa bastante trivial é ter que copiar alguns arquivos estáticos para a pasta de deploy, como por exemplo: arquivos de imagens, arquivos de fontes, javascripts de terceiros, etc. Para essa tarefa, não usaremos o CTRL+C e CTRL+V, mas sim o plugin [copy](https://www.npmjs.com/package/grunt-contrib-copy). 121 | 122 | Da mesma forma que os plugins anteriores, substitua no lugar apropriado de seu Gruntfile.js 123 | 124 | ```javascript 125 | 126 | copy: { 127 | dist: { 128 | files: [ 129 | {src: 'source/vendor/*', dest: 'deploy/vendor/'} 130 | ] 131 | } 132 | }, 133 | 134 | 135 | ``` 136 | 137 | A diferença é que agora a propriedade files não é mais uma string, mas sim um array de objetos. 138 | 139 | Na verdade, o exemplo anterior funcionaria sem precisarmos de um array, ou seja, se fizéssemos dessa forma: 140 | 141 | ```javascript 142 | 143 | copy: { 144 | dist: { 145 | src: 'source/vendor/*', 146 | dest: 'deploy/' 147 | }, 148 | }, 149 | 150 | ``` 151 | 152 | 153 | Mas a questão é que dificilmente temos que copiar somente um diretório, ou seja, escrevendo com array você poderá copiar mais de um diretório sem grandes problemas. 154 | 155 | Por exemplo: 156 | 157 | 158 | 159 | 160 | ```javascript 161 | 162 | copy: { 163 | dist: { 164 | files: [ 165 | {src: 'source/vendor/*', dest: deploy/vendor/'}, 166 | {src: 'source/images/*', dest: deploy/images/'}, 167 | {src: 'source/fonts/*', dest: deploy/fonts/'}, 168 | ] 169 | } 170 | } 171 | 172 | ``` 173 | 174 | 175 | É hora de verificarmos se o que fizemos deu certo. No terminal, digite ``` $ grunt copy ``` e em seguida abra o seu diretório deploy e veja como ficou. Os arquivos foram copiados? A estrutura de pasta está certa? Ficou como esperávamos? Eu acho que não. 176 | 177 | A questão é que o Grunt copiou os arquivos, mas não da maneira como estávamos imaginando. Quando configuramos o Grunt dessa forma: ``` {src: 'source/vendor/*', dest: 'deploy/'} ``` o que esperávamos era que todos os arquivos inseridos na pasta vendor fossem copiados para deploy/vendor. Mas na prática, o que o Grunt fez foi copiar o caminho completo, desde source, para dentro de deploy. O resultado foi o seguinte caminho: deploy\vendor\source\vendor. Bem estranho, não é mesmo? 178 | 179 | Para resolver, precisamos dizer ao Grunt para, no momento da cópia, se basear relativamente ao diretório source, mas não incluí-lo na cópia. Para isso: 180 | 181 | ```javascript 182 | expand: true, //habilita o cwd 183 | cwd: 'source/', //relativo ao diretório source, mas não o inclui na cópia 184 | 185 | 186 | ``` 187 | 188 | 189 | A configuração final de nosso copy ficou assim: 190 | 191 | ```javascript 192 | copy: { 193 | dist: { 194 | expand: true, //habilita o cwd 195 | cwd: 'source/', //relativo ao source, mas não o inclui na cópia 196 | src: 'vendor/*', 197 | dest: 'deploy/', 198 | } 199 | }, 200 | 201 | ``` 202 | 203 | 204 | Para finalizar, falta configurarmos a cópia da nossa index.html. Veja como deve ficar. 205 | 206 | ```javascript 207 | 208 | copy: { 209 | dist: { 210 | files: [ 211 | { 212 | expand: true, //habilita o cwd 213 | cwd: 'source/', //relativo à source, mas não a inclui na cópia 214 | src: 'vendor/*', 215 | dest: 'deploy/' 216 | }, 217 | { 218 | expand: true, //habilita o cwd 219 | cwd: 'source/', 220 | src: 'index.html', 221 | dest: 'deploy/'} 222 | ] 223 | } 224 | }, 225 | 226 | 227 | ``` 228 | 229 | 230 | Tudo copiado conforme esperávamos, mas ainda resta alguns problemas: O arquivo index.html faz as chamadas às folhas de estilo e ao javascript da seguinte forma: 231 | 232 | ```html 233 | 234 | 235 | 236 | 237 | 238 | 239 | ``` 240 | 241 | 242 | Precisamos atualizar a inclusão do javascript apontando para o arquivo concatenado e minificado e também arrumar o caminho do css, apontando para a pasta correta (nós trocamos o nome do diretório de "sass" para "css", e isso causou um problema de referência) 243 | 244 | 245 | Eu já trabalhei com dois plugins do GruntJS para resolver esse tipo de problema: 246 | 247 | * [grunt-useref](https://www.npmjs.com/package/grunt-useref). 248 | * [grunt-usemin](https://github.com/yeoman/grunt-usemin). 249 | 250 | 251 | Para o nosso guia, eu vou simplesmente pedir que você altere a chamada do main.css e app.min.js em "source" e execute o copy novamente. 252 | 253 | Se você quiser deixar mais profissional, tente por conta própria usar um dos plugins descritos acima. Senão, basta alterar o caminho do css e do javascript. 254 | 255 | 256 | ## Limpando o diretório antes do deploy 257 | 258 | A cereja do bolo é fazer com que, antes de cada deploy, o grunt apague todos os arquivos da pasta de destino. Isso garante que não sobre arquivos indevidos no nosso diretório de deploy, como por exemplo imagens ou fontes que não são mais utilizadas. 259 | 260 | Para isso, vamos usar o [grunt-contrib-clean](https://www.npmjs.com/package/grunt-contrib-clean). 261 | 262 | 263 | ```javascript 264 | 265 | clean: { 266 | dist: { 267 | src: ["deploy"] 268 | } 269 | } 270 | 271 | 272 | ``` 273 | 274 | Esse comando irá deletar o nosso diretório deploy. Não é difícil perceber que o comando ``` $ grunt clean ``` deve ser executado antes de qualquer outro comando. 275 | 276 | 277 | Ou seja, no nosso terminal, devemos executar os seguintes comandos, nessa ordem: 278 | 279 | ```javascript 280 | 281 | $ grunt clean 282 | $ grunt autoprefixer 283 | $ grunt cssmin 284 | $ grunt uglify 285 | $ grunt copy 286 | 287 | ``` 288 | 289 | Eu acho que seria interessante se tivéssemos como executar apenas um comando no terminal e o próprio grunt executasse quantas tarefas fossem necessárias. E advinha: isso é possível. É o que veremos a seguir. -------------------------------------------------------------------------------- /automatizacao-de-tarefas/registrando-tarefas-no-Gruntfile.md: -------------------------------------------------------------------------------- 1 | #Registrando tarefas no Gruntfile.js 2 | 3 | Depois que tivermos todos os plugins instalados, precisamos registrá-los (carregá-los) no nosso Gruntfile. Para isso, abra esse arquivo no seu editor de código e insira o trecho a seguir: 4 | 5 | ````javascript 6 | module.exports = function(grunt) { 7 | 8 | grunt.loadNpmTasks('grunt-autoprefixer'); 9 | grunt.loadNpmTasks('grunt-contrib-cssmin'); 10 | grunt.loadNpmTasks('grunt-contrib-uglify'); 11 | grunt.loadNpmTasks('grunt-contrib-copy'); 12 | grunt.loadNpmTasks('grunt-contrib-clean'); 13 | } 14 | 15 | ``` 16 | 17 | Isso faz com que os plugins instalados anteriormente estejam disponíveis para serem usados via Gruntfile.js, e não mais via terminal. 18 | 19 | O próximo passo é configurar cada um dos plugins. Cada um deles possui sua maneira peculiar de configuração. Eu farei aqui somente o básico, mas no final, você poderá ler diretamente a documentação de cada um dos plugins para se aprofundar. 20 | 21 | Toda a configuração precisa estar inserida num método do Grunt. Veja o código: 22 | 23 | ```javascript 24 | grunt.initConfig({ 25 | 26 | }); 27 | 28 | ``` 29 | 30 | Esse objeto que é passado por parâmetro para a função initConfig conterá as opções de cada um dos plugins. 31 | 32 | 33 | 34 | ```javascript 35 | grunt.initConfig({ 36 | autoprefixer: { 37 | 38 | }, 39 | 40 | copy: { 41 | 42 | }, 43 | 44 | clean: { 45 | 46 | }, 47 | 48 | cssmin: { 49 | 50 | }, 51 | 52 | uglify: { 53 | 54 | }, 55 | 56 | }); 57 | 58 | ``` 59 | 60 | Por hora, essa é a aparência de nosso arquivo. 61 | 62 |  63 | 64 | 65 | Para começarmos os nossos testes efetivamente, precisamos criar os nossos arquivos css, javascript e html. Mas para isso, você terá que clicar no link do próximo tópico (ou ir para a próxima página, se tiver feito o download deste gruia). -------------------------------------------------------------------------------- /automatizacao-de-tarefas/tarefas-em-lote.md: -------------------------------------------------------------------------------- 1 | #Executando tarefas em lote 2 | 3 | Estamos quase lá. 4 | 5 | O que nos resta agora é fazer com que, digitando apenas um comando no nosso terminal, sejamos capazes de executar todas as tarefas de uma única vez. Para isso, nós iremos criar um alias, ou seja, um atalho para mais de uma tarefa criada no Gruntfile. 6 | 7 | Veja um exemplo abaixo: 8 | 9 | ```javascript 10 | grunt.registerTask(minhaTarefa, [tarefa1, tarefa2, tarefa3]) 11 | 12 | ``` 13 | 14 | Dessa forma, se você digitar no terminal 15 | 16 | ```javascript 17 | $ grunt minhaTerefa 18 | 19 | ``` 20 | 21 | As tarefas tarefa1, tarefa2 e tarefa3 serão executadas nessa mesma ordem. 22 | 23 | Um detalhe importante é que você pode registrar uma tarefa chamada ‘default’. Nesse caso, lá no terminal basta digitar ``` $ grunt ``` que esse "default" será chamado. 24 | 25 | 26 | Para esse exercício, vamos criar uma tarefa chamada "deploy", que conterá todas as tarefas criadas até o momento: 27 | 28 | ```javascript 29 | grunt.registerTask("deploy", ["clean", "autoprefixer", "cssmin", "uglify", "copy"]) 30 | 31 | ``` 32 | 33 | Agora basta digitarmos no terminal ``` $ grunt deploy ``` que as cinco tarefas serão executadas, uma a uma. 34 | 35 | Isso não é demais!? 36 | 37 | Para referência, segue meu Gruntfile.js final: 38 | 39 | ```javascript 40 | module.exports = function(grunt) { 41 | 'use strict'; 42 | 43 | grunt.initConfig({ 44 | autoprefixer: { 45 | dist: { 46 | files: { 47 | 'deploy/css/main.css': 'source/sass/main.css', 48 | }, 49 | }, 50 | }, 51 | 52 | copy: { 53 | dist: { 54 | files: [ 55 | { 56 | expand: true, //habilita o cwd 57 | cwd: 'source/', //relativo à source, mas não a inclui na cópia 58 | src: 'vendor/*', 59 | dest: 'deploy/' 60 | }, 61 | { 62 | expand: true, //habilita o cwd 63 | cwd: 'source/', 64 | src: 'index.html', 65 | dest: 'deploy/'} 66 | ] 67 | } 68 | }, 69 | 70 | clean: { 71 | dist: { 72 | src: ["deploy"] 73 | } 74 | }, 75 | 76 | cssmin: { 77 | dist: { 78 | files: { 79 | 'deploy/css/main.css': 'deploy/css/main.css' 80 | } 81 | } 82 | }, 83 | 84 | uglify: { 85 | options: { 86 | mangle: true 87 | }, 88 | 89 | dist: { 90 | files: { 91 | 'deploy/javascript/app.min.js': [ 92 | 'source/javascript/incrementButton.js', 93 | 'source/javascript/date.js' 94 | ] 95 | } 96 | }, 97 | } 98 | 99 | 100 | }); 101 | 102 | 103 | grunt.loadNpmTasks('grunt-autoprefixer'); 104 | grunt.loadNpmTasks('grunt-contrib-cssmin'); 105 | grunt.loadNpmTasks('grunt-contrib-uglify'); 106 | grunt.loadNpmTasks('grunt-contrib-copy'); 107 | grunt.loadNpmTasks('grunt-contrib-clean'); 108 | 109 | grunt.registerTask('deploy', ['clean', 'autoprefixer', 'cssmin', 'uglify', 'copy']) 110 | 111 | 112 | } 113 | 114 | 115 | ``` -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "workflow front end", 3 | "description": "Os fundamentos para o moderno workflow front-end para quem já manja de HTML, CSS e Javascript", 4 | "language": "pt-br", 5 | "plugins": ["ga"], 6 | "pluginsConfig": { 7 | "ga": { 8 | "token": "UA-73075491-1" 9 | } 10 | } 11 | } -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/cover.jpg -------------------------------------------------------------------------------- /cover_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/cover_small.jpg -------------------------------------------------------------------------------- /cta_livro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/cta_livro.png -------------------------------------------------------------------------------- /fundamentos-do-github.md: -------------------------------------------------------------------------------- 1 | # Fundamentos do GitHub 2 | 3 | Ainda me lembro como se você ontem. Foi no final de 2012 que desenvolvi meu primeiro plugin jQuery. 4 | O plugin era muito simples e resolvia um problema que frequentemente eu enfrentava: igualava as alturas de vários elementos flutuantes de acordo com a altura do maior elemento na mesma linha. Hoje há formas de resolver este problema apenas com o CSS, mas naquela época, me facilitou muito a vida e resolvi compartilhar o meu feito com o mundo inteiro. 5 | 6 | E onde deveria "hospedar" o meu código? Já havia usado o GitHub para "baixar" javascripts de terceiros, portanto, "subir" meu próprio código não deveria ser difícil. 7 | 8 | Depois de me cadastrar no site, procurei imediatamente um botão para upload, sem sucesso. Não havia (e não há um botão upload de arquivos no GitHub). Tudo bem, talvez eu tenha sido o único idiota que tenha procurado esse botão no GitHub, mas naquele momento, a minha vida teria sido mais fácil se alguém mais experiente tivesse me explicado: 9 | 10 | "O GitHub não é um lugar para você hospedar seus arquivos lá. Ele é um serviço que possibilita você deixar o seu repositório GIT na nuvem." 11 | 12 | ##Assim no Git como no GitHub. 13 | 14 | Até o capítulo passado, todo o versionamento (```git init```, ```git add```, ```git commit``` etc) era efetuado na sua máquina. Isso resolve um problema: se algo der errado, é fácil voltar uma versão ou até mesmo comparar arquivos antes e depois de cada commit. Mas isso ainda não resolve alguns problemas: 15 | * Se você trabalhar em equipe, cada desenvolvedor terá a sua própria versão. O que não é o ideal. 16 | * Mesmo trabalhando sozinho, o ideal é que você não mantenha o seu versionamento de seu sistema somente na sua máquina. Assim, mesmo que a sua máquina pegue fogo, você poderá continuar trabalhando de qualquer outro lugar. 17 | 18 | O GitHub não é a única solução para estes problemas. Você poderia, por exemplo, manter um repositório central no seu servidor e fazer todos os colaboradores clonarem os projetos de lá. É uma solução válida, contudo, pela facilidade, mostrarei aqui como manter seu repositório no GitHub. Entretanto, vale alertar que o GitHub é gratuíto para contas com projetos públicos. Se você precisar de um projeto privado, precisará de uma conta paga. 19 | 20 | Dito isto, o primeiro passo é criar sua conta em [https://github.com/join](https://github.com/join). 21 | 22 | Preencha o formulário com seus dados e depois escolha um dos planos. Pode criar uma conta gratuita para testarmos. 23 | 24 | Depois da conta criada, você precisará criar um repositório de teste. Do lado direito, procure uma caixa "Your repositories" e clique no botão "upload". Brincadeira!. Clique em "new repository". Dê um nome bonito para o seu repositório e lembre-se de deixá-lo como público. As demais configurações você pode deixar como está. Clique em "create repository". 25 | 26 | Prontinho. Você tem seu primeiro repositório (ainda vazio) criado. Agora vamos fazer a ligação entre o seu repositório local e o remoto. 27 | 28 | O primeiro passo é configurar o repositório corretamente usando o terminal. 29 | 30 | Acesse a pasta do nosso exemplo digitando no Git Bash: 31 | 32 | ```$ cd ~/Projects/PrimeirosPassosWorflow``` 33 | 34 | Lembre-se que o "~" é um atalho para a sua pasta pessoal. 35 | 36 | Estando na pasta correta, digite o seguinte comando no seu terminal: 37 | 38 | ```$ git remote add origin https://github.com/Seu_usuario/seu_repositorio.git``` 39 | 40 | Repare que você precisa trocar o seu usuário e o nome do seu repositório no endereço acima. Se você não tiver certeza de ter escrito corretamente, procure na página inicial do seu repositório o lado direito onde está escrito: HTTPS clone URL 41 | 42 | É essa URL que você precisa escrever no seu terminal (comando ```$ git remote```) 43 | 44 | Com o comando anterior, você criou um vínculo do nome "origin" para o seu repositório que está lá no GitHub. 45 | 46 | ##Git Push e Pull 47 | 48 | Uma vez criado o nosso apontamento do "origin" para o GitHub, o próximo passo é "subir" seus arquivos para a nuvem. Tendo certeza que você está na pasta correta, digite no terminal: 49 | 50 | ```$ git push origin master``` 51 | 52 | Na verdade, nós não estamos apenas "subindo" nossos arquivos. Nós estamos enviando todo o histórico do versionamento. Explicando o comando acima: 53 | ```push``` é o comando que submete o versionamento para o seu repositório na nuvem. 54 | ```origin``` é o seu repositório remoto que, como dito antes, aponta lá para o GitHub. 55 | ```master``` é a sua branch principal. Não cabe aqui explicar em detalhes o que é uma branch, mas saiba que o nome "master" é um nome padrão criado pelo próprio Git. Recomendo deixar esse nome por enquanto. 56 | 57 | Digite seu usuário e senha do GitHub e tecle ENTER. Se tudo correu bem, você já consegue ver sua versão na internet. https://github.com/Seu_usuario/seu_repositorio 58 | 59 | Digamos agora que a sua máquina subiu no telhado e você precisa continuar o desenvolvimento da sua página exemplo01.html. Se você fez tudo certinho (```git commit``` e ```git push``` nos momentos adequados) basta você "baixar" seus arquivos de outra máquina (pode até ser emprestada) que contenha o Git instalado. 60 | 61 | Para isso, crie uma pasta nesse novo computador que será o seu repositório local de todos os projetos (similar à nossa pasta "Projects") e a acesse no terminal com o comando ```cd```. Depois, digite: 62 | 63 | ```$ git clone https://Seu_usuario/seu_repositorio.git``` 64 | 65 | Esse comando fará uma cópia dos arquivos que estão no seu repositório lá no GitHub num diretorio com o mesmo nome de seu repositório (veja com o comando ```ls```). Agora não tem mais desculpa. Pode continuar o desenvolvimento do projeto. Quando tudo tiver feito (ou no final do dia de trabalho), faça um ```commit``` e suba tudo novamente no GitHub (```$ git push origin master```). Assim você garante que não haverá problema de perda de arquivos (e horas de trabalho) se a sua nova máquina resolver subir no telhado também. 66 | 67 | Maravilha. Você continuou o trabalho usando uma máquina emprestada sem prejuízo algum. Mas a sua outra máquina foi para o concerto e ficou pronta. Tudo funcionando perfeitamente. Então você agradece e devolve a máquina emprestada e volta para a sua própria máquina. Como continuar com o desenvolvimento? Será preciso clonar novamente o repositório? Não. Se este ainda estiver configurado no computador, basta solicitar ao Git para atualizar os arquivos locais de acordo com o último ```commit``` que foi feito no GitHub. Para isso, digite no terminal (depois de acessar a sua pasta com o comando ```cd```). 68 | 69 | ```$ git pull origin master```. 70 | 71 | Prontinho, não só os arquivos na sua máquina estão todos atualizados como você ainda mantém todo o histórico. Faça um teste digitando ```$ git log```. 72 | 73 | Por hora é isso. Ainda há muito o que aprender sobre o Git mas o que eu apresentei aqui é o básico necessário para você continuar seus estudos. 74 | 75 | Atualmente, saber manusear bem os comandos do Git (ou outro sistema de controle de versão) é requisito obrigatório em qualquer área de desenvolvimento (web, app, mobile, front-end, back-end etc). 76 | 77 | Se você não conhecia nada sobre o assunto, eu espero que tenha conseguido te dar uma luz. Se já conhecia, espero que tenha acrescentado algo novo. 78 | 79 | No próximo capítulo vou mudar um pouco de assunto e falar sobre npm e automatização de tarefas. Espero que continue a leituira. Até lá! 80 | 81 | -------------------------------------------------------------------------------- /introducao.md: -------------------------------------------------------------------------------- 1 | # Introdução 2 | 3 | Nesta introdução você conhecerá os motivos que me levaram a escrever esse guia. Saberá para quem ele foi escrito e o que você aprenderá até o final da leitura. 4 | -------------------------------------------------------------------------------- /introducao/antes-do-susto.md: -------------------------------------------------------------------------------- 1 | # Antes do susto 2 | 3 | Mas algo muito positivo aconteceu na minha vida. Saí da agência onde os projetos tinham data de nascimento e de óbito definidas e fui trabalhar numa empresa onde eu tive a oportunidade de desenvolver produtos que teriam vida longa. Aplicativos baseados na web que seriam usados por muitas pessoas, e em diversos dispositivos. E agora? Até dá pra desenvolver aplicativos web usando javascript e jquery, (com um mínimo de padrão de projeto, por favor). Mas e a performance? Minificar e concatenar arquivos? Sprites de imagens? Eu até sabia tudo isso na teoria, mas na prática, nada. Eu precisava mudar isso. E rápido. 4 | 5 | Então fui procurar material na internet. Procurei sobre automatização de tarefa e fui levado ao site do [grunt.js](http://gruntjs.com/). O link *"Getting Started"* é onde devemos clicar para aprender algo, não é mesmo? A primeira linha, do primeiro parágrafo, na primeira página que abro, diz o seguinte: 6 | 7 | *"Grunt and Grunt plugins are installed and managed via npm, the Node.js package manager."* 8 | 9 | Mas whata? npm? node.js? Ok. Tinha que correr atrás do prejuízo. Achei que seria mais fácil ver como o GruntJs funciona na prática. Googlei novamente e abri um site famoso em português que dizia: 10 | 11 | ...para instalar, digite: 12 | `sudo npm install -g grunt-cli` 13 | 14 | 15 | **Digitar? Onde? Como assim? ** 16 | 17 | Com um pouco de receio, entrei no site [nodejs.org](https://nodejs.org/) para saber mais sobre essa tecnologia. Confesso que o texto a seguir não me esclareceu muito: 18 | 19 | *"Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js' package ecosystem, npm, is the largest ecosystem of open source libraries in the world."* 20 | 21 | Foi a partir desse ponto que eu fechei todas as abas do navegador. Abri meu Sublime e continuei com o velho e bom javascript. Do jeito que sempre foi. Ah, javascript, seu lindo! 22 | -------------------------------------------------------------------------------- /introducao/depois-do-susto.md: -------------------------------------------------------------------------------- 1 | # Depois do susto 2 | 3 | Mas é claro que se eu me propus a escrever todo esse texto que se segue, é porque eu superei esse trauma inicial e, sem a pressão do dia-a-dia, fui estudando aos poucos, à noite e aos finais de semana. Sem pressão, sem prazo. 4 | 5 | Fui descobrindo aos poucos sobre como essas novas tecnologias funcionavam e onde me seriam úteis. 6 | 7 | Ainda tenho muito o que aprender. Comecei os meus primeiros passos agora (no início de 2015). Mas creio que, mesmo com pouco tempo de experiência trabalhando com esse workflow front-end, já tenho uma base sólida e consiga passar esse conhecimento adiante. 8 | -------------------------------------------------------------------------------- /introducao/html-css-e-javascript-eram-suficientes.md: -------------------------------------------------------------------------------- 1 | # HTML, CSS e Javascript eram suficientes 2 | 3 | Por muito tempo isso foi tudo o que era preciso saber para trabalhar como webdesigner. Com o tempo, fui me aprofundando nessas tecnologias e adquiri experiência construindo coisas mais interessantes do que simplesmente mostrar a data e um menu pop-up (Eu estou falando de janelas modais, carrosseis, validação de formulário e menus drop-downs. Talvez no futuro alguém fale desses caras com certa nostalgia. Assim como eu fiz quando lembrei do window.open). 4 | 5 | A verdade é que até o final de 2013, trabalhando numa grande agência de publicidade, onde os projetos têm prazos curtos e ficam pouco tempo no ar, essas tecnologias eram tudo o que eu precisava. Lá, as vezes eu desenvolvia um projeto em uma semana para uma campanha que iria ficar on-line por 30 dias ou menos. 6 | 7 | Nessa época, já havia surgido muita coisa na área de front-end: node.js, automatização de tarefas, pré-processadores CSS, etc. Mas como não via chances de usar essas coisas na agência, dei uma lida sobre esses assuntos, mas logo me esqueci de tudo pela falta de utilização prática. 8 | -------------------------------------------------------------------------------- /introducao/no-comeco-era-tudo-tag.md: -------------------------------------------------------------------------------- 1 | # No começo era tudo TAG 2 | 3 | Me lembro até hoje, o momento em que criei o meu primeiro arquivo HTML. Isso foi lá pelo final dos anos 90, bem no meio da bolha. Eu abri um simples arquivo no notepad, escrevi ‘olá mundo’ envolto por uma simples tag ```h1``` e salvei o arquivo na área de trabalho com uma nova extensão, a tal da .html. E quando eu abri o arquivo, com um duplo clique, magicamente ele não abriu mais no bloco de notas, mas sim num programa muito melhor, o *Netscape navigator*. 4 | 5 | Algum tempo depois apareceu uma tecnologia revolucionária para formatação de páginas, chamada CSS. Adeus ``````. Aprendi várias novas propriedades de CSS que me ajudavam a colocar características visuais em meus sites montados com tabelas. Uma beleza! 6 | 7 | Também aprendi Javascript, para que eu pudesse mostrar a data e a hora, e oferecer um pop-up de boas-vindas a todos os meus visitantes. Aahh! que saudade do ```window.open```! 8 | -------------------------------------------------------------------------------- /introducao/para-quem-foi-escrito.md: -------------------------------------------------------------------------------- 1 | # Para quem foi escrito 2 | 3 | 4 | Com este material pretendo ajudar a galera que está começando agora e que já conhece e consegue se virar com Javascript, HTML e CSS. Se você se identificar com alguns dos aspectos abaixo, esse material é pra você: 5 | 6 | * Manjo de javascript mas gostaria de melhorar meu workflow front-end para desenvolvimento de sites ou aplicativos. 7 | * Quando abro um tutorial na internet que começa com uma frase parecida com "Para começar, digite sudo *npm install …*", ou - pior ainda - "Basta você digitar *npm install …*", fecho-o imediatamente antes que me contamine. 8 | * Sei da importância da performance de um site ou aplicativo, mas continuo entregando os mesmos javascripts de desenvolvimento em produção. 9 | * Versionamento? Claro! Sempre copio e colo a pasta de projetos colocando a data no nome da pasta. Além disso, nunca apago um trecho de código javascript. Sempre comento código velho que não está sendo mais necessário. Vai que eu precise dele no futuro. Nunca se sabe! 10 | * Eu ainda uso o bom e velho FTP para subir meus arquivos no servidor. Nunca falha. 11 | 12 | 13 | Se você se identificou com alguns pontos descritos acima, espero que este material seja útil para você. 14 | 15 | 16 | ## Se resolver continuar a leitura, você: 17 | 18 | 19 | * Irá perder o medo do terminal. 20 | * Irá conhecer um dos pré-processadores mais famosinhos do momento: o Sass. 21 | * Concatenará e minificará seus javascripts e css. Acredite: é moleza e vale a pena. 22 | * Nunca mais irá comentar códigos velhos com medo de precisar deles no futuro. 23 | * Nunca mais irá colocar seus arquivos de desenvolvimento em produção. 24 | * Não se assustará se abrir um tutorial na net que começa pedindo para você digitar algo começando com *npm install*. Você saberá o que isso significa e onde deverá digitar esse código maluco. 25 | 26 | 27 | Ou seja, No final deste livro (se é que posso chamá-lo assim), você terá uma base sólida para iniciar o desenvolvimento de aplicativos para a web. Hoje em dia, saber HTML, CSS e Javascript não é suficiente. Você precisa conhecer versionamento (Git e GitHub). Você precisa instalar uma ferramenta de build (Grunt ou Gulp). Você precisa saber manipular um gerenciador de dependencias (NPM ou NPM + Bower), e se souber também um pouco sobre pre-processadores CSS, terá uma maior produtividade e acrescentará no teu currículo. 28 | 29 | 30 | ## O que você não verá aqui 31 | 32 | 33 | * Detalhes sobre javascript, jquery, css e html. Espero que você já possua esses pré-requisitos. 34 | * Não vou desenvolver nenhum sistema do zero, e você não será um ‘ninja’ em Node.js. Meu intuito é fazer com que você saiba o básico, que eu adoraria que alguém tivesse me contado quando comecei a desenvolver aplicativos para a web. 35 | * Não vou explorar nenhum framework em particular. Pelo menos não por enquanto. 36 | * Mesmo sobre os assuntos que me proponho a explicar, por vezes não serei 100% fidedigno. Me proponho a explicar de um jeito fácil de entender. Provavelmente, se alguém tivesse feito isso comigo quando eu estava começando a entrar nesse terreno, algumas pedras sairiam do caminho antes de eu tropeçar. Pense assim: Se você tivesse que explicar javascript para alguém que está começando, provavelmente você não se preocuparia em explicar sobre escopo de variáveis. Estou quase certo que as suas variáveis estariam todas no escopo global. E sabemos que isso não é uma boa prática. Contudo, se entrar muito nesse nível de detalhe talvez você assuste o iniciante e o faça desistir antes mesmo de tentar. Nesse caso, não importa que o seu código se pareça com: 37 | ``` javascript 38 | var texto = "Olá mundo"; 39 | alert(texto); 40 | ``` 41 | Mesmo que isso não seja uma boa prática é fácil de entender. Lembre-se: os meus exemplos não têm a intensão de serem escritos como na vida real, contudo, espero te mostrar a base para que, depois, você possa avançar com os seus estudos. 42 | 43 | 44 | ## Softwares utilizados: 45 | 46 | 47 | ### Sistema Operacional: 48 | 49 | 50 | Eu sei que há na comunidade um certo estrelismo por quem usa o mac ou linux. Não quero entrar nesse mérito. Sei também que há um certo preconceito com o windows. Também não quero discutir isso. Mas o fato é que eu, desde o começo da minha carreira, trabalhei com windows. Portanto, não vou escrever nada que eu não tenha proficiência. Tudo que você verá aqui é voltado para o windows. Muitas coisas irão servir mesmo que você use o mac ou linux, mas não me comprometo com isso, uma vez que não tenho know-how nesses sistemas. Combinado? 51 | 52 | 53 | ### Editor de código: 54 | 55 | 56 | Há vários editores de código disponíveis no mercado e você provavelmente utiliza o Sublime Text com o package manager instalado e, no mínimo, o emmet. Isso não é primordial, mas sugiro que dê uma olhada no Sublime, se ainda não o conhece. 57 | Não faz diferença, nesse momento, se você usa o Notepad++, o Text Edit, o Brackets ou o Dreamweaver. Antes que chova pedra na minha cabeça, quero me explicar: já ví códigos muito mais semânticos e corretos escritos no Dreamweaver do que códigos escritos por pessoas que se achavam cools só porque usavam o Notepad ou Sublime. A ferramenta não é importante. O que importa é o desenvolvedor. É claro que com o tempo os devs com mais experiência tendem a abandonar o Dreamweaver e começar a utilizar um editor de código melhor. Mas isso não importa realmente. Se você usa o Dreamweaver, pense em ao menos experimentar algo diferente. E por falar nisso, eu comecei a escrever HTML usando o programa até então da Macromedia. Foi de lá que vieram os meus primeiros ```
um texto qualquer
62 | 63 | 64 | ``` 65 | 66 | 67 | Vamos investigar como está o nosso repositório git nesse momento (depois de alterar e salvar, não se esqueça, salvar é muito importante). 68 | 69 | ```$ git status``` 70 | 71 | O git nos dá duas informações muito importantes. A primeira é que há mudanças que não estão na área de stage, portanto, ainda não estão prontas para o próximo commit. A segunda é uma consequência da primeira, ou seja, não há mudanças para serem comitadas. 72 | 73 | Essa é a segunda pegadinha do Git. Ao alterarmos um arquivo que foi comitado previamente, precisamos incluí-lo novamente na área de stage e só depois podemos comitá-lo. Então vamos lá: 74 | 75 | ```$ git add exemplo01.html``` 76 | 77 | ```$ git commit -m "inclusao de paragrafo".``` 78 | 79 | 80 | Agora que nós temos o nosso primeiro html versionado, quero que você execute algumas tarefas: 81 | 82 | 1. criar um arquivo de estilo css/estilo.css 83 | 2. criar uma arquivo de javascript: js/app.js 84 | 3. criar um conteúdo qualquer dentro desses arquivos 85 | 4. vincular os dois arquivos à sua página html. 86 | 87 | Para referência, segue um exemplo bem bobinho que fiz apenas para mostrar: 88 | 89 | 90 | estilo.css: 91 | ```css 92 | body{ 93 | background: #ccc; 94 | } 95 | ``` 96 | 97 | 98 | app.js 99 | ```javascript 100 | var body = document.body; 101 | body.style.color = 'red'; 102 | ``` 103 | 104 | Nesse ponto vale uma dica: com o comando ```ls``` é muito difícil identificar o que é arquivo e o que é diretório. Faça um experimento, digite no terminal ```$ ls --color``` e veja o que acontece. 105 | 106 | 107 | Depois de vinculá-los à sua página, digite ```$ git status``` e analise o output no terminal. Se tudo estiver bem, você deverá ver que um arquivo já comitado anteriormente foi modificado, porém, os dois arquivos criados não estão sendo rastreados pelo Git, ou seja, não estão sendo versionados. Como são apenas dois arquivos, você poderia incluí-los um a um com o comando ```$ git add```. Porém, pense no caso de termos muitos arquivos, como fontes, imagens, audios, vídeos etc. Nesse caso, incluí-los um a um faria você desistir do versionamento nos primeiros dez arquivos. 108 | 109 | Para incluir todos os arquivos de uma vez, você poderia digitar o seguinte comando: 110 | ```$ git add .``` 111 | 112 | Observe o ponto no final. Esse sinal é o mesmo que dizer "todos os arquivos". 113 | 114 | Faça o teste: digite o comando acima e em seguida veja o que acontece quando você verifica o status novamente. 115 | 116 | Com tudo adicionado à área do stage, que informa que os arquivos estão preparados para serem comitados, basta você efetuar o comite normalmente 117 | 118 | ```$ git commit -m "Inclusão de javascript e css"``` 119 | 120 | Fácil, né? Incluímos todos os arquivos que não estavam na área de stage de uma única vez e depois comitamos normalmente. Contudo, digamos que depois do comite efetuado, o cliente pediu algumas alterações que precisam ser efetuadas tanto no arquivo de estilo quanto no arquivo de javascript. Como queremos manter o histórico, vamos alterar esses arquivos e efetuar um novo comite. Então vai lá. Altere os seus arquivos (pode ser qualquer alteração mesmo, ok). 121 | 122 | Pronto? agora digite ```$ git status``` novamente. Repare que Git nos mostra no output do terminal que dois arquivos (previamente adicionados à área do stage) foram modificados. E também nos dá uma dica do que podemos fazer: podemos digitar ```git add``` ou ```git commit -a``` para resolver a questão. 123 | 124 | O comando ```git commit -a``` mata dois coelhos com uma cajadada: acrescenta as modificações à área de stage e comita de uma só vez, porém, o jeito certo de usar esse comando é um pouco diferente. As três linhas de comando abaixo são equivalentes. Fica a seu gosto 125 | 126 | ``` 127 | $ git commit -a -m "mensagem do comite". 128 | ``` 129 | (a flag -a siginica "todos os arquivos" e -m significa que você quer digitar uma mensagem no comite). 130 | 131 | ``` 132 | $ git commit -am "mensagem do comite". 133 | ``` 134 | (é uma abreviação da linha acima, juntando as duas flags) 135 | 136 | ``` 137 | $ git commit -all -m "mensagem do comite". 138 | ``` 139 | (um pouco mais verboso, mas é exatamente a mesma coisa que as duas linhas acima). 140 | 141 | Mas atenção: a flag -a, ou uma das variações, só funciona se os arquivos alterados foram versionados previamente (com o ```$ git add``` ou ```$ git add .```). Se você nunca adicionou os arquivos à área de stage, a flag -a não produzirá resultado algum. 142 | 143 | 144 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") -------------------------------------------------------------------------------- /nodejs-npm-terminal.md: -------------------------------------------------------------------------------- 1 | # Nodejs, NPM e terminal 2 | 3 | Nesta seção você saberá, sem muitas explicações técnicas demais, o que é esse tal de NodeJS. Saberá o que é um terminal e o que é o NPM. Se você nunca mexeu num terminal e isso te assusta um pouco, fique tranquilo. Ao final dessa leitura você não dominará em detalhes a linha de comando, mas conseguirá se virar bem com qualquer tutorial da internet que espera que você já saiba o que é um programa de linha de comando. 4 | 5 | Boa leitura! 6 | 7 | -------------------------------------------------------------------------------- /pre-processadores-css.md: -------------------------------------------------------------------------------- 1 | #Pré-processadores de CSS 2 | 3 | Durante muito tempo eu relutei em trabalhar com um pré-processador de CSS. Escrever CSS é tão simples que achava não precisar de uma ferramenta para deixá-lo mais simples ainda. Mas a questão aqui não é se escrever folhas de estilo é simples ou não. A questão é deixar a escrita do CSS mais rápida e de fácil manutenção. Eu estava errado. 4 | 5 | Pense quantas vezes você precisou trocar um código hexadecimal em vários elementos. Provavelmente você fez uma busca em todo o seu arquivo CSS por uma determinada cor e a substituiu por uma nova cor, certo? E quando você precisou encontrar um trecho de CSS naquele seu arquivo com um milhão de linhas? Estas tarefas não são difíceis de serem executadas, é verdade. O 'F12' do crhome te ajuda a encontrar a linha específica do CSS que você precisa editar e você sempre tem a opção de um 'replace all'. Mas digamos que esse processo, apesar de ser simples, é um pouco chato e deselegante. 6 | 7 | Por isso está na hora de dar um up na maneira de escrever suas regras de folhas de estilos. Vamos nessa! 8 | 9 | 10 | -------------------------------------------------------------------------------- /pre-processadores-css/01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/01.jpg -------------------------------------------------------------------------------- /pre-processadores-css/02.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/02.jpg -------------------------------------------------------------------------------- /pre-processadores-css/03.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/03.jpg -------------------------------------------------------------------------------- /pre-processadores-css/04.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/04.jpg -------------------------------------------------------------------------------- /pre-processadores-css/05.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/05.jpg -------------------------------------------------------------------------------- /pre-processadores-css/06.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tapmorales/workflow-front-end/6e91d1f6a43e98fa5e813faba45cc67408dbed5c/pre-processadores-css/06.jpg -------------------------------------------------------------------------------- /pre-processadores-css/aplicando-sass-em-nosso-projeto.md: -------------------------------------------------------------------------------- 1 | #Aplicando Sass em nosso projeto 2 | 3 | Uma das principais vantagens em usar algum pré-processador de CSS é podermos modularizar a nossa folha de estilo em diversos arquivos independentes. A metodologia BEM, aplicada em nosso projeto, é meio caminho andado para separar responsabilidades de cada um dos componentes, deixando-os isolados e com formatações visuais bem definidas. 4 | 5 | Em nosso projeto, tenho apenas dois componentes: 6 | 7 | * mainHeader 8 | * buttonsContainer 9 | 10 | Em termos de estrutura de arquivos dentro de uma metodologia de desenvolvimento, eu poderia ter estes componentes inseridos em um diretório chamado _modules. 11 | 12 | Existem várias maneiras de organizar seus arquivos sass. Vale dar uma pesquisada na internet sobre como organizar estes arquivos ou inventar uma maneira própria. Não há regras. Mas o que se vê muito por aí é termos, basicamente, três principais diretórios: 13 | * _modules/ - armazena a formatação de componentes independentes, como por exemplo, carousel, modal, accordion etc. Por serem independentes, estes componentes não devem sofrer alterações visuais se você alterar a posição deles no seu HTML. Tanto faz se o seu caroussel estiver numa section, num article ou numa div. O resultado deve ser o mesmo. 14 | * _partials/ - aqui é onde armazenamos as informações da estrutura do site. Os arquivos dessa pasta devem ser responsáveis pela formatação da grid, do header, do footer etc. 15 | * _base/ - aqui é onde criamos as configurações principais do site. Definimos as cores, as fontes, os css resets etc. 16 | 17 | Como eu falei, não há uma regra. Sinta-se livre para modificar essa estrutura à vontade. 18 | 19 | 20 | Irei criar dentro da pasta sass de nosso projeto apenas dois diretórios: _base e _modules. dentro de _base irei criar dois arquivos: _variables.scss e _base.scss. Dentro de _modules criarei também dois arquivos: _mainHeader.scss e _buttonsContainer.scss. Na raiz, criarei o main.scss (sem o underline). 21 | 22 | Arquivos que contenham o underline inicial não serão compilados em arquivos CSS, ou seja, eles só podem ser importados para outros arquivos. 23 | 24 | Dentro de sass/ há um arquivo main.css. Não vamos mais utilizar esse arquivo, mas vou deixá-lo aí apenas para referência. No final desse tópico podemos apagá-lo sem problemas. 25 | 26 | 27 | 28 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") 29 | 30 | Segue uma imagem de como deve ficar a estrutura de arquivos. 31 | 32 | 33 |  34 | 35 | 36 | 37 | Antes de começarmos a ver o Sass em ação, vou fazer uma pequena alteração em nosso Gruntfile. 38 | 39 | Anteriormente, o autoprefixer usava o arquivo source/sass/main.css como base para salvar o novo deploy/css/main.css. Veja como era o nosso Gruntfile: 40 | 41 | ```javascript 42 | 43 | autoprefixer: { 44 | dist: { 45 | files: { 46 | 'deploy/css/main.css': 'source/sass/main.css', 47 | }, 48 | }, 49 | }, 50 | 51 | 52 | ``` 53 | 54 | 55 | Só que agora não há mais arquivo .css, ou pelo menos não haverá no futuro. Por isso, farei a seguinte alteração: 56 | 57 | ```javascript 58 | 59 | autoprefixer: { 60 | dist: { 61 | files: { 62 | 'deploy/css/main.css': 'deploy/css/main.css', 63 | }, 64 | }, 65 | }, 66 | 67 | 68 | ``` 69 | 70 | Repare que o arquivo de origem e destino é o mesmo. Quem irá gerar o mais.css será o Sass antes da tarefa autoprefixer ser executada. 71 | 72 | Precisamos, portanto, incluir a tarefa do sass. 73 | 74 | ```javascript 75 | sass: { 76 | dist: { 77 | files: { 78 | 'deploy/css/main.css': 'source/sass/main.scss', 79 | }, 80 | }, 81 | }, 82 | 83 | 84 | ``` 85 | 86 | Além disso, se você ainda não o fez, vamos carregar o grunt-contrib-sass: 87 | 88 | 89 | ```javascript 90 | 91 | grunt.loadNpmTasks('grunt-contrib-sass'); 92 | 93 | ``` 94 | 95 | E registrá-lo em nossa lista de tarefas: 96 | 97 | ```javascript 98 | grunt.registerTask('deploy', ['clean', 'sass', 'autoprefixer', 'cssmin', 'uglify', 'copy']) 99 | ``` 100 | 101 | No final, o nosso Gruntfile deve ficar semelhante à: 102 | 103 | 104 | ```javascript 105 | 106 | module.exports = function(grunt) { 107 | 'use strict'; 108 | 109 | grunt.initConfig({ 110 | sass: { 111 | dist: { 112 | files: { 113 | 'deploy/css/main.css': 'source/sass/main.scss', 114 | }, 115 | }, 116 | }, 117 | autoprefixer: { 118 | dist: { 119 | files: { 120 | 'deploy/css/main.css': 'deploy/css/main.css', 121 | }, 122 | }, 123 | }, 124 | 125 | copy: { 126 | dist: { 127 | files: [ 128 | { 129 | expand: true, //habilita o cwd 130 | cwd: 'source/', //relativo à source, mas não a inclui na cópia 131 | src: 'vendor/*', 132 | dest: 'deploy/' 133 | }, 134 | { 135 | expand: true, //habilita o cwd 136 | cwd: 'source/', 137 | src: 'index.html', 138 | dest: 'deploy/'} 139 | ] 140 | } 141 | }, 142 | 143 | clean: { 144 | dist: { 145 | src: ["deploy"] 146 | } 147 | }, 148 | 149 | cssmin: { 150 | dist: { 151 | files: { 152 | 'deploy/css/main.css': 'deploy/css/main.css' 153 | } 154 | } 155 | }, 156 | 157 | uglify: { 158 | options: { 159 | mangle: true 160 | }, 161 | 162 | dist: { 163 | files: { 164 | 'deploy/javascript/app.min.js': [ 165 | 'source/javascript/incrementButton.js', 166 | 'source/javascript/date.js' 167 | ] 168 | } 169 | }, 170 | } 171 | 172 | 173 | }); 174 | 175 | 176 | grunt.loadNpmTasks('grunt-autoprefixer'); 177 | grunt.loadNpmTasks('grunt-contrib-sass'); 178 | grunt.loadNpmTasks('grunt-contrib-cssmin'); 179 | grunt.loadNpmTasks('grunt-contrib-uglify'); 180 | grunt.loadNpmTasks('grunt-contrib-copy'); 181 | grunt.loadNpmTasks('grunt-contrib-clean'); 182 | 183 | grunt.registerTask('deploy', ['clean', 'sass', 'autoprefixer', 'cssmin', 'uglify', 'copy']) 184 | 185 | 186 | } 187 | 188 | 189 | ``` -------------------------------------------------------------------------------- /pre-processadores-css/consideracoes-finais.md: -------------------------------------------------------------------------------- 1 | #Considerações Finais 2 | 3 | A abordagem apresentada até este ponto não é a única possível, mas o meu intuito não é te apresentar tudo que está disponível no Sass, mas sim te mostrar os primeiros passos para que você consiga desenvolver os seus estudos. [Nesse site](http://sass-lang.com/guide) há mais alguns exemplos básicos sobre a utilização do Sass, em especial, veja com atenção sobre @extend e operadores. 4 | 5 | Todo esse conhecimento passado até aqui foi bem básico, mas se você quiser conhecer o Sass pra valer, vá até a [documentação](http://sass-lang.com/documentation/file.SASS_REFERENCE.html). 6 | 7 | Antes de finalizarmos, devemos remover as referencias aos arquivos .map. 8 | 9 | 10 | ##Removendo o sourceMap de produção 11 | 12 | Lembra que eu falei que não devemos colocar em produção os arquivos .map e que devemos remover as referências à estes arquivos? Pois então, para fazer isso, basta incluir uma opção nas configurações do Sass em nosso Gruntfile.js. Veja: 13 | 14 | ```javascript 15 | 16 | sass: { 17 | options: { 18 | sourceMap: false 19 | }, 20 | dist: { 21 | files: { 22 | 'deploy/css/main.css': 'source/sass/main.scss', 23 | }, 24 | }, 25 | } 26 | 27 | 28 | 29 | ``` 30 | 31 | ##automatização da automatização 32 | 33 | Para compilar seus arquivos, você pode digitar no terminal o nome da sua tarefa ou fazer com que, toda vez que um arquivo .scss seja alterado e salvo, o GruntJS rode automaticamente e tarefa necessária. 34 | Para isso você precisará instalar o [watch do grunt](https://github.com/gruntjs/grunt-contrib-watch). Este wrapper é responsável por monitorar alterações nos seus arquivos (.scss, por exemplo) e rodar determinadas tarefas quando estes arquivos forem salvos. Dessa forma, configurando corretamente, você consegue fazer com que o grunt rode a sua tarefa sass toda vez que um arquivo .scss for salvo, sem que você tenha digitar o tempo todo comandos no terminal para esta tarefa. 35 | 36 | 37 | ##Fallback com o Modernizr 38 | 39 | No componente buttonsContainer, você pode utilizar o sinal de & para criar um fallback de css para quando o browser não tiver suporte à todas as features utilizadas em nossa folha de estilo. 40 | 41 | ##Uma palavra sobre o BEM. 42 | 43 | Nesse ponto nosso arquivo está funcionando perfeitamente. Vimos como trabalhar com variáveis, @mixins/@include,seletor & e aninhamento de seletores. Dei uma rápida passada sobre as @function/@return e pedi para que você visse por conta própria sobre @extend e os operadores. Isso cobre uma parte de qualquer pré-processador, mas fique ciente que ainda há muito que não foi discutido. 44 | 45 | Para encerrar, gostaria de sugerir que você use com cautela o aninhamento de seletores. O meu exemplo foi para uso didático, mas creio que possa ser melhorado. 46 | 47 | Se olharmos com atenção para a metodologia BEM, vemos que não faz muito sentido termos seletores desse tipos: 48 | 49 | ```css 50 | .buttonsContainer .buttonsContainer__button 51 | ``` 52 | 53 | O seletor acima poderia ser facilmente substituído por: 54 | ```css 55 | .buttonsContainer__button 56 | ``` 57 | Concorda? 58 | 59 | Se achar válido, altere seus arquivos .scss para deixar os seletores do arquivo compilado mais simples, quando possível. -------------------------------------------------------------------------------- /pre-processadores-css/para-comecar.md: -------------------------------------------------------------------------------- 1 | #O que é preciso para começar? 2 | Antes de tudo, precisamos escolher um pré-processador de CSS para dar início à esta etapa do nosso workflow. Há três que dominam o mercado, o [Stylus](http://stylus-lang.com/), o [Less](http://lesscss.org/) e o [Sass](http://sass-lang.com/). 3 | 4 | O Sass é, atualmente, o mais usado e é o que eu vou utilizar nesse guia, mas tenha em mente que os conceitos mostrados aqui são válidos para qualquer pré-processador que você venha a escolher. 5 | 6 | Pense num pré-processador de CSS como sendo um software que recupera um código escrito em um formato diferente e o transforma na boa e velha folha de estilo em cascata , ou seja, você escreve num arquivo contendo outra extensão e o compilador gera o CSS comum. A vantagem é que com um pré-processador você ganha features que não estão disponíveis nativamente num CSS, como variáveis (mentira: [http://caniuse.com/#feat=css-variables](http://caniuse.com/#feat=css-variables)), loops, if e else, entre outras coisas legais. 7 | 8 | É importante salientar que há duas formas de escrevermos com o Sass. Há a sintaxe.sass (um pouco diferente do CSS tradicional. É baseado em indentações e quebras de linha) e o .scss (parecido com o CSS que estamos acostumados, por isso mesmo, é a minha sintaxe preferida. Esta sintaxe é baseada em chaves e ponto-e-vírgulas). 9 | 10 | Além de escolhermos nosso pré-processador e também a sintaxe, precisamos decidir qual a ferramenta que vamos utilizar para transformar nossos arquivos .scss em .css. Há o [Ruby](http://rubyinstaller.org/) e o [Libsass](http://libsass.org/). 11 | 12 | Originalmente, o Sass foi criado baseado em Ruby, porém, posteriormente surgiu o Libsass, escrito em C. O fato é que o compilador escrito em Ruby possui um melhor suporte às novas features, e por esse motivo será a minha escolha nesse guia (atualmente, início de 2016, acho que isto está mudando. Me senti tentado a escrever esse guia usando Libsass pela facilidade de não termos que instalar o Ruby, mas como tenho trabalhado com esta ferramenta de maneira satisfatória, darei preferência à ela). 13 | 14 | Antes de qualquer coisa, como estamos num ambiente windows, precisamos instalar o Ruby. Vá em [http://rubyinstaller.org/](http://rubyinstaller.org/) e faça o download. Depois... Ah!, você já sabe o que fazer. 15 | 16 |  17 | 18 |  19 | 20 | Mas atenção: Habilite a opção para adicionar uma variável PATH. Sem essa opção habilitada, você não conseguirá rodar o Sass da maneira como queremos. 21 | 22 |  23 | 24 | Depois de instalado, abra o terminal do Ruby (isso é importante). É a partir dele que iremos instalar o Sass. Digite: 25 | 26 | ``` 27 | gem install sass 28 | 29 | ``` 30 | 31 | Talvez seja necessário digitar o comando acima com permissão de administrador usando a palavra ```sudo```. 32 | 33 | ``` 34 | sudo gem install sass 35 | 36 | ``` 37 | 38 | Veja se tudo correu bem digitando 39 | 40 | ``` 41 | sass -v 42 | 43 | ``` 44 | 45 | Você deve visualizar a versão do sass instalado na sua máquina. 46 | 47 | --- 48 | 49 | Se você optar por compilar seus arquivos usando o Libssas, não precisará instalar o Ruby. Nesse caso, como estamos usando o node, você precisará instalar um wrapper chamado [node-sass](https://github.com/sass/node-sass). Veja mais detalhes [nesse link](http://sass-lang.com/libsass). 50 | 51 | --- 52 | 53 | 54 | Se você, assim como eu, instalou o Ruby e o Sass da maneira como descrevi acima, você será capaz de transformar seus arquivos .scss em .css através do próprio terminal do ruby. É algo muito simples. Basta digitar no terminal do ruby: 55 | 56 | ``` 57 | sass arquivo-fonte.scss arquivo-compilado.css 58 | ``` 59 | 60 | Porém, não entrarei em maiores detalhes sobre isso. A ideia é conseguirmos compilar nossos arquivos através do GruntJS e não através do terminal. Para isso, feche o seu terminal do ruby e abra o Git Bash. Como você já deve saber, precisamos instalar um wrapper do sass para o GruntJS, então… 61 | 62 | ``` 63 | $ npm install grunt-contrib-sass --save-dev 64 | ``` 65 | 66 | Depois disso, precisamos registrar essa tarefa no nosso Gruntfile.js 67 | 68 | ``` 69 | grunt.loadNpmTasks(‘grunt-contrib-sass’) 70 | ``` 71 | 72 | Para configurar o Sass dentro de nosso Gruntfile, temos duas opções: 73 | 74 | ###Opção 1 (simplificada): 75 | 76 | ```javascript 77 | 78 | sass: { 79 | dist: { 80 | files: { 81 | 'arquivo-compilado.css': 'arquivo-original.scss' 82 | } 83 | } 84 | } 85 | 86 | ``` 87 | 88 | 89 | ###Opção 2 (mais parruda): 90 | 91 | ```javascript 92 | 93 | sass: { 94 | dist: { 95 | files: [{ 96 | expand: true, //você já sabe o que isso faz 97 | cwd: 'source/sass', // você também já sabe o que isso faz. 98 | src: ['**/*.scss'], // onde estão os arquivos fontes 99 | dest: 'deploy/css', // pasta de destino. 100 | ext: '.css' // extensão do arquivo final. 101 | }] 102 | 103 | } 104 | } 105 | ``` 106 | 107 | 108 | Além disso, podemos passar algumas opções ao compilador. Veja: 109 | 110 | 111 | ###Opção 1 (simplificada - com opções): 112 | 113 | ```javascript 114 | 115 | sass: { 116 | dist: { 117 | options: { 118 | //opções de configuração 119 | }, 120 | files: { 121 | 'arquivo-compilado.css': 'arquivo-original.scss' 122 | } 123 | } 124 | } 125 | 126 | ``` 127 | 128 | 129 | 130 | ###Opção 2 (mais parruda - com opções): 131 | 132 | ```javascript 133 | 134 | sass: { 135 | dist: { 136 | options: { 137 | //opções de configuração 138 | }, 139 | files: [{ 140 | expand: true, //você já sabe o que isso faz 141 | cwd: 'source/sass', // Você também já sabe o que isso faz. 142 | src: ['**/*.scss'], // onde estão os arquivos fontes 143 | dest: 'deploy/css', // pasta de destino. 144 | ext: '.css' // extensão do arquivo fina. 145 | }] 146 | 147 | } 148 | } 149 | ``` 150 | 151 | 152 | No próximo tópico vamos aplicar todo esse conhecimento no nosso projeto. Até lá! 153 | 154 | 155 | 156 | 157 | -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-aninhamento-de-seletores.md: -------------------------------------------------------------------------------- 1 | ##Aninhamento de seletores 2 | 3 | 4 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") 5 | 6 | Entender como funciona o aninhamento de seletores no Sass é algo que não exige maiores explicações por ser bastante auto-explicativo. Veja um exemplo: 7 | 8 | O .scss ... 9 | 10 | ```scss 11 | #menu{ 12 | ul{ 13 | margin: 0px; 14 | padding: 0; 15 | li{ 16 | list-style-type: none; 17 | a{ 18 | text-decoration: none; 19 | } 20 | } 21 | } 22 | } 23 | 24 | 25 | ``` 26 | 27 | … gera o.css: 28 | ```css 29 | #menu { 30 | background: #ddd; 31 | } 32 | #menu ul { 33 | margin: 0px; 34 | padding: 0; 35 | } 36 | #menu ul li { 37 | list-style-type: none; 38 | } 39 | #menu ul li a { 40 | text-decoration: none; 41 | } 42 | 43 | ``` 44 | 45 | O problema do aninhamento é a sua facilidade. É tão fácil que se não tomarmos cuidado, podemos acabar com seletores do tipo: 46 | 47 | ```css 48 | main #mainContent #header #menu ul li a span.icon 49 | ``` 50 | Nós dois sabemos que seletores desse tipo são péssimos em termos de performance na renderização, os arquivos ficam mais pesados, ficam deselegantes e denigrem sua imagem como desenvolvedor. Nunca faça seletores desse tipo. (Para mim, isso é pior que usar o Dreamweaver ;) 51 | 52 | Mas nós podemos usar o aninhamento para gerar o efeito hover em um link, juntamente com a referência ao seletor pai ‘&’. Veja: 53 | 54 | o arquivo .scss ... 55 | ```scss 56 | a{ 57 | text-decoration: none; 58 | &:hover{ 59 | text-decoration: underline; 60 | } 61 | } 62 | 63 | ``` 64 | 65 | … gera o seguinte .css: 66 | 67 | ```css 68 | 69 | a{ 70 | text-decoration: none; 71 | } 72 | a:hover{ 73 | text-decoration: underline; 74 | } 75 | 76 | ``` -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-cores.md: -------------------------------------------------------------------------------- 1 | ##Funções relacionadas a cores 2 | 3 | Para facilitar minha vida, criarei uma variável para a cor cinza mais clara dentro do contexto de nosso componente. 4 | 5 | Onde eu precisar escurecer minha cor, chamarei uma função do Sass chamada darken($color, $amount). O segundo parâmetro é referente à porcentagem de escurecimento. 6 | 7 | ```scss 8 | 9 | .buttonsContainer{ 10 | 11 | $cor: #AFAFAF; 12 | 13 | border-top: 2px solid #A5A5A5; 14 | .buttonsContainer__button{ 15 | background-image: linear-gradient(to top, darken($cor, 15), $cor); 16 | border: none; 17 | padding: 1em; 18 | margin: 1em 0; 19 | cursor: pointer; 20 | outline: none; 21 | 22 | &:hover{ 23 | background-image: linear-gradient(to top, $cor, darken($cor, 15)); 24 | } 25 | &:active{ 26 | background-image: linear-gradient(to top, darken($cor, 14), darken($cor, 34)); 27 | } 28 | } 29 | 30 | .buttonsContainer__result--number{ 31 | font-weight: bold; 32 | } 33 | 34 | } 35 | 36 | 37 | 38 | ``` 39 | 40 | Eu usei [este site](http://sassme.arc90.com/) para me ajudar a escolher o valor do segundo parâmetro da função darken(). 41 | 42 | Está ficando bom, mas ainda pode ser melhorado. Você deve ter percebido que incluir a variável da cor dentro do contexto do container não é uma boa ideia. Se no futuro aparecer no layout um botão com destaque, por exemplo, teríamos que duplicar código (e é justamente para não ter que fazer isso que estamos usando o Sass). -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-import.md: -------------------------------------------------------------------------------- 1 | ##Declaração @import 2 | 3 | Uma coisa bem legal no sass é que podemos separar os nossos códigos em vários arquivos e importá-los num arquivo "pai". Apesar da semelhança de escrita de um import do css, a importação do scss é totalmente diferente. Se em css puro o import não é bem visto por ter problemas com o cache e com múltiplas requisições http, em sass ele é quase que obrigatório. O import do sass faz com que os blocos de códigos sejam inseridos num único arquivo. Logo, o resultado será um arquivo contendo todos os blocos, um a um, na ordem em que foram inseridos. 4 | 5 | Abra o seu main.scss e digite o seguinte: 6 | 7 | ```scss 8 | @import "_base/variables", 9 | "_base/base"; 10 | 11 | ``` 12 | Repare que não precisamos incluir o underline nem a extensão. O Sass já sabe do que se trata. Se você incluir o underline ou a extensão, tudo continuará funcionando da mesma forma. 13 | 14 | Agora sim, rode o seu grunt sass no terminal e veja o resultado. -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-juntando.md: -------------------------------------------------------------------------------- 1 | ##Juntando o aninhamento, variáveis e seletor pai 2 | 3 | O próximo passo é criarmos o nosso componente buttonsContainer. Abra esse arquivo e edite-o incluindo os aninhamentos necessários. Lembre-se que ele está em _modules/. 4 | 5 | .scss 6 | 7 | ```scss 8 | 9 | .buttonsContainer{ 10 | border-top: 2px solid #A5A5A5; 11 | 12 | 13 | .buttonsContainer .buttonsContainer__button{ 14 | background-image: linear-gradient(to top, #848484, #AFAFAF); 15 | border: none; 16 | padding: 1em; 17 | margin: 1em 0; 18 | cursor: pointer; 19 | outline: none; 20 | 21 | 22 | &:hover{ 23 | background-image: linear-gradient(to top, #AFAFAF, #848484); 24 | } 25 | &:active{ 26 | background-image: linear-gradient(to top, #868686, #565656); 27 | } 28 | } 29 | 30 | .buttonsContainer .buttonsContainer__result--number{ 31 | font-weight: bold; 32 | } 33 | 34 | } 35 | 36 | 37 | 38 | ``` 39 | 40 | Se você olhar bem, verá que há cores que se repetem. Parece interessante criarmos variáveis, não acha? Um detalhe importante é que o sass também possui escopo de variáveis. Veja um exemplo: 41 | 42 | ```scss 43 | 44 | .main{ 45 | $cor: red; 46 | h1{ 47 | color: $cor; 48 | } 49 | } 50 | div { 51 | background: $cor; 52 | } 53 | 54 | ``` 55 | 56 | O código acima irá gerar um erro pois a variável $cor não existe no contexto da div. 57 | 58 | Sabendo disso, vamos editar nosso componente 59 | 60 | ```scss 61 | 62 | .buttonsContainer{ 63 | $cor1: #848484; 64 | $cor2: #AFAFAF; 65 | border-top: 2px solid #A5A5A5; 66 | 67 | 68 | .buttonsContainer__button{ 69 | background-image: linear-gradient(to top, $cor1, $cor2); 70 | border: none; 71 | padding: 1em; 72 | margin: 1em 0; 73 | cursor: pointer; 74 | outline: none; 75 | 76 | 77 | &:hover{ 78 | background-image: linear-gradient(to top, $cor2, $cor1); 79 | } 80 | &:active{ 81 | background-image: linear-gradient(to top, #868686, #565656); 82 | } 83 | } 84 | 85 | .buttonsContainer__result--number{ 86 | font-weight: bold; 87 | } 88 | 89 | } 90 | 91 | 92 | ``` 93 | 94 | Não há nada de errado com o código acima. Mas ele ainda pode ser melhorado. Se prestarmos atenção, todas as cores são variações de cinza. E se tivéssemos uma função que consiga clarear ou escurecer um cor? Ah! sim. [Nós temos esse tipo de coisa no sass](http://sass-lang.com/documentation/Sass/Script/Functions.html). -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-map.md: -------------------------------------------------------------------------------- 1 | ##Entendendo o arquivo .map 2 | Coisa linda. Se tudo correu bem, temos um main.css compilado e um arquivo novo chamado main.css.map. Este arquivo é usado para debugar o código (você já deve ter se deparado com esse arquivo em bibliotecas como o jquery). Ele não deve ser levado para produção. Além disso, a referência /*# sourceMappingURL=main.css.map */ deve estar presente apenas no ambiente de desenvolvimento. 3 | 4 | Por enquanto, vou deixar o arquivo .map sendo criado normalmente. Em breve iremos configurar o sass para não gerar esse sourceMap. 5 | 6 | Se você inspecionar o seu html pelo Chrome (em um servidor, pois o sourceMap não funciona em file://…) você verá que o Browser mostra a referência ao arquivo .scss e não ao .css, como era esperado. Assim, quando você tiver muitos arquivos, muitos componentes, muitas partials etc, ficará fácil saber quem é o sass responsável por aquela formatação. Se não existisse o .map, você teria que avaliar o arquivo compilado e "caçar" nos arquivos fontes. Isso seria uma grande perda de tempo. 7 | 8 |  9 | 10 | O arquivo de extensão .map serve para nos ajudar no ambiente de desenvolvimento. Conforme podemos observar, ao inspecionar um elemento html, o web inspector do google chrome nos mostra o arquivo fonte .scss, e não o .css compilado. Isso é muito útil quando tivermos muitos componentes gerando um único e extenso arquivo final. 11 | -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-mixin.md: -------------------------------------------------------------------------------- 1 | ##@mixin 2 | 3 | 4 | 5 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") 6 | 7 | Para resolver o problema de reutilização de código comentado no tópico anterior, criarei um @mixin que gere todo o código do botão e que receba por parâmetro a cor base. Farei isso da seguinte maneira: 8 | 9 | ```scss 10 | 11 | @mixin gerarBotao($cor){ 12 | background-image: linear-gradient(to top, darken($cor, 15), $cor); 13 | border: none; 14 | padding: 1em; 15 | margin: 1em 0; 16 | cursor: pointer; 17 | outline: none; 18 | 19 | &:hover{ 20 | background-image: linear-gradient(to top, $cor, darken($cor, 15)); 21 | } 22 | &:active{ 23 | background-image: linear-gradient(to top, darken($cor, 14), darken($cor, 34)); 24 | } 25 | } 26 | 27 | 28 | ``` 29 | 30 | O @mixin é o responsável por criar dinamicamente todo o código do botão, incluindo o hover e o active. Há no sass a opção de criarmos uma @function, porém, em nosso exemplo, uma @function não nos ajudaria, uma vez que esta retorna apenas um valor, enquanto um @mixin retorna diversos valores. 31 | 32 | Tenha em mente que, ao criarmos um @mixin, precisamos utilizá-lo usando a palavra @include. Se usarmos uma @function, temos que retornar o valor com a palavra @return e chamar a função do local que queremos usar aquele valor. 33 | 34 | Apenas para exemplificar o uso de uma @function, vou criar uma função que recebe dois valores e calcula a porcentagem: 35 | 36 | ```scss 37 | @function calc-percent($target, $container) { 38 | @return ($target / $container) * 100%; 39 | } 40 | ``` 41 | 42 | Quando precisarmos utilizar essa função, teremos que chamá-la de dentro da regra css. 43 | 44 | ```scss 45 | .modulo { 46 | width: calc-percent(500px, 1000px); 47 | } 48 | ``` 49 | 50 | Voltando ao nosso exemplo, para utilizar o @mixin criado, precisamos da palavra @include. Veja como deve ficar: 51 | 52 | ```scss 53 | 54 | @mixin gerarBotao($cor){ 55 | background-image: linear-gradient(to top, darken($cor, 15), $cor); 56 | border: none; 57 | padding: 1em; 58 | margin: 1em 0; 59 | cursor: pointer; 60 | outline: none; 61 | 62 | &:hover{ 63 | background-image: linear-gradient(to top, $cor, darken($cor, 15)); 64 | } 65 | &:active{ 66 | background-image: linear-gradient(to top, darken($cor, 14), darken($cor, 34)); 67 | } 68 | } 69 | 70 | .buttonsContainer{ 71 | 72 | border-top: 2px solid #A5A5A5; 73 | 74 | .buttonsContainer__button{ 75 | @include gerarBotao(#AFAFAF) 76 | } 77 | 78 | .buttonsContainer__result--number{ 79 | font-weight: bold; 80 | } 81 | 82 | } 83 | 84 | 85 | ``` 86 | 87 | E se no futuro precisarmos de uma variação desse mesmo botão, poderemos simplesmente passar uma nova cor como parâmetro: 88 | 89 | ```scss 90 | 91 | .buttonsContainer__button{ 92 | @include gerarBotao(#AFAFAF) 93 | } 94 | 95 | .buttonsContainer__button--hightlight{ 96 | @include gerarBotao(red) 97 | } 98 | 99 | 100 | ``` -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-seletor-pai.md: -------------------------------------------------------------------------------- 1 | ## Referência ao seletor pai 2 | 3 | O nosso próximo passo é incluirmos o componente mainHeader. Para isso, crie o seguinte código em _modules/_mainHeader.scss 4 | 5 | ```scss 6 | 7 | .mainHeader{ 8 | color: #bbb; 9 | text-shadow: 2px 2px 1px rgba(0,0,0,.6); 10 | } 11 | 12 | 13 | ``` 14 | Em seguida, importe-o no main.scss e rode novamente ``` $ grunt sass ```. 15 | 16 | Nada de novo aqui. Porém, a grande sacada é que, mesmo que você não goste do IE, precisa gostar dos usuários que o utilizam, assim como Deus abomina o pecado, mas ama o pecador. 17 | 18 | Sabemos que text-shadow [não funciona em IE antigo](http://caniuse.com/#search=text-shadow), e sinceramente, eu nem ligo. Mas o que eu não posso permitir é que os usuários do IE9 ou mais velhos tenham acesso prejudicado ao conteúdo simplesmente por utilizarem browsers antigos. 19 | 20 |  21 | 22 | Conforme podemos observar, a legibilidade do título é prejudicada quando o browser não tiver suporte ao text-shadow. Ou seja, nestes casos, precisamos mostrar o texto com uma fonte um pouco mais escura. 23 | 24 | Para resolver essa questão, vou utilizar o símbolo ‘&’ que representa um seletor pai, juntamente com o modernizr que inserimos lá no começo do nosso guia. 25 | 26 | Edite o arquivo da seguinte forma: 27 | 28 | ```scss 29 | 30 | .mainHeader{ 31 | 32 | font-size: 1.2em; 33 | 34 | .textshadow &{ 35 | color: #bbb; 36 | text-shadow: 2px 2px 1px rgba(0,0,0,.6); 37 | } 38 | 39 | .no-textshadow &{ 40 | color: #717171; 41 | } 42 | } 43 | 44 | 45 | 46 | 47 | ``` 48 | 49 | Incluí propositalmente um font-size para você avaliar o resultado. Abra o arquivo main.css em deploy e veja o que representa o sinal ‘&’. Perceba que fica muito mais fácil dar manutenção. Você pode até não se dar conta disso agora, mas tente implementar esse conceito no próximo código que você precisar escrever. 50 | 51 | Repare que no exemplo acima eu também aninhei seletores do CSS, algo muito usado (mas que também pode se tornar um pesadelo se não for usado com cautela). Veremos isso daqui a dois segundos. 52 | 53 | 54 | 55 | 56 | -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa-variaveis.md: -------------------------------------------------------------------------------- 1 | ##Variáveis 2 | 3 | 4 | 5 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") 6 | 7 | Sabemos que o arquivo _base/_variables.scss deve conter as principais configurações visuais de todo o site/aplicativo. Portanto, vamos editá-lo com o seguinte código: 8 | 9 | ```scss 10 | 11 | $bg-color: #ccc; 12 | $font: arial, sans-serif; 13 | 14 | ``` 15 | 16 | Repare que as variáveis em sass começam com um sinal de '$'. 17 | 18 | Agora, em _base/_base.scss, digite o seguinte código: 19 | 20 | ```scss 21 | 22 | body{ 23 | background: $bg-color; 24 | font-family: $font; 25 | } 26 | 27 | ``` 28 | Muito simples! A varíável $bg-color armazena o valor #ccc e esta é usada na declaração CSS background: $bg-color; Ou seja, no arquivo compilado teremos o resultado: 29 | 30 | ```css 31 | 32 | background: #ccc; 33 | 34 | ``` 35 | 36 | Pode parecer bem bobinho neste exemplo, mas num código extenso, saber utilizar bem as variáveis pode te poupar muito retrabalho. 37 | 38 | Se você se adiantou e rodou o comando no seu terminal para compilar os seus arquivos, você deve ter percebido que o main.css ficou sem nenhuma regra visual. Isso ocorre porque a tarefa do grunt compila o arquivo main.scss em main.css. Ou seja, para vermos o sass trabalhando precisamos importar nossos arquivos recém criados. -------------------------------------------------------------------------------- /pre-processadores-css/pondo-a-mao-na-massa.md: -------------------------------------------------------------------------------- 1 | #Pondo a mão na massa 2 | 3 | A partir desse ponto temos o nosso Gruntfile configurado para compilar os nossos arquivos e também temos uma estrutura muito simples de diretório que os armazenará. 4 | 5 | Tentarei aqui exemplificar algumas funcionalidades do Sass aplicado ao nosso mini-minuscúlo-pequeno projeto e como utilizá-lo para resolver problemas em projetos reais. Não falarei de todas as funcionalidades, mas como darei exemplos práticos, acredito que o aprendizado será muito mais proveitoso. 6 | 7 | Uma grande vantagem do uso de qualquer pré-processador de css é poder trabalhar com variáveis. Em sites grandes, é muito comum ter que mudar uma propriedade como uma cor, um valor de opacidade ou o tamanho de uma fonte em mais de um lugar no código. É nesses cenários que as variáveis fazem sentido. 8 | 9 | 10 | [](https://www.udemy.com/ferramentas-front-end-git-npm-script-gulp-e-sass/?couponCode=PROMOLIVRO20 "12 horas de video. Apenas R$ 20,00. Acesso vitalício e sem mensalidades") -------------------------------------------------------------------------------- /turbinando-o-node/dependencias-de-producao-vs-de-desenvolvimento.md: -------------------------------------------------------------------------------- 1 | #Dependências de produção vs. de desenvolvimento 2 | 3 | Há dois tipos de dependências em projetos NodeJS. Vamos estudá-las. 4 | 5 | ##Dependências de produção 6 | São aquelas dependências que precisam estar em produção para que seu projeto funcione. Por exemplo: jquery, angular, bootstrap etc. 7 | Se você deseja instalar um módulo de produção, basta digitar em seu terminal: 8 | 9 | ```$ npm install