Iniciando o front-end de um projeto - Parte 1

A camada client de um projeto é tão fundamental quanto o server-side. Controversamente ela sempre é deixada de lado no que diz respeito a otimização e organização. Parece que o desenvolvedor front-end tem uma mania absurda de diminuir sua importância em um projeto e se limitar às gambiarras e deslexos comuns pra maioria dos programadores - bom, quem nunca fez aquela "gambis" marota, né?

Nossa empresa, a MustacheLabs, está começando agora, e por isso, estamos tentando criar processos e boas práticas para desenvolvimento. Tudo isso durante os sprints, no dia-a-dia.

O objetivo é que, além de tornar ágil o desenvolvimento, também facilite a manutenção e deixe o código mais sustentável.

Um dos pontos que começamos a pensar é definir o core de front-end da aplicação. Pra isso resolvi listar nessa série quais pontos pretendemos fechar.

Lembre-se que é apenas um breve resumo de cada item. Não é uma tese completa e aprofundada, nem um artigo complexo.

Dividi em algumas partes pra facilitar a leitura. Então... vamos lá!


1. Antes do back-end

Durante o início do projeto, muita coisa ainda não é definida e a camada de back-end não foi pensada de forma total - muito menos desenvolvida.

Pra não travarmos o desenvolvimento do front-end, resolvemos subir uma aplicação com o Sinatra.

Faz mais sentido pra gente porque a maioria dos nossos projetos são construídos utilizando Rails. O Sinatra é uma aplicação super leve em Ruby que, explicando de modo bem simplório, gerencia suas rotas, serve arquivos estáticos, entre outras coisas que você pode encontrar aqui.

A partir daí você pode fazer qualquer coisa, e uma delas é o gerenciamento das views com templates.

Assim, enquanto a estrutura do back-end não é definida, temos possibilidade de andar com o front, sem atrasar o projeto.

1.1 Templates

Em praticamente todos os projetos devemos evitar repetição de código. Seja ela no javascript ou no markup. No html, utilizamos templates.

O uso do template na verdade não é condicionado ao tamanho do site/sistema/aplicativo. Você precisa tornar isso padrão, por mais que o projeto seja pequeno.

Um template pode ser criado para:

  • um menu;
  • um header,
  • um corpo de texto;
  • slideshow;
  • qualquer objeto comum pertencente ao layout, que se repita em sua estrutura por uma ou mais vezes.

Como ainda estamos na parte de front-end, rodando o web server com Sinatra, optamos por usar o próprio pra gerenciar as views. Isso provisóriamente, já que provavelmente o CMS tenha um render mais avançado dessas views, usando controllers, passando dados e parâmetros, e etc.

Pra usar templates com Sinatra é increvelmente simples, como demonstra a documentação dele, e você pode usar qualquer linguagem de template como erb, haml, nokogiri, etc.

Usamos o erb (conheça mais aqui), que já é nativo do Ruby. A sintaxe dele é bem simples, como no exemplo abaixo, demostrando uma iteração de um array @news.

<ul>
    <% # Onde @news é uma hash com notícias %>
    <% @news.each do |news| %>
        <li>
            <%= news.title %>
        </li>
    <% end %>
</ul>

1.2 Organização das views

Resolvemos adotar outra prática comum que é separar nossas views de forma mais clara.

Como você deve ter visto mais sobre o Sinatra nos links acima, temos o gerenciamento de rotas bem simplificado, como no exemplo abaixo:

Ex: Quando a url for http://hostname/ a view home/index.erb é renderizada usando o application.erb

# my_application.rb

class MyApplication < Sinatra::Base

  get "/" do
      erb :"home/index", :layout => :application
  end

end

Na pasta view temos:

/views
    # Application é o template base
    application.rb

    # index.erb é o conteúdo interno da home
    /home
        index.erb

E como é que o index é inserido dentro do template application?

R: No application.rb você precisa ter um <%= yield %> pra que o index.erb seja inserido dentro dele.

Você pode usar yields com nomes que você queira, como:

<%= yield_content :styles %>

<%= yield_content :header_area %>

Viu? Simples e prático. Já temos um esqueleto pra renderizar nossas views de forma quase dinâmica, imitando a aplicação que virá, nesse caso, pelo Rails.

Depois da lógica do back-end estar pronta a migração pra camada do Rails é muito simples, tanto quanto um copy & paste =)

1.3 HTML5 Boilerplate

Decidimos usar o HTML5 Boilerplate como padrão do nosso scaffolding, mas com nossas adaptações e especificações. Não foge em nada praticamente desse padrão.

Esse boilerplate é mantido pela comunidade, portanto, use com confiança!


2. Estrutura dos assets

Já vi vários projetos muito confusos na hora de separar um asset do outro. Seguem abaixo algumas práticas não muito legais...

# Fonte dentro de CSS
/css
    /fonts

# Duas pastas de imagens
/img
/images

# Confusão com os scripts
/javascripts
    - main.js
/libs
    - jquery.js

# Tudo junto e misturado
/stylesheets
    common.css
    main.css
    footer.css
    news.css
    posts.css
    sliders.css
    ...

Decidimos padronizar da seguinte forma:

/assets
    /stylesheets
    /javascripts
    /fonts
    /images

Dentro de stylesheets, convencionamos que:

  • O que é comum entre as páginas fica no /common;
  • O que é específico pra cada página, fica em /pages;
  • O que pertence a uma lib, fica em /libs;
  • É um mixin? Então, /mixins;
  • Um main é pra importar tudo o que estiver em /common e /libs, já que essas podem ser necessárias em todas as páginas.

Resumindo

/assets

    /stylesheets

        main.css.scss

        /common
            variables.css.scss
            header.css.scss
            footer.css.scss
            lists.css.scss
            buttons.css.scss
        /pages
            home.css.scss
            contact.css.scss
        /libs
            sliderX.css.scss

        /mixins
            button-bordered.css.scss
            shadow-text.css.scss

Podem haver casos mais específicos que esses, mas invariávelmente isso se repete pra quase todos.


Bom... por enquanto demos o primeiro passo. Ainda outras partes virão e assim que publicar, atualizo esse post com o link da Parte 2.

comments powered by Disqus