-
Notifications
You must be signed in to change notification settings - Fork 0
Frontend
Olá.
Nessa Wiki você encontrará informações sobre como se portar junto ao time frontend da Din Digital, desde como escrever seu CSS e JS até quais padrões indicamos para escrita.
A maioria do conteúdo dessa wiki não é o como você vai fazer - tecnicamente - mas o que deve ser feito/levado em consideração no desenvolvimento.
Lembrando que TODA sugestão é bem vinda.
Hoje utilizamos SMACSS e BEM para a escrita de CSS.
Para mais informações, consulte a discussão da equipe sobre o alinhamento de escrita.
Geralmente nos deparamos com inclusões de códigos externos e, visando isso, padronizamos nomes de classes e IDs da seguinte forma:
.l-header {}
.m-card {}Caso encontre o prefixo dd, ele faz referência à Din Digital, m significando Módulo, em SMACSS e card é o seu módulo em si, e é encontrado em projetos antigos.
Tentar sempre utilizar o bloco com apenas um única palavra, mas se passar separar palavras por hífen.
Da forma padrão do BEM, utilizamos o elemento separado do bloco com dois underlines:
<a class="l-header__logo" href="/"></a>Reduzimos a escrita e repetição de texto original do BEM e os modificadores são escritos apenas com os dois hífens:
<button class="dd-m-button --filled --primary">Muitas vezes utilizar margens fixas em módulos/seções podem causar problemas, principalmente se os espaçamentos não estiverem padronizados. Por isso recomenda-se utilizar um spacer. Exemplo no Codepen.
Utilizado principalmente nos projetos da Giungla, o Carrefour Property possui o spacer em todo o site.
Utilizamos o Sass na extensão .scss para escrita de CSS.
Utilizamos o gulp quando o projeto é do zero - independente da tecnologia - ou o Sass puro. Também trabalhamos com webpack quando o projeto é Laravel, pois o framework já nos traz essa opção por default.
Em projetos antigos da Din Digital você poderá se deparar com grunt.
Podemos e é indicado pelo Sass não passar de 4 aninhamentos, mas conseguimos até 3, certo?!
Os pontos acima também servem para desenvolvimento de Apps com Ionic.
Trabalhamos com funções auto invocadas, ex:
(function(){
// some code…
})();Também declaramos variáveis públicas e privadas, visando o reaproveitamento de módulos entre páginas do site. Ex:
var $private = {};
var $public = {};Temos um arquivo exemplo que você pode startar.
Também visamos o aproveitamento de módulos da aplicação, ou seja, quanto mais modularizado, melhor.
Você pode se sentir livre para utilizar ES6/7, desde que use um transpiler/compiler, como o Babel.
Atomic Design para aplicações Node.JS.
Como sempre, estamos abertos a novas ideias.
Indicamos impreterivelmente o padrão do John Papa para desenvolvimento JS com o framework.
Os pontos acima também servem para desenvolvimento de Apps com Ionic.
Indicamos o Swiper para criação de sliders, carrosséis e outros.
Na discussão na talk de fronts discutimos sobre sobre o documento completo e extenso sobre normas para as leis de acessibilidade que governo criou.
Importante também utilizar o Checklist da The A11Y Project enquanto desenvolvemos alguma aplicação.
A Axe DevTools é uma extensão Chrome para validar pontos de acessibilidade. Além desse, a W3 recomenda diversos outros validadores.
Em geral, podemos concatenar e minificar os assets de uma aplicação em:
2 arquivos - para libs externas:
vendor.jsvendor.css
1 arquivo - para toda a aplicação, visando reaproveitamento de código/módulos:
app.jsapp.css
E 1 arquivo para a página atual, e.x.:
contact.jscontact.css
Reforçamos que existem ocasiões onde não vale a pena fazer essa separação. Pense no seguinte cenário: na página de contato utilizamos uma lib externa para envio de formulário, e essa lib é usada somente nessa página. Nesse caso, podemos verificar o tamanho dessa lib e, se for pequena como o projeto, não vemos problemas em deixa-la em vendor.js/css, entretanto se a lib for grande e o projeto também, recomendamos fortemente a inclusão do arquivo em contact.js/css.
Contamos com o seu bom senso antes de botar a mão na massa, por isso, converse com a equipe em caso de dúvidas, sugestões, etc.
Todo projeto deve ser desenvolvido visando uma boa nota no pagespeed. Muitos clientes levam isso em consideração. Recomendamos fortemente que seja sempre feita uma verificação quando um update for realizado e, em casos que o projeto estiver sendo desenvolvido do zero, que o time verifique constantemente a nota.
É muito mais fácil verificar o pagespeed em pequenas partes do que como um todo.
Aqui você encontra dicas de como seguir no desenvolvimento de módulos e como testar a parte de front de um site.