O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

don't repeat yourself front-ender

443 visualizações

Publicada em

Desenvolvedores sempre buscaram escrever menos e fazer mais. Mas como aplicar a filosofia DRY com tecnologias que inicialmente não foram projetadas especificamente para desenvolver apps? Vamos aprender nessa talk quais são as boas práticas, metodologias e ferramentas para repetir menos e produzir mais!

A web é uma das principais plataformas de desenvolvimento de aplicações. Hoje (quase) tudo está conectado na internet. Apps cada vez mais dinâmicas aumentaram a complexidade do desenvolvimento de interfaces web. Em consequência desse crescimento, surgiram metodologias e ferramentas para repetir menos código, modularizar e criar componentes para a web. No passado trabalhamos com iframes e no futuro talvez teremos web components funcionando em todos os browsers. Mas e hoje, como podemos aplicar a filosofia DRY?

Publicada em: Educação
  • Seja o primeiro a comentar

don't repeat yourself front-ender

  1. 1. DON’T REPEAT YOURSELF, FRONT-ENDER! @fernahh
  2. 2. blog.fernahh.com.br
  3. 3. www.organicadigital.com
  4. 4. Don’t Repeat Yourself [...] Propõe que cada porção de conhecimento em um sistema deve possuir uma representação única, de autoridade e livre de ambiguidades em todo o sistema. - Wikipédia
  5. 5. Escrever algo apenas uma vez; Pensar sempre em reuso; Ser específico; Se algo tem mais de uma funcionalidade, divida em quantas vezes for necessário para fazer apenas uma. REPRESENTAÇÃO ÚNICA LIVRE DE AMBIGUIDADES
  6. 6. Escrever menos com tecnologias web está ligado diretamente com performance. - Wikipédia
  7. 7. É sempre bom lembrar... 80-90% do tempo de carregamento de uma página é gasto no front-end! - Steve Sounders
  8. 8. <span class="icon"></span> <i class="icon"></i> HTML
  9. 9. .button {} CSS .botao {} .btn {}
  10. 10. if (foo.length === 0) {} JavaScript if (foo === "") {} if (foo.isEmpty()) {}
  11. 11. Bibliotecas <script src="//code.jquery.com/jquery-1.2.4.min.js"></script> <script src="https://ajax.googleap is.com/ajax/libs/jquery/1.11.3 /jquery.min.js"></script> <script src="jquery.js"></script>
  12. 12. Bibliotecas <script src="//code.jquery.com/jquery-1.2.4.min.js"></script> <script src="https://ajax.googleap is.com/ajax/libs/jquery/1.11.3 /jquery.min.js"></script> <script src="jquery.js"></script>
  13. 13. HTML A reutilização da marcação é correta?
  14. 14. Componente de tabs do Bootstrap <ul class="nav nav-tabs"> <li class="active"><a href="#">Home</a></li> <li><a href="#">Profile</a></li> <li><a href="#">Messages</a></li> </ul>
  15. 15. Componente de navbar do Bootstrap <ul class="nav navbar-nav"> <li><a href="#">Home</a></li> <li><a href="#">Profile</a></li> <li><a href="#">Messages</a></li> </ul>
  16. 16. Perdemos muito tempo em tentativa e erro de retirar pedaços e tentando inserir outros pedaços no meio da árvore de HTML e decifrando nomes de classes CSS. - Fabio Akita
  17. 17. Componente do Google Maps <div id="map"></ul> <script> map = new google.maps.Map(document.getElementById('map'), { center: {lat: -34.397, lng: 150.644}, zoom: 8 }); </script>
  18. 18. Server rendered pages are not optional. - Guillermo Rauch http://rauchg.com/2014/7-principles-of-rich-web-applications/
  19. 19. HTML enviado pelo servidor de aplicações Meteor. http://tableless.com.br/nos-quebramos-web/
  20. 20. %strong{:class => "foo", :id => "bar"} Hello, World! <strong class="foo" id="bar">Hello, World!</strong>
  21. 21. strong.foo#bar Hello, World! <strong class="foo" id="bar">Hello, World!</strong>
  22. 22. strong.foo#bar Hello, World! <strong class="foo" id="bar">Hello, World!</strong>
  23. 23. Os problemas com pré- processadores de HTML: - Pré-processadores geralmente são mais complexos; - Quase ninguém olha o output dessas ferramentas; - O futuro da linguagem é sempre ela mesma!
  24. 24. Mas qual o futuro do HTML?
  25. 25. Para alguns desenvolvedores (principalmente os do Google), o futuro do HTML são Web Components.
  26. 26. Web Components? Custom Elements HTML Imports Templates Shadow DOM
  27. 27. Custom Elements Permite criarmos novos elementos HTML.
  28. 28. Component paper-tabs <paper-tabs selected="0"> <paper-tab>Home</paper-tab> <paper-tab>Profile</paper-tab> <paper-tab>Messages</paper-tab> </paper-tabs> https://elements.polymer-project.org/elements/paper-tabs
  29. 29. Good parts - Não temos ambiguidade; - Ganhamos tags amigáveis; - Encapsulamento de tags.
  30. 30. - Novos elementos não possuem semântica nenhuma; - Alguns elementos possuem comportamento atribuído pelo agent do usuário; - Dependemos de JavaScript para load do conteúdo. Bad parts
  31. 31. HTML Imports Permite fazermos load de outros documentos HTML
  32. 32. HTML Imports na prática <head> <link rel="import" href="bootstrap.html"> </head> http://www.akitaonrails.com/2014/07/06/web-components-e-uma-revolucao
  33. 33. Good parts - É uma forma de empacotarmos compontentes; - Faz todo sentido com HTTP/2.
  34. 34. - No HTTP/1.1 por ser um problema gigante; - É inviável controlar versões de um componente; - O JavaScript do documento importado é executado no mesmo escopo. Bad parts que perigo!
  35. 35. Templates Permite utilizarmos um mesmo bloco de código através de JavaScript.
  36. 36. HTML <template id="foo"> <img src=""></img> </template> JavaScript var t = document.querySelector('#foo').content(); t.querySelector('img').src = 'avatar.jpg'; document.body.appendChild(t.cloneNode(true));
  37. 37. Good parts - É uma tentativa de padronizar o uso de templates; - Todas as soluções atuais são gambiarras.
  38. 38. - O conteúdo só é acessível via JavaScript; - Não tem os mesmos benefícios de bibliotecas atuais. Bad parts
  39. 39. Shadow DOM Permite criarmos elementos de DOM independentes e isolados do restante da página.
  40. 40. HTML <style> #foo: {color: blue;} </style> <h1 id="foo"></h1> JavaScript var foo = document.querySelector('#foo').createShadowRoot(); foo.innerHTML = '<p>Foobar</p>';
  41. 41. Good parts - Hoje é a única forma de isolarmos marcação, comportamento e estilo; - É a melhor forma de criarmos widgets; - Nos permite criar componentes que possuem parâmetros.
  42. 42. - Perdemos o estilo da página a cada shadow DOM. Bad parts
  43. 43. TL;DR ~ Web Componentes nos ajudam a repetir menos? - Custom Elements são mais elegantes do que criarmos elementos com Js; - Shadow DOM é infinitamente melhor do que usarmos Iframe; - Template é uma boa tentativa ao invés de uma tag script; - Não é uma revolução, é uma tentativa de oficializarmos práticas já existentes; - Se Web Compontents serão úteis ou não, depende do ecossistema em volta da sua aplicação.
  44. 44. As melhores práticas não estão necessariamente no futuro Nunca se falou tanto em componentes para a web nos últimos anos. Porém, para construir componentes precisamos saber usar muito bem os três pilares da web: HTML, CSS, e JavaScript.
  45. 45. Especificidade Efeito Cascata Herança Arquitetura de CSS
  46. 46. CSS
  47. 47. CSS 2 3 1
  48. 48. CSS 2 3 1 !IMPORTANT
  49. 49. Especificidade de seletores - CSS inline: 1000 pontos; - ID: 100 pontos; - Classes, pseudo-elementos e atributos: 10 pontos; - Elementos: 1 ponto;
  50. 50. Sempre que você usa !important, você quebra a especificidade.
  51. 51. https://twitter.com/rafaelrinaldi/status/586216597913739264
  52. 52. Técnica uilizada para definir o estilo a um seletor mesmo em caso de conflitos. O coração do CSS
  53. 53. Definindo o peso de uma regra - Importância; - Origem; - Especificidade; - Ordem da declaração.
  54. 54. HERANÇA Herença? OO? Assim como você herda métodos e atributos de objetos, no CSS você herda as regras de um elemento pai.
  55. 55. /* * Todo o conteúdo textual do documento * terá 16px de tamanho, pois herdam do * `body`. */ body { font-size: 16px; }
  56. 56. HERANÇA height, width, margin, padding Propriedades que se referem ao box-model não aceitam herança, porém podemos forçar com o valor inherit.
  57. 57. Super poderes para o CSS Pré-processadores deram super poderes para desenvolvedores escreverem CSS. Em nosso contexto, @extend e mixins nos trazem benefícios, mas que devem ser usados com bastante cautela.
  58. 58. @extend Permite estender placeholders e classes, porém, muitos autores desencorajam a usar esse recurso.
  59. 59. .error { color: red; } .icon--error { @extend .error; }
  60. 60. .error { color: red; } .icon--error { @extend .error; } /* * Resultado gerado pelo Sass. */ .error, .icon-error { color: red; }
  61. 61. .other__context .error { color: darken(red, 10%); }
  62. 62. .other__context .error { color: darken(red, 10%); } /* * Resultado gerado pelo Sass. */ .other_context .error, .other_context .icon-error { color: #cc0000; }
  63. 63. Isso é péssimo! Além de tirar o controle do desenvolvedor, o Sass irá gerar código desnecessário e prejudicar outras áreas de uma interface.
  64. 64. .error, %error { color: red; } .icon--error { @extend .error; } .other__context .error { color: darken(red, 10%); }
  65. 65. /* * Resultado gerado pelo Sass. */ .error { color: red; } .icon--error { color: red; } .other__context .error { color: #cc0000; }
  66. 66. Resumindo sobre @extend Evite ao máximo. Talvez você nem precise. Se realmente quiser usar, vá de placeholders.
  67. 67. Mixins Mixins são eficientes pois eles injetam código somente onde ele foi usado, além de ser muito úteis quando precisamos de parâmetros.
  68. 68. @mixin error { color: red; } .icon--error { @include error; } .label--error { @include error; }
  69. 69. /* * Resultado gerado pelo Sass. */ .icon--error { color: red; } .icon--error { color: red; }
  70. 70. @mixin error($critical: false) { @if $critical { color: darken(red, 10%); } @else { color: red; } } .icon--error { @include error; } .icon--critical_error { @include error($critical: true); }
  71. 71. /* * Resultado gerado pelo Sass. */ .icon--error { color: red; } .icon--critical_error { color: #cc0000; }
  72. 72. Concatenação de classes O uso de composição/concatenação de classes é muito usado em frameworks de CSS. O popular Bootstrap faz bastante uso dessa abordagem.
  73. 73. .button { display: inline-block; padding: 10px; color: black; background-color: white; } .button--sucess { color: white; background-color: green; }
  74. 74. No CSS nem tudo depende da tecnologia Uma das melhores formas de não repetir código, encapsular e escrever menos e produzir mais é aplicando sistemas de arquitetura de CSS.
  75. 75. OOCSS Qualquer estilo da página que se repete pode ser aplicado através de uma classe, ou seja, um “objeto”.
  76. 76. <button class="button anchor-icon">Abrir</button> estrutura skin
  77. 77. BEM Block, Element, Modifier. Preza que o nome das classes sejam auto- explicáveis.
  78. 78. <button class="button button__anchor_icon">Abrir</button> módulo elemento
  79. 79. SMACSS Foi criado para resolver os problemas do Yahoo Mail. É dividido em base, layout, module, state. Não é apenas um sistema de escrita, é uma metodologia.
  80. 80. SMACSS > Base Contém todo o conteúdo global da aplicação, ou seja, seletores que não possuem classe ou id. exemplo: body, a, p, h1, ul, etc.
  81. 81. SMACSS > Layout Possui seletores agregadores da aplicação. exemplo: #header, #container, #footer.
  82. 82. SMACSS > Module Englobam componentes que podem ser reusáveis. exemplo: .search-box, .box, .content-box.
  83. 83. SMACSS > State São estados dos módulos da aplicação. exemplo: .is-complete, .is-ready, .is-current.
  84. 84. SMACSS > Theme São as diferentes variações dos módulos. exemplo: .button-black, .button-navy.
  85. 85. <button class="button button-anchor">Abrir</button> módulo sub-módulo
  86. 86. Especificidade Efeito Cascata Herança Arquitetura de CSS Nunca saia escrevendo CSS até dar certo. Entenda as regras e planeje seus passos.
  87. 87. COMO APLICAR COMPORTAMENTO AOS COMPONENTES?
  88. 88. Module Pattern Permite organizar bem o código, manter o escopo de variáveis e simular privacidade de funções e atributos.
  89. 89. Module Pattern (function(){ // ... }());
  90. 90. Muitos plugins jQuery usam esse pattern (function($){ // ... }(jQuery));
  91. 91. Privacidade de atributos var Counter = (function(){ var count = 0; return { count: function() { return count; }, increment: function() { return count += 1; } }; })();
  92. 92. Privacidade de atributos var Counter = (function(){ var count = 0; return { count: function() { return count; }, increment: function() { return count += 1; } }; })(); dessa forma não quebramos o encapsulamento da variável count!
  93. 93. ES6 Modules É a melhor forma de definirmos módulos JavaScript hoje!
  94. 94. util.js function multiplicacao(a, b) { return a * b; }; export { multiplicacao }
  95. 95. util.js function multiplicacao(a, b) { return a * b; }; export { multiplicacao } app.js import { multiplicacao } from 'util';
  96. 96. Revisando: Markup Estilo Comportamento
  97. 97. Revisando: Markup Estilo Comportamento Como gerenciar esses componentes?
  98. 98. Gerenciadores de pacotes > Bower Gerenciador de pacotes front-end. http://bower.io
  99. 99. Ferramentas > Bower > bower commands # procurar um pacote $ bower search jquery # instalar um pacote $ bower install jquery --save # atualizar um pacote $ bower update jquery # remover um pacote $ bower remove jquery
  100. 100. Ferramentas > Bower > .bowerrc { "directory": "vendor/assets/components" }
  101. 101. Ferramentas > Bower > bower.json { "name": "nome-do-app", "private": true, "dependencies": { "jquery": "~1.11.1", "normalize-css": "~3.0.1", "modernizr": "~2.8.3", } }
  102. 102. Gerenciadores de pacotes > npm Gerenciador de pacote oficial do NodeJS. http://npmjs.com
  103. 103. Gerenciadores de pacotes > npm > npm commands # procurar um pacote $ npm search jquery # instalar um pacote $ npm install jquery --save # atualizar pacotes $ npm update # remover um pacote $ npm uninstall jquery
  104. 104. Gerenciadores de pacotes > npm > package.json { "name": "nome-do-app", "private": true, "devDependencies": {} }
  105. 105. Revisando: Markup Estilo Comportamento Gerenciar componentes
  106. 106. - Aprenda bem a web antes de qualquer ferramenta; - Converse muito com os (UX) designers do seu time; - Converse muito com os desenvolvedores do seu time; - Documente.
  107. 107. OBRIGADO! @fernahh fernahh@gmail.com blog.fernahh.com.br

×