Loop Infinito

Hoisting e escopo em JavaScript

2014-10-29T00:00:00-07:00

O JavaScript é uma linguagem cheia de pequenas surpresas que pode espantar até o mais experiente programador. Vamos tomar como exemplo o trecho de código abaixo. Você sabe quais valores serão impressos?

// Exemplo 1
var a = 1

function foo() {
  console.log(a)
  var a = 2
  console.log(a)
}

foo()

console.log(a)

Pela “lógica”, deveria ser primeiro impreso 1, 1 e 2, correto? Não. E neste outro trecho de código, qual será a saída?

// Exemplo 2
function foo() {
  function bar() {
    return 3
  }

  return bar()

  function bar() {
    return 8
  }
}

console.log(foo())

Se você não respondeu undefined, 2 e 1 para o exemplo 1 e 8 para o exemplo 2, aconselho a leitura deste post. Aqui vamos discutir um pouco sobre o hoisting no JavaScript. Mas antes de elaborarmos mais sobre os motivos que levaram nosso código a se comportar de tal forma, vamos de volta ao básico e falar sobre escopo.

Escopo

Escopo em JavaScript é um tópico que gera bastante confusão para iniciantes na linguagem. Apesar de pertencer a família das linguagens baseadas em C, o escopo em JavaScript não funciona da mesma forma como em C, C++ ou mesmo Java. Vamos usar o seguinte trecho de código em C como exemplo:

// Exemplo 3
#include <stdio.h>

int main() {
  int a = 1;
  printf("%d\n", a); //=> 1

  if (1) {
    int a = 2;
    printf("%d\n", a); //=> 2
  }

  printf("%d\n", a); //=> 1
}

No código acima, o exemplo 3 irá imprimir 1, 2 e 1. Isso acontece porque em C (assim como Java e C++), temos escopo por bloco. Em JavaScript só temos escopo a nível de função. O código anterior traduzido de uma forma “ingênua” pra JavaScript seria algo assim:

// Exemplo 4
var a = 1
console.log(a) //=> 1

if (true) {
  var a = 2
  console.log(a) //=> 2
}

console.log(a) //=> 2

Mas este código — exemplo 4 — não se comporta da mesma forma que o código anterior em C — exemplo 3. Repare que o bloco if não cria um escopo. Logo, quando a variável recebe o valor 2, ela continuará com este mesmo valor mesmo fora do bloco if.

Para criarmos um escopo dentro do if temos que usar uma função — uma IIFE — pois, em JavaScript, esta é a única ferramenta que temos para criar um escopo.

// Exemplo 5
var a = 1
console.log(a) //=> 1

if (true) {
  (function() {
    var a = 2
    console.log(a) //=> 2
  }())
}

console.log(a) //=> 1

Agora sim nosso algoritmo em JavaScript está se comportando de forma semelhante ao nosso código anterior em C. Mesmo sendo considerada como uma linguagem que pertence a família C, escopo em JavaScript funciona de um modo bastante diferente. Lembre-se: escopo em JavaScript apenas com o uso de funções. E com o uso de closures podemos criar escopos onde e quando quisermos em nosso código, simulando assim o comportamento de outras linguagens.

Declaração e nomes no escopo

Existem 4 maneiras de um nome entrar em um escopo em JavaScript:

Definido pela linguagem: todo escopo possui o this, e caso seja uma função, também o arguments.
Parâmetros de uma função: caso uma função seja chamada na forma foo(a, b), a e b entram no escopo da função.
Declaração de uma função: funções declaradas na forma function foo() {}.
Declaração de uma variável: variáveis declaradas como var bar.

Porém, para cada diferente método de entrada no escopo há diferença na ordem de resolução de nomes. Alguns podem ser resolvidos primeiro mesmo aparecendo ao fim do escopo, enquanto outros podem ter apenas seus nomes resolvidos, sem ter seus valores inicializados. E é esse comportamento não explicito de resolução de nomes e inicialização de valores do JavaScript que foi batizado como hoisting por Ben Cherry.

Hoisting

Hoist em inglês significa levantar ou suspender algo através de um aparato mecânico. Em bom português, significa usar o guindaste para elevar um objeto. E é isto o que acontece em JavaScript quando declaramos uma variável ou função. Sua declaração é “elevada” para o topo do escopo.

Apesar de não ser óbvio, o modo como o hoisting funciona é fácil de ser entendido. Vamos estudar todos os casos e saber como se comporta mais esse dark corner da nossa querida linguagem.

Variable hoisting

Toda vez que uma variável é definida, sua declaração é hoisted, mas não sua inicialização. O que quer dizer que a declaração da variável vai para cima do escopo antes mesmo do código ser executado, mas esta variável não recebe nenhum valor e permanece como undefined.

// Exemplo 6
// Irá imprimir o erro dentro do `catch`
try {
  console.log(a)
} catch (e) {
  console.error('A variável `a` não foi definida.')
}

// Exemplo 7
// Irá imprimir `undefined`
try {
  console.log(a)
  var a = 2
} catch (e) {
  console.error('A variável `a` não foi definida.')
}

Reparem no código acima que no exemplo 6, quando tentamos imprimir o valor de a, recebemos um erro pois esta variável não existe. Já no exemplo 7, undefined será impresso, mesmo tendo a declaração de a depois do do comando console.log. Ali ocorreu um hoisting da declaração da variável a, mas não da sua inicialização.

O código do exemplo 7 se comporta da mesma forma que este no exemplo 8:

// Exemplo 8
// Irá imprimir `undefined`
try {
  var a
  console.log(a)
  a = 2
} catch (e) {
  console.error('a não existe no contexto atual')
}

No código acima — exemplo 8 — reescrevemos o exemplo 7 de tal forma que faça mais sentido para nós, já que este código será executado de forma linear.

Repare que apenas a declaração da variável vai para o topo, mas não sua inicialização. Esta continua no mesmo lugar em que definimos no nosso código. Por isso recebemos um undefined quando tentamos acessar seu valor.

Apenas a declaraçãode uma variável é hoisted, não sua inicialização.

Function hoisting

O hosting com funções acontece de maneira diferente. Aqui, não só o nome da função é hoisted como também seu corpo.

// Exemplo 9
foo()
function foo() {
  console.log('bar')
}

O código acima irá imprimir bar, sem nenhum erro. Mesmo executando uma função antes mesmo de ser definida. Isso porque tanto o nome da função como seu corpo são hoisted.

Vamos analisar novamente o exemplo 2 que apareceu logo no começo do post. Por que seu output é 8?

// Exemplo 2
function foo(){
  function bar() {
    return 3
  }

  return bar()

  function bar() {
    return 8
  }
}

console.log(foo())

Dentro do escopo da função foo, primeiro temos a definição da função bar que já está no topo. Depois do return temos uma outra definição de função com o nome de bar. Apesar de aparecer ao fim do escopo, ela é hoisted — vai para o topo antes da execução. Como ela é a segunda função com o mesmo nome, ela acaba por sobreescrever a primeira, e o nome bar acaba por fazer referência à segunda função.

Uma função pode ser declarada também como uma expressão, e quando declarada desta forma, ela obedece a regra de hoisting de variável. Apenas seu nome será hoisted.

// Exemplo 10
foo() //=> TypeError
var foo = function() {}

No exemplo acima — exemplo 10 — será disparado um erro do tipo TypeError, nos avisando que undefined não pode ser usado como uma função.

ECMAScript 6

O ECMAScript 6 introduz um novo meio de definir variáveis através do let. Com ele nós temos escopo a nível de bloco. No exemplo 11 temos um trecho de código extraído da MDN.

// Exemplo 11
function varTest() {
  var x = 31
  if (true) {
    var x = 71 // mesma variável
    console.log(x) // 71
  }
  console.log(x) // 71
}

function letTest() {
  let x = 31
  if (true) {
    let x = 71 // variável diferente
    console.log(x) // 71
  }
  console.log(x) // 31
}

Com o let, é criado um diferente escopo também dentro de blocos como if, for, while, etc.

Outra diferença com o uso do let é que não temos hoisting, ou seja, a declaração da variável não vai para o topo do escopo antes da execução do código.

// Exemplo 12
function fooLet() {
  console.log(bar) //=> ReferenceError
  let bar = 2
}
fooLet()

function fooVar() {
  console.log(bar) //=> Undefined
  var bar = 2
}
fooVar()

No exemplo 12 temos dois trechos de código, um deles declara a variável bar com var, o outro com let. Quando usamos let não há hoisting, e então recebemos um ReferenceError.

Protip

Como dica para evitar comportamentos inesperados, declare todas suas variáveis — todas mesmo — no topo das funções, utilize apenas um único var por escopo e habilite a flag onevar do JSHint.

ECMAScript 6 Proxy

2014-09-09T00:00:00-07:00

O termo proxy tem suas origens no Direito dos países de língua inglesa. Um proxy é alguém com poderes legais de representar uma outra pessoa. No Brasil seria algo como alguém que possui uma procuração para representar uma outra. Por analogia, o termo acabou sendo usado na computação para designar softwares que atuam por outros como, por exemplo, um Web Proxy, que funciona como um intermediário para requisições de um cliente a um servidor externo.

No ECMAScript 6, um proxy é um objeto que representa um outro. Ele é capaz de interceptar chamadas às propriedades do objeto alvo, podendo até mesmo alterar o resultado da chamada.

Show me the code

Para melhor entender, vamos utilizar um exemplo simples.

function Pessoa(nome, idade) {
  this.nome = nome
  this.idade = idade
}

var joao = new Pessoa("João", 37)
console.log(joao.idade) //=> 37

Acima criamos uma função construtora Pessoa e logo após instanciamos um objeto do tipo Pessoa. Checamos sua idade com console.log e temos o resultado esperado: 37.

Agora vamos usar um Proxy para interceptar chamadas à propriedade idade do objeto joao:

proxy = new Proxy(joao, {
  get: function(target, prop) {
    if (prop === "idade") {
      console.log("Acesso a prop. idade interceptado")
    }

    return target[prop]
  }
})

Vamos passo-a-passo no código acima. O construtor de um proxy aceita dois argumentos: o primeiro é o target — o objeto que queremos interceptar as chamadas — o segundo é um objeto, que chamaremos por handler, que define o comportamento do proxy.

As chaves do objeto handler são chamadas de traps — ou armadilhas — com os valores sendo funções que definem como o proxy irá se comportar quando esta trap for disparada.

Acima usamos apenas a trap get, que é disparada quando tentamos ler uma propriedade do target — o objeto que está sendo interceptado. Vamos discutir mais a fundo sobre todas as traps logo.

Também é possível utilizar o proxy não apenas como intermediário, mas também como única porta de entrada para o objeto alvo, de forma transparente. Para isso, basta armazenar na variável que faz referência ao objeto alvo a própria referência ao proxy.

console.log(joao.idade) //=> 37

joao = proxy
console.log(joao.idade) //=> Acesso a prop. idade interceptado
                        //=> 37

Sendo assim, todo código que fazia referência à variável joao passará agora pelo proxy e este irá interceptar as chamadas ao objeto sem que seja alterado nenhum código antigo.

Aplicações

Por ser uma API muito nova, a comunidade ainda há de criar os melhores cases de uso dessa nova feature do JavaScript. Porém, alguns cenários já se mostram ideais para a aplicação dos proxies.

Validação

Podemos usar a armadilha set para validarmos o novo valor de uma propriedade do objeto alvo. Caso seja um valor inválido, disparamos um erro e o valor não é alterado.

joao = new Proxy(joao, {
  set: function(target, prop, val) {
    // Verifica se estamos acessando a propriedade `idade` do obj. alvo
    if (prop === "idade") {
      val = parseInt(val, 10)

      // Verifica se o novo valor é um inteiro
      if (isNaN(val) || !isFinite(val)) {
        throw new TypeError("Idade deve ser um inteiro")
      }

      // Verifica se o novo valor é igual ou maior que 0
      if (val < 0) {
        throw new RangeError("Idade deve ser igual ou maior que 0")
      }

      // Verifica se o novo valor é menor que 200
      if (val >= 200) {
        throw new RangeError("Idade deve ser menor que 200")
      }

      // Comportamento padrão para armazenar o novo valor
      target[prop] = val
    }
  }
})

joao.idade = "Uma string" // Irá disparar o erro `TypeError`

Neste exemplo estamos validando se a idade é:

Um número inteiro
Maior ou igual a zero
Menor que 200

Perceba que a validação ocorre de forma transparente. Não é usado nenhum método setIdade ou outro método que funciona de intermediário de forma explícita.

Log

Com um proxy fica fácil criar uma função que recebe um objeto, intercepta e loga todos os acessos às suas propriedades.

function loggable(target) {
  target =  new Proxy(target, {
    // Armadilha de acesso a propriedades
    get: function(target, prop) {
      console.log('Lendo prop. ' + prop)
      return target[prop]
    },

    // Armadilha de modificação de propriedades
    set: function(target, prop, val) {
      console.log('Mudando valor da prop. ' + prop + ' para ' + val)
      target[prop] = val
    },

    // Armadilha de deleção de propriedades
    deleteProperty: function(target, prop) {
      console.log('Deletando prop. ' + prop)
      delete target[prop]
    }
  })
}

var joao = new Pessoa("João", 37)
// Loga o acesso a todas as propriedades do objeto `joao`
loggable(joao)

joao.idade //=> Lendo prop. idade
joao.idade = 38 //=> Mudando valor da prop. idade para 38. Era 37
delete joao.idade //=> Deletada prop. idade

No exemplo acima criamos uma função loggable que recebe um objeto como argumento e retorna um proxy que imprime na saída padrão todo o acesso, mudança e deleção de propriedades do objeto interceptado.

Armadilhas

Abaixo, uma lista com algumas das armadilhas que achei mais úteis. Vale lembrar que existem outras além das que estão listadas abaixo. Uma documentação atualizada e completa sobre armadilhas nos proxies pode ser vista na Mozilla Developer Network.

Get

Disparada quando se tenta acessar uma propriedade no objeto alvo. A assinatura do handler é a seguinte: get function(target, name, receiver) -> any.

var foo = {bar: 1}

foo = new Proxy(foo, {
  get: function(target, name, receiver) {
    // Seu código aqui...

    // Comportamento padrão de acesso a propriedade
    return target[name]
  }
})

foo.bar // Armadilha `get` será disparada nesta linha

Set

Disparada quando se tenta trocar o valor de uma propriedade do objeto alvo. A assinatura do handler é: set function(target, name, val, receiver) -> boolean.

var foo = {}

foo = new Proxy(foo, {
  set: function(target, name, val, receiver) {
    // Seu código aqui...

    // Comportamento padrão
    return target[name] = val
  }
})

Has

Disparado quando é verificado se uma propriedade existe no objeto alvo através do código prop in proxy. A assinatura do handler é: has function(target, name) -> boolean.

var foo = {bar: 1}

foo = new Proxy(foo, {
  has: function(target, name) {
    // Comportamento padrão
    return name in target
  }
})

Enumerate

Retorna um array de string com o nomes das propriedades que devem ser lidas em um loop for in. A assinatura do handler: enumerate function(target) -> [String].

var foo = {lorem: 1, ipsum: 2}

foo = new Proxy(foo, {
  enumerate: funtion(target) {
    return ['lorem']
  }
})

for (prop in foo) {
  // irá iterar apenas na propriedade `lorem`
}

Suporte

Proxy	*	--	32	--	--
* implementado, porém na antiga especificação

Agora as más notícias. Atualmente a última versão da Proxy API definida no ECMAScript 6 só está disponível no Firefox. No V8, a máquina virtual de JavaScript do Chrome e Node.js, ela também está presente, porém está implementada conforme a definição antiga. Entretanto é possível usar um shim, como o harmony proxy, para normalizar a antiga API com a nova no Chrome e Node.js.

Para mais informações sobre compatibilidade do ECMAScript 6 com os mais populares ambientes JavaScripts, aconselho uma visita na tabela de compatibilidade do kangax.

A metáfora do escritório

2014-07-22T00:00:00-07:00

Usar um computador nem sempre foi uma tarefa fácil — não que hoje o seja. Computadores eram telas pretas com letras verdes. Máquinas que executavam uma única tarefa por vez a partir da entrada de comandos no terminal. Comandos esses difíceis de serem decorados e quase impossíveis de serem deduzidos.

Por volta de 1960, computadores começavam a ganhar alguma popularidade fora das empresas, principalmente entre grupos de hobbistas. Pessoas essas que gastavam um bom tempo lendo grossos manuais para só então serem capaz de interagir com um computador. Toda essa complexidade assustava a maioria das pessoas e era, obviamente, um grande empecilho para a popularização destas fantásticas máquinas.

Era necessário uma mudança radical no modo de interagir com um computador. Algo mais visual, mais próximo da realidade de um ser humano e mais distante da realidade baixo nível de uma máquina. Porém, a tecnologia necessária simplesmente não existia para tal quebra de paradigma.

A Mãe de Todos os Demos

Na ciência estamos sempre nos apoiando em ombros de gigantes. Com a invenção da Interface Gráfica não foi diferente. Não houve de fato um inventor, mas sim uma série de melhorias que foram feitas em cima da geração anterior.

Um dos primeiros teóricos sobre o assunto foi Vannevar Bush, engenheiro americano chefe do escritório Office of Scientific Research and Development durante a segunda guerra mundial que, em 1945, publicou um artigo com o título “As We May Think” descrevendo sua visão do futuro de como usaríamos máquinas — chamadas por ele de Memex — para acessar um vasto conjunto de dados ligados entre si (linked data).

Este artigo serviu de inspiração para Douglas Engelbart. Durante sua estadia na faculdade de Stanford, no Vale do Silício, ele formou o Augmentation Research Center e lá concebeu algumas das invenções bases para a GUI ser o que é hoje. Entre essas invenções estava o mouse, um dispositivo que permitia mover um ponteiro através da tela e manipular informação de uma maneira mais flexível e natural.

The digital revolution is far more significantthan the invention of writing or even of printing — Douglas Engelbart

Em dezembro de 1968, em San Francisco, Douglas Engelbart demonstrara todas as novas invenções feitas por sua equipe. Entre essas invenções estava o já citado mouse e também o conceito de janelas, hipertexto, gráficos, vídeo conferência, processador de texto, controle de versão e um editor de texto colaborativo. Essa apresentação foi — e é — um marco na história da computação, e ficou conhecida como A Mãe de Todos os Demos, a demonstração mais fantástica e à frente de seu tempo da área. Ela pode ser — e deveria ser — vista completa aqui.

PARC

A próxima onda de inovação no campo das Interfaces Gráficas do Usuário aconteceria em Palo Alto, no lendário laboratório PARC (Palo Alto Research Center) da Xerox, onde, em 1970, boa parte da equipe de Engelbart foi trabalhar. Lá refinaram suas ideias e inclusive conseguiram implementar e comercializar estas novas ideias, em 1981, com o computador Xerox Star.

O Xerox Star foi o primeiro computador comercial a vir com uma interface gráfica do usuário baseada em janelas (windows), ícones, pastas, um mouse, rede ethernet, servidor de arquivos, servidor de impressão e e-mail.

Ele foi, também, o primeiro computador a empregar a técnica de bit mapping. Em essência, tudo na tela do Xerox Star era uma imagem. A técnica de bit mapping tornou mais simples o ato de se trabalhar com gráficos e também permitiu que o computador apresentasse na tela uma exata representação do que seria impresso. O que ficou conhecido como WYSIWYG (What You See Is What You Get).

Muitos creditam a invenção das interfaces gráficas como conhecemos hoje ao PARC. Lá, eles não só criaram (refinaram) a GUI, como também inventaram a programação orientada a objetos — com a linguagem Smalltalk — o design pattern MVC, a impressora a laser, o ethernet, editores de texto WYSIWYG e tantas outras.

Os cientistas do PARC definiram a base da Interface Gráfica do Usuário como sendo o WIMP, sigla para Windows, Icons, Menu and Pointer Device. Até hoje, a maioria dos sistemas desktops, entre eles Windows, OS X, Gnome, KDE, utilizam essa base.

The best way to predict the future is to invent it — Alan Kay

Em cima desses elementos básicos, foi criada a Metáfora do Escritório. Os cientistas do PARC, principalmente Alan Kay, decidiram usar metáforas a tarefas comuns em um escritório para diminuir a curva de aprendizado de uso de um computador.

A metáfora

A primeira Graphical User Interface, ou GUI, era uma metáfora a um ambiente de escritório. O desktop, ou área de trabalho, representava uma mesa de escritório. Em cima dela tínhamos papéis, que eram arquivos do computador.

Estes mesmos arquivos podiam ser agrupados em pastas, assim como papéis são organizados em pastas nos escritórios. Os arquivos poderiam ser jogados em uma lixeira, tal qual, também, é feito em um escritório. Estes arquivos poderiam, inclusive, serem resgatados da lixeira, do mesmo modo que podemos fazer com um papel amassado jogado no lixo.

Além da metáfora do escritório, foi desenvolvido o conceito de janelas. Cada janela representaria um aplicativo aberto. Cada aplicativo aberto seria o equivalente a um papel em uma mesa. Nele o trabalho aconteceria.

A Apple foi uma das grandes responsáveis pela popularização da GUI. Steve Jobs em uma visita ao Xerox PARC conheceu a GUI, e logo percebeu que aquilo era o futuro. A Xerox estava com problemas para vender o Xerox Alto, o único computador que até então rodava com uma GUI. Jobs então fez uma proposta a Xerox para comprar a GUI, e implementar no que viria a ser o Apple Lisa.

No vídeo abaixo temos uma propaganda de televisão da Apple, anunciando seu novo computador e a sua GUI com a metáfora do escritório como sendo um diferencial entre outros produtos da época, devido a sua facilidade de uso. Perceba como o ator usa o seu dedo como ponteiro, simulando um mouse, apontando para objetos que o Mac simula em sua interface, como papéis, pastas e calculadora.

Praticamente todos os sistemas operacionais que adotaram uma interface gráfica utilizaram ou utilizam a metáfora do escritório. Alguns mais puristas em relação a própria metáfora, outros mais práticos.

O BeOS, por exemplo, mostrava um ícone de dispositivos externos conectados no desktop, enquanto que dispositivos internos eram acessados através do ícone do computador, para ser mais fiel a metáfora.

Uma das implementações mais fiéis à metáfora em si veio em 2010 com o BumpTop. A ideia da interface do BumpTop era de simular de forma mais real uma mesa de trabalho de escritório. Nele, os documentos são pequenos objetos 3D que podem ser empilhados, manipulados usando gestos e, inclusive, jogados de um lado para o outro utilizando leis físicas para uma experiência mais realista.

Infelizmente, o produto BumpTop foi descontinuado logo após a empresa ter sido comprada pelo Google.

Impactos

A Metáfora do Desktop desenvolvida pela equipe de Alan Kay é até hoje usada em todos os grandes sistemas operacionais de desktop. Ela foi um importante passo para que computadores ganhassem a popularidade que hoje possuem. Tornou possível o uso de computadores por pessoas não técnicas e abriu diferentes possibilidades na criação de programas de computadores, já que não estávamos mais limitados a uma interface de linha de comando.

Ela é hoje tão popular que, para muitos, superou sua “inspiração”. Quando falamos de pastas ou arquivos, logo nos vem a cabeça não mais pastas e vários papéis, mas sim arquivos e pastas em um computador. O próprio nome desktop é, hoje, mais relacionado a sua área de trabalho no computador do que a sua mesa de trabalho em um escritório.

O grande encontro do HTML com o HTTP

2014-06-19T00:00:00-07:00

Li um post muito bom do @jcemer que aborda os problemas de inconsistência entre o HTML e o HTTP. O artigo menciona, inclusive, um rascunho do editor que propunha melhorias ao que se diz respeito às capacidades dos formulários web de realizar tarefas consideradas bem comuns hoje em dia, mas que dependem de JavaScript e de outras técnicas comuns que viabilizem seus usos. Algumas dessas técnicas foram desenvolvidas com o intuito de suprir algumas questões divergentes entre o HTML e o HTTP, sobretudo quando se deseja utilizar REST — como por exemplo o uso dos métodos PUT e DELETE diretamente no atributo method do <form>.

Para entender plenamente do que se tratam esses problemas, recomendo a leitura do post do Jean — o qual inspirou o título deste.

A motivação

Uns dias depois do post do Jean, me deparei com o seguinte tweet do @W3C:

First Public Working Drafts: W3C HTML Form HTTP Extensions, W3C HTML JSON Form Submission http://t.co/CDF0LPl0Ve
— W3C (@w3c) May 29, 2014

O rascunho do editor evoluiu para um rascunho público do W3C, ou seja, parece que a coisa vai rolar mesmo — então decidi dar uma estudada na proposta e falar um pouco sobre o que achei mais legal. Será esse o encontro definitivo entre o HTML e seu protocolo de transferência?

HTML ♥ Forms

As propostas desse rascunho não se referem somente a entrar em conformidade com os verbos REST. Há recursos para padronizar autenticação HTTP e até mesmo para enviar informações diretamente no header de uma submissão de formulário.

Métodos HTTP

Será possível especificar quase todos os métodos HTTP através do atributo method de um formulário. Atualmente apenas são suportados os métodos GET e POST.

O HTTP tem 9 métodos, e os únicos que não poderão ser utilizados são CONNECT, TRACE e TRACK. Claro que, os que saltam aos olhos são os já utilizados no padrão REST — os métodos PUT e DELETE. Quanto aos restantes, consigo imaginar uma utilidade para HEAD e PATCH, mas não para OPTION — e também não há exemplos de utilização desses métodos no documento do W3C (por enquanto).

Como mostrado no post do @jcemer, os frameworks geralmente utilizam campos <input type="hidden"> para poder especificar métodos que não são GET nem POST e daí realizar as gambiarras necessárias no lado do servidor. Imagino que agora as coisas vão ficar um pouco mais simples.

method=“PUT”

O método PUT, como já sabemos, serve para atualizar um objeto/recurso no servidor.

<form action="http://ego.globo.com/noticias/1440" method="PUT">
    <input type="text" name="titulo" value="Daniel Filho aparou a barba." />
    <textarea name="conteudo">
        Daniel Filho finalmente criou vergonha na cara e (...)
    </textarea>
    <button type="submit">Atualizar</button>
</form>

No trecho acima, temos um formulário que atualiza uma notícia (de alto grau de importância) com identificador “1440” do portal ego (super relevante para nossas vidas #sqn).

Obs.: Não mostrem isso ao Daniel. Ele nem vai ler esse post mesmo. =P

method=“DELETE”

Com o método DELETE podemos deletar um objeto/recurso (dãã).

<form action="http://ego.globo.com/noticias" method="DELETE">
    <button type="submit">Excluir</button>
</form>

No trecho acima, temos um formulário que provê um grande serviço à humanidade, mandando todas as notícias do portal ego pro raio que o parta com o simples uso do método DELETE (acho que esse método nunca foi tão bem utilizado, hein). Claro que o serviço em questão deve estar em conformidade com o padrão REST para que isso aconteça.

Atributo payload

O atributo payload é usado para representar a associação entre um determinado dado (ou campo) de um formulário a um tipo de esquema de dados (http/https/data/mailto) na submissão do formulário. Um payload pode ser basicamente de três tipos: action, header ou body (valores _action, _header e _body respectivamente).

payload=“action“

Informação ou dado que descreve uma ação a ser executada no lado do servidor. Comumente referente ao atributo action do formulário.

<form action="mailto:">
    <input name="to" type="email" payload="_action" />
    <textarea name="content">
        Parabéns Daniel Filho! Você foi contemplado com um barbeador (...)
    </textarea>
    <button type="submit">Enviar email</button>
</form>

Fiz esse exemplo acima com base no que existe no rascunho do W3C. Pelo que entendi, o input[name=to] é associado à action que descreve um endereço de email, no entanto, não ficou claro como isso acontece exatamente. Por exemplo, se adicionarmos mais um <input> com payload="_action", o que deverá acontecer? Seguindo a lógica do action, informações adicionais seriam impostas na forma de querystring.

<form action="http://ego.globo.com/noticias" method="PUT">
    <input name="id" type="hidden" payload="_action" value="1440" />
    <!-- ... -->
</form>

Isso faria sentido. Deixando assim a URL do recurso mais limpa, e especificando seus parâmetros em outros lugares. A action resultante acima seria “http://ego.globo.com/noticias?id=1440”.

payload=“header“

Informação que pode ser incluída no header da submissão. Com isso pode-se especificar valores para um determinado header. O exemplo a seguir envia o header If-Unmodified-Since na submissão do formulário.

<form action="http://ego.globo.com/noticias/1440" method="DELETE">
    <input type="hidden"
           name="If-Unmodified-Since"
           value="Tue, 1 Jan 2013 12:00:00 GMT"
           payload="_header"/>
    <button type="submit">Excluir</button>
</form>

Só vai excluir o objeto se o mesmo não foi modificado desde a data especificada.

payload=“body“

Dado que pertence ao conteúdo (body) da submissão. É o valor padrão para a maioria dos casos.

Autenticação HTTP

Outra ação bem comum realizada via formulários é o login em algum serviço. Logins geralmente necessitam de pelo menos duas informações, o identificador do usuário que está tentando acessar o sistema e sua senha — claro que estamos falando de autenticações simples aqui (antes que venham falar sobre OAuth). Da mesma maneira também há uma proposta para padronizar a ação de logout.

Para determinar que um formulário realize uma submissão de um login, basta definir os elementos <input> de usuário e senha cada qual com seu atributo name como _username_ e _password_, respectivamente.

<form action="http://dandan.com/login" method="POST">
    <label for="usuario">Usuário</label>
    <input id="usuario" name="_username_" type="text" />
    <label for="senha">Senha</label>
    <input id="senha" name="_password_" type="password" />
    <button type="submit">Entrar</button>
</form>

_username_: Deve ser utilizado apenas em elementos <input> do tipo text ou email.
_password_: Deve ser utilizado apenas em elementos <input> do tipo password.

Tá, mas qual a real vantagem disso? Bem, se essa convenção for utilizada, então o agente de usuário (navegador) automaticamente deverá incluir um header adequado de autorização na requisição, no caso, esse header seria o Authorization.

Logout

A ação de logout é mais simples ainda. Precisa-se apenas de um <input> do tipo hidden com seu atributo name="_logout_".

<form action="http://dandan.com/logout" method="POST">
    <input name="_logout_" type="hidden" />
    <button type="submit">Sair</button>
</form>

Isso deve fazer com que o agente de usuário (que suporte autenticação HTTP e que reutilize credenciais de login em suas requisições) limpe quaisquer informações sobre credenciais de login previamente armazenadas.

Curiosidades

Na minha pesquisa, encontrei algumas informações interessantes.

PUT e DELETE no Firefox

A Mozilla chegou a implementar os métodos PUT e DELETE em formulários no Firefox 4 Beta (2011), mas depois foram removidos. Fonte.

PUT e DELETE no HTML5

Os métodos PUT e DELETE chegaram a fazer parte de alguns rascunhos iniciais do HTML5, mas foram removidos nas suas versões subsequentes. Vai ver foi por isso que o Firefox acabou implementando-os e depois removendo-os. Fonte 1.

Aqui temos uma resposta do Ian Hickson, que fechou a issue como Won’t fix:

PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.

— Ian Hickson (Fonte 2)

E vocês, o que acham?

Miniaturas simplificadas com CSS3

2014-05-27T00:00:00-07:00

Perambulando pelos padrões da W3C, encontrei uma coisa bem interessante na especificação de imagens CSS3 — a mesma que define os gradientes. Trata-se do modo de definição de tamanhos para imagens com as propriedades CSS object-fit e object-position, o que achei bastante útil principalmente para quando precisamos construir miniaturas (thumbnails) para visualizar imagens. Abaixo temos uma mini galeria com algumas imagens.

OBS.: Para visualizar os resultados experimentados neste post, é preciso utilizar um navegador baseado na engine do Blink (Google Chrome ou Opera) — caso contrário, não fará o menos sentido ler este material sem ver os resultados.

As miniaturas acima foram compostas apenas com o elemento <img>, ou seja, não foi preciso fazer uso de um elemento pai para servir de empacotador para a imagem — coisa que é muito comum na construção de miniaturas, costuma-se utilizar uma <div> com overflow: hidden e fazer o redimensionamento da imagem para acompanhar o tamanho da <div>.

<!-- Isso -->
<img class="galeria-img" src="einstein.jpg" alt="Einstein" />

<!-- Não isso -->
<div class="galeria-thumb">
    <img  class="galeria-img" src="einstein.jpg" alt="Einstein" />
</div>

Note que as quatro primeiras imagens são a mesma imagem, assim como as quatro últimas. A imagem do Einstein tem uma orientação de retrato (altura maior que largura), enquanto que a imagem do Chico Science tem uma orientação de paisagem (largura maior que altura).

object-fit

Cada uma das quatro ocorrências dessas imagens tem um comportamento diferente. Esse comportamento é definido através da propriedade object-fit, e com o uso dessa propriedade, fica visível que há uma separação entre o elemento invólucro (pai) e o conteúdo (bitmap) da imagem — o que já dá para perceber se utilizarmos a propriedade padding em uma imagem.

Então, o elemento <img> não é apenas um elemento, afinal de contas; mas pelo menos dois — assim como a maioria dos elementos HTML, afinal, a Shadow DOM está aí.

A propriedade object-fit define como o conteúdo da imagem é apresentado em relação ao seu elemento invólucro (elemento pai), e pode ter seu valor igual a fill, none, cover, contain ou scale-down. Para notar as diferenças do uso dessa propriedade, é necessário que a imagem em questão tenha altura e largura definidas. No nosso exemplo acima temos ambas as dimensões com 140 pixels:

.galeria-img {
    width: 140px;
    height: 140px;
}

Agora, vamos ao que interessa.

fill

Este é o valor padrão para object-fit. Para uma imagem com com altura e largura definidas, sua forma será achatada se a proporção resultante for diferente da original (comportamento padrão das imagens até então).

Imagem original

140x140px com fill

.galeria-img {
    width: 140px;
    height: 140px;
    object-fit: fill;
}

none

Com none, não é realizado nenhum processamento na imagem, mas ela será “cropada” (crop) pelas dimensões definidas, ou seja, será renderizada com seu bitmap inalterado, porém cortado. Com um exemplo fica mais fácil de entender:

Imagem original

140x140px com none

.galeria-img {
    width: 140px;
    height: 140px;
    object-fit: none;
}

Agora, vejamos o que acontece quando uma das dimensões definidas excede sua correspondente original:

Imagem original

220x140px com none

.galeria-img {
    width: 220px;
    height: 140px;
    object-fit: none;
}

Como dito, nenhum processamento foi feito na imagem, e ela mantém seu tamanho original. Pode-se perceber também que, nesses dois exemplos, a imagem resultante foi posicionada de forma centralizada. Veremos isso mais adiante com a propriedade object-position.

cover

Igualmente a none, mantém a proporção original da imagem, porém faz um redimensionamento na imagem para que esta possa preencher toda a área definida pelas dimensões especificadas. A seguir temos o mesmo exemplo do caso anterior, a única coisa que muda é o valor de object-fit para cover.

Imagem original

220x140px com cover

.galeria-img {
    width: 220px;
    height: 140px;
    object-fit: cover;
}

contain

Mantém a proporção original como em cover, mas faz um redimensionamento na imagem de modo que esta não seja cortada e seja mostrada completamente dentro da área definida pelas dimensões especificadas.

Imagem original

140x140px com contain

.galeria-img {
    width: 140px;
    height: 140px;
    object-fit: contain;
}

scale-down

Esse é um valor que pode causar um pouco de confusão. Ele fará com que a imagem se comporte de dois jeitos diferentes, dependendo do seu tamanho. scale-down irá sempre se comportar igual a none ou contain. O comportamento resultante sempre será o que representar um menor tamanho de imagem desenhada — e isso dependerá das dimensões originais da imagem e das dimensões definidas para o elemento <img>. De novo, com um exemplo fica mais fácil:

Imagem original

120x250px scale-down

200x250px com scale-down

.einstein-fit-1 {
    width: 120px;
    height: 250px;
    object-fit: scale-down;
}

.einstein-fit-2 {
    width: 200px;
    height: 250px;
    object-fit: scale-down;
}

Podemos perceber que nas duas imagens temos a mesma altura, e apenas mudamos a largura de um para o outro. No primeiro caso, scale-down se comporta como contain, pois none resultaria numa imagem maior. Já no segundo caso, temos o oposto, scale-down se comporta como none, pois contain resultaria numa imagem maior. Simples, não é?

object-position

O propósito de object-position é bem simples: posicionar o conteúdo da imagem dentro do emento <img>. O seu valor é definido exatamente da mesma maneira que a propriedade background-position. No exemplo a seguir temos imagens definidas com object-fit: cover e modificamos seu alinhamento vertical.

140x140px com cover

140x140px com cover no topo

140x140px com cover na base

.einstein-fit-1 {
    object-fit: cover;
    object-position: 50% 50%; /* valor padrão */
}

.einstein-fit-2 {
    object-fit: cover;
    object-position: 50% 0%; /* alinhada ao topo */
}

.einstein-fit-3 {
    object-fit: cover;
    object-position: 50% 100%; /* alinhada à base */
}

Agora, para ilustrar o alinhamento horizontal, no exemplo a seguir temos imagens definidas com object-fit: contain.

140x140px com contain

140x140px com contain no topo

140x140px com contain na base

.einstein-fit-1 {
    object-fit: contain;
    object-position: 50% 50%; /* valor padrão */
}

.einstein-fit-2 {
    object-fit: contain;
    object-position: 0% 50%; /* alinhada à esquerda */
}

.einstein-fit-3 {
    object-fit: contain;
    object-position: 100% 50%; /* alinhada à direita */
}

Claro que também é possível utilizar outras unidades como px, em, etc. e valores negativos também.

Ah, e mais uma coisinha…

As propriedades object-fit e object-position podem ser utilizadas também no elemento <video>, nos possibilitando realizar exatamente as mesmas configurações de estilos tanto para imagens quanto para vídeos.

Suporte

`object-fit`	31	--	--	--	19
`object-position`	31	--	--	--	19

Informações segundo o caniuse. Apenas o Google Chrome e o Opera dão suporte atualmente (logicamente, agora que o Opera também usa o Blink).

2 anos, um olá e um adeus

2014-04-01T00:00:00-07:00

Hoje, 1º de abril, estamos completando 2 anos de existência (não é mentira), e como no ano passado, estou publicando mais um post de retrospectiva sobre o Loop Infinito, além de algumas novidades.

2 anos

Há exatos 2 anos, Caio e eu começamos esse projeto maravilhoso para nós, que se trata deste humilde blog sobre front-end, produtividade e lifestyle.

De lá pra cá muita coisa aconteceu. Muita coisa mudou em nossas vidas. Decisões foram feitas, obstáculos foram superados, soluções foram descobertas, amizades foram firmadas, algumas decepções foram amargas, algumas conquistas não importaram, e no fim, muito se aprendeu — e esse sim é o objetivo principal para nós. Aprender. Tanto nós quanto vocês. Vocês são todos nossos parceiros nessa busca — a busca pelo conhecimento e pelo constante aprimoramento.

Este ano não vou mostrar aquele monte de gráficos como da vez passada — apesar de gostar bastante disso =P. Mas selecionei alguns números importantes e plotei-os em comparação com o ano anterior. Para saber os números, passe o mouse em cima dos gráficos.

Quantidade de posts

Esse é o número mais óbvio, pois tá na cara que nossa frequência de postagens deixou muito a desejar nesse ano — e nós reconhecemos isso. Eu poderia citar N razões plausíveis para isso agora, mas tenho certeza de que no fim tudo não passará de desculpas para nossos leitores, e eu não os culpo por pensar isso.

Ranking de localidades

As cidades que mais nos visitam (não mudou muita coisa em relação ao ano anterior):

São Paulo (22.16%)
Rio de Janeiro (9.11%)
Belo Horizonte (5.76%)
Porto Alegre (4.67%)
Curitiba (3.51%)

Ranking de navegadores

Essa ainda é a minha parte preferida. Abaixo temos uma comparação com o ano anterior.

O Chrome ganhou ainda mais espaço (+1.2%), mas o Safari foi o que mais cresceu, obtendo um ganho (+3.1%) maior que o Chrome. O restante dos navegadores perdeu espaço.

Conferências

2013 foi de longe o ano em que mais participamos de conferências de web, especialmente de front-end. Palestramos em alguns eventos regionais e participamos das grandes conferências como a JSConf BR e BrazilJS Conf, ambas de alto nível e imperdíveis (falando nisso, já garantiu sua entrada para a BrazilJS Conf deste ano?).

É sempre muito bom reencontrar os amigos que moram espalhados pelo país, além de trocar ideias com os participantes e palestrantes dos eventos — principalmente quando tem aquele chopp depois.

Um olá

Bem, como mostrado, nós faltamos bastante com nosso compromisso de manter o blog com novidades na maior parte do tempo, mas acreditamos que 2014 tem tudo para ser melhor que 2013. Vamos nos focar mais nisso e manteremos o Setup trazendo sempre as pessoas mais f***s que conhecemos da web brasileira. Algumas pessoas reclamam que a periodicidade do Setup é muito alta (1 setup por mês) — e realmente é, mas tem uma boa razão para isso e acredito que vocês sabem qual é: qualidade e compromisso. Acreditem, não é fácil ter que escolher apenas uma pessoa por mês em meio a tanta gente boa. Também vamos voltar a atualizar o wiredIn() (coisa que queremos há muito tempo), então podem esperar por playlists ainda melhores e um redesign do projeto.

Um adeus?

Como alguns já devem estar sabendo, Caio está indo morar em Amsterdã, e isso pode influenciar bastante em como as coisas vão se desenrolar daqui pra frente. Chegamos até a conversar sobre encerrar as atividades no Loop Infinito, e cada um continuar a fazer suas postagens em seus respectivos blogs. Porém, a ideia me pareceu um absurdo, e confesso que não me dei bem com essa possibilidade. Ainda não consigo me imaginar fazendo isso, pelo menos não por um bom tempo pela frente.

O que foi decidido enfim foi o seguinte: vamos continuar na ativa por aqui, e depois de um certo tempo tentar perceber se as coisas ainda estão fluindo legal. Então, o “adeus” na verdade é do Caio para sua morada aqui no Brasil, e não para o Loop.

Livro Coletânea Front-end

Nos últimos meses estávamos trabalhando em conjunto com mais 9 autores na elaboração desse, que se tornou no nosso primeiro material publicado em um livro. O convite veio do Sérgio Lopes (@sergio_caelum), que teve essa maravilhosa iniciativa. Para nós é uma grande honra poder compor algo juntamente com Bernard de Luna, Deivid Marques, Diego Eis, Eduardo Shiota, Giovanni Keppelen, Luiz Corte, Jaydson Gomes, Reinaldo Ferraz, e o próprio Sérgio, totalizando 11 autores, cada um com um capítulo independente.

O livro Coletânea Front-end: Uma antologia da comunidade front-end brasileira está sendo distribuído pela Casa do Código e está sendo publicado hoje (também não é mentira de 1º de abril). Por enquanto só está disponível na versão eletrônica, mas a versão impressa também estará disponível em breve. Achei a capa animal!

2014 promete, galera. Contamos com vocês para continuar movimentando a nossa comunidade. Valeu!

Segredos do Chrome Developer Tools

2014-03-18T00:00:00-07:00

Inspecionar elemento, breakpoints em JavaScript e console API já virou muito mainstream. Vamos conhecer neste post algumas features mais hipsters — porém úteis — do Chrome Developer Tools que vão melhorar seu dia-a-dia.

Compartilhar e analisar uma Timeline gravada por outro

Você está com aquele bug Cássia Eller na sua aplicação, deadline aproximando e você tem certeza que se fosse possível enviar os dados da sua timeline para aquele seu amigo que manja de todos os paranauês do front-end, ele iria te ajudar.

Seus problemas se acabaram-se. Agora você pode compartilhar sua timeline e analisar uma gravação alheia. Na aba Timeline clique com o botão secundário do mouse em qualquer lugar e aparecerá uma opção para salvar e uma outra para carregar dados de uma Timeline gravada.

Emulando dispositivos

Permite emular o tamanho da tela, pixel ratio e user agent string dos dispositivos móveis mais populares. Para acessar essa feature, chame o Console drawer como indicado na figura abaixo.

Uma vez no drawer, vá na aba Emulation e escolha o aparelho que deseja emular. Caso o aparelho não esteja na lista, é possível inserir todos os dados de forma manual.

Emulando acelerômetro

Além de emular dispositivos móveis, podemos emular alguns de seus sensores. Para emular o acelerômetro, por exemplo, vá ao drawer (o mesmo do item anterior), depois na aba Emulation e clique no checkbox Accelerometer. Você pode mexer a representação 3D do dispositivo para emular uma determinada posição ou pôr valores diretamente em cada eixo.

Contador de FPS

Útil para visualizar, em tempo real, o frame rate de sua aplicação. Para ativá-lo, vá no drawer, depois na aba Rendering e clique no checkbox Show FPS meter.

Quando ativo, irá aparecer uma caixa preta no topo à direita com detalhes sobre a quantidade de frames que estão sendo renderizados por segundo.

Debugar requisições Ajax de forma mais fácil

Na aba Sources, ao lado direito, é possível adicionar breakpoints dinâmicos para que o código pare a execução toda vez que uma chamada XHR possua uma dada string em sua URL.

Procure por uma string entre todos os arquivos

Um dos atalhos que mais uso. Aperte Cmd + Opt + F (Ctrl + Shift + F no Windows e Linux) para procurar qualquer palavra ou expressão regular entre todos os arquivos carregados (inclusive os carregados em tempo de execução).

Replay de chamadas Ajax

Já pensou ter que refazer sempre aquele fluxo enorme na sua aplicação só para disparar novamente aquela requisição Ajax (XHR)? Com esse atalho você pode dar um replay em qualquer chamada Ajax.

Na aba Network, clique com o botão secundário em cima de qualquer requisição XHR e escolha a opção Replay XHR.

Copiando requisições como comando cURL

Praticamente uma derivação do replay de chamadas Ajax. Com a diferença que aqui é gerado um comando cURL da requisição feita, com todos os parâmetros e cabeçalhos. Cole no seu terminal e aperte enter para disparar uma requisição idêntica à que foi disparada pelo seu navegador.

Troque rapidamente entre abas

Para navegar de forma rápida entre as abas do Dev Tools, utilize Cmd + [ e Cmd + ] (ou Ctrl + [ e Ctrl + ] no Windows e Linux).

Preservar o log do console durante navegação

Sabe quando você quer debugar algo que acontece um pouco antes de um redirect mas o redirect sempre apaga o log do console? Seus problemas acabaram. Clique com o botão direito no console e escolha a opção Preserve log upon navigation.

Benchmark usando console.time

Caso queira medir quanto tempo uma determinada operação leva para ser executada, basta usar console.time() e, quando a operação acabar usar o método console.timeEnd() passando a mesma string, como no exemplo abaixo.

Limpando o histórico do console

Bastante útil quando se começa a usar mais a aba console. Cmd + K no OS X e Ctrl + L no Windows e Linux para limpar o console. Também funciona com o método console.clear().

Mais um segredo

A capa do post também possui um pequeno segredo. Existe um rosto escondido entre os grãos de café. Consegue achar, olhos de águia?

Vibration API

2014-02-11T00:00:00-08:00

Embora ainda não seja possível provocar terremotos de escala geográfica, já podemos fazer dispositivos vibrar com HTML5. Entenda por dispositivo qualquer meio de acesso que possua um hardware específico que possibilite isso — como os dispositivos móveis, pois não faria o mínimo sentido seu computador vibrar (ou não?).

Muitas dessas novas APIs de acesso a dispositivos são focadas em utilidades mobile (assim como a Battery API), e eu diria que a Mozilla é a entidade que mais investe nessas especificações, pelo simples fato de que ela mantém o Firefox OS, cuja proposta é funcionar totalmente em cima dos padrões abertos da web.

Curiosidade

Originalmente, o nome dessa API seria Vibrator (vibrador), mas, por questões óbvias, preferiram mudar para Vibration. #tr00l

Uma API enorme

Essa API é tão extensa que dá até medo, eis a listagem de todas as suas propriedades e métodos:

navigator.vibrate()

Pronto. É isso. Já podemos ir pra praia? Sério, só tem esse método. Legal né? (aposto que tem muita gente comemorando agora.) De acordo com a spec, esse método recebe apenas um parâmetro que representa uma duração de tempo que o dispositivo deve permanecer vibrando.

navigator.vibrate(1000); // vibra por 1000ms (1s)

Esse parâmetro também pode ser uma lista representando um padrão de toques, onde cada item da lista alterna entre tempo de duração de uma vibração e tempo de duração de uma intervalo. Com um exemplo fica mais fácil de entender:

navigator.vibrate([500, 1000, 800, 500, 1000]);

No trecho acima o dispositivo começará vibrando por 500ms, depois pausa por 1000ms, vibra novamente por 800ms, pausa por 500ms e termina vibrando por mais 1000ms.

Caso uma chamada de vibração já tenha sido disparada, também é possível cancelá-la passando um zero ou um array vazio como parâmetro.

navigator.vibrate(0); // cancela qualquer vibração em execução
navigator.vibrate([]); // mesma coisa que o anterior

Quer testar o suporte?

if('vibrate' in navigator){
    // tann namm!
}

Utilidades

Tá, mas o que faço com essa API? Bem, considerando que o mecanismo de vibração causa um simples feedback tátil, existem algumas utilidades que podem ser de interesse para uma aplicação móvel. As mais comuns são, por exemplo, alertar o usuário ao disparar uma notificação, mensagem ou ligação e vibrar em momentos específicos ao decorrer de um jogo (uma bomba explodindo, talvez) — causando uma maior imersão para o jogador.

Outras utilidades não tão óbvias poderiam ser, por exemplo, guiar um usuário portador de deficiência visual em um ambiente, onde cada tipo de vibração poderia corresponder a direcionamentos como ‘esquerda’, ‘direita’, ‘trás’, ‘frente’, etc. Um experimento que achei bastante criativo foi um comunicador em código morse entre dois dispositivos utilizando a API de vibração e Web Sockets. A partir daí vai de acordo com a criatividade de cada um.

Suporte

`navigator.vibrate()`	32 *	--	26 *	?	--
* Ainda não há nenhuma informação no caniuse à respeito da Vibration API, então fiz essa verificação nos navegadores que tenho atualmente.

Google Traceur, ou “Como usar ECMAScript 6 hoje”

2014-01-28T00:00:00-08:00

Google Traceur é um compilador de ECMAScript 6 para o JavaScript de hoje. O seu objetivo é tornar possível o uso de features da linguagem que ainda não foram implementadas na maioria dos browsers e, até mesmo, outras que ainda estão sendo discutidas.

Além de tornar possível o teste de features da especificação do ECMAScript 6, um dos intuitos do projeto é fazer com que a comunidade participe de forma mais ativa no futuro do JavaScript, fazendo com que os desenvolvedores usem e testem hoje o que poderá vir a ser o futuro da linguagem e, assim, opinar e influenciar na nova especificação antes que esta se dê por fechada.

Algumas das principais features suportadas hoje em dia são:

Classes

Implementa a especificação ainda em rascunho do ECMAScript 6 sobre classes. Apenas suporta a implementação mínima, pois muito ainda está sendo discutido sobre como de fato irá ser a especificação final.

class Monstro extends Personagem {
  constructor(x, y, nome) {
    super(x, y)
    this.nome = nome
    this.life_ = 100
  }

  ataca(personagem) {
    super.attack(personagem)
  }

  get isVivo() { return this.life_ > 0 }
  get life() { return this.life_ }
  set life(valor) {
    if (valor < 0) {
      throw new Error('Life não pode ser negativo.')
    }

    this.life_ = valor
  }
}

Reparem no código acima que temos alguns elementos comuns em linguagens orientadas a objeto como: uma função construtora, herança e uma palavra reservada para chamarmos a classe pai. Além disso, as definições dos métodos não necessitam ser declarados com function como uma função normal e podemos também definir métodos get e set para atributos que irão ser chamados quando passarmos um novo valor para um atributo ou pedirmos seu valor atual.

Destructuring Assignment

Um atalho para inicializar ou definir várias variáveis de uma só vez.

var ponto = {x: 1, y: 2}
var retangulo = {topLeft: {x: 3, y: 4}, bottomRight: {x: 5, y: 6}}

var {x, y} = ponto // descompacta o ponto
console.log(x, y) // imprime 1 2

// descompacta o retângulo
var {topLeft: {x: x1, y: y1}, bottomRight: {x: x2, y: y2}} = retangulo
console.log(x1, y1, x2, y2) // imprime 3 4 5 6

Block scoped bindings

Aqui temos escopo a nível de bloco, e não mais apenas a nível de função e global. Isto assegura que as variáveis não vazem de um escopo sem a necessidade de usarmos funções de execução imediata.

{
  const salario = 750,
  nome = 'n3rd',
  sobrenome = 'l33t'
}
// não é acessível fora do escopo do objeto onde foi definido
console.log(salario)

As palavras reservadas const e let são, até o momento, as únicas que possuem esse comportamento de escopo em bloco.

Parâmetros default

Tão óbvio que os novatos em JS nem conseguem acreditar que não existe um meio de definirmos valores default para parâmetros. Finalmente agora é possível.

function foo(a = 1, b = 2, c = 3) {
  // ...
}

foo(3) // a = 3, b = 2, c = 3

Rest parameters

Permite que funções tenham um número variável de parâmetros sem a necessidade do uso do objeto arguments.

var ouro = prata = restante = 'desconhecido'

function concedeMedalha(primeiro, segundo, ...outros) {
  ouro = primeiro
  prata = segundo
  restante = outros
}

concedeMedalha('Michael Phelps', 'Liu Xiang', 'Yao Ming', 'Allyson Felix')

console.log(ouro) // imprime “Michael Phelps”
console.log(prata) // imprime “Liu Xiang”
console.log(restante.join(', ')) // imprime o “Yao Ming, Allyson Felix”

Spread operator

O spread operator é como o inverso do rest parameters. Ele expande um array em em argumentos formais. Continuando com o exemplo acima, imaginem que agora, no lugar de passarmos um a um os competidores para a função concedeMedalha, pudessemos passar um array e cada posição desse array ser interpretado como um argumento.

var ouro = prata = restante = 'desconhecido'

function concedeMedalha(primeiro, segundo, ...outros) {
  ouro = primeiro
  prata = segundo
  restante = outros
}

var competidores = [
  'Michael Phelps',
  'Liu Xiang',
  'Yao Ming',
  'Allyson Felix'
]

concedeMedalha(...competidores)

console.log(ouro) // imprime “Michael Phelps”
console.log(prata) // imprime “Liu Xiang”
console.log(restante.join(', ')) // imprime o “Yao Ming, Allyson Felix”

Atalho para inicializar objeto

Evita o repetitivo código {x: x, y: y, z: z} quando estamos definindo um objeto cujo a chave possui o valor da variável de mesmo nome.

var obj = {x, y}
// um atalho para o código acima
var obj = {x: x, y: y}

function f(x, y) { return {x: x, y: y} }
// o mesmo que o código acima
function f(x, y) { return {x, y} }

Reparem que na primeira linha do trecho de código acima, inicializamos a variável obj com o valor {x, y}, o que é sintaticamente errado no ECMAScript 3. O que este “atalho” faz é setar um objeto com chave x com o valor da variável x. Falando em JS, ele evita que você digite repetidamente este trecho: var obj = {x: x, y: y}, dando um atalho para tal, desta forma: var obj = {x, y}. Dificil de explicar, mas fácil de entender. Tenta acompanhar esse outro exemplo.

var nome = "Joao"
var sobrenome = "Silva"

var pessoa = {nome, sobrenome} // o mesmo que `var pessoa = {nome: nome, sobrenome: sobrenome}`

Property method assignment

Permite que métodos de objetos sejam definidos de uma maneira mais clara. Reparem que, abaixo, definimos os métodos bunizar e ligar sem usar a palavra-reservada function.

var carro = {
  nome: 'Lorem',
  marca: 'Ipsum',
  buzinar() {
    // ...
  },
  ligar() {
    // ...
  }
}

Isto é, até o momento, o que o Google Traceur suporta sobre Property method assignment. Porém a especificação abrange mais detalhes.

E mais…

Existem mais algumas features que o o Google Traceur suporta, como promises, iterators, generatos e outros. Optei por abranger as mais consolidadas na especificação e de mais fácil entendimento, caso contrário este post iria virar uma bíblia. A quem quiser descer na toca do coelho, aconselho a Wiki do projeto e, claro, a própria especificação do ECMAScript 6.

Integrando no Grunt

E como já dizia Steve Jobs: “There is a Grunt task for that!”. Integrar o processo de tradução/compilação/transpilação de ECMAScript 6 para o JS de hoje fica fácil com o Grunt. Vamos usar o pacote grunt-traceur para tal.

No terminal, entre na pasta do seu projeto e vamos instalar todos os pacotes necessários. Primeiro vamos instalar o Grunt e, logo em seguida, o grunt- traceur.

npm install -g grunt-cli
npm install grunt --save-dev
npm install grunt-traceur --save-dev

Algumas considerações sobre os comandos usados acima: a flag -g usada para instalar o Grunt é para que o grunt-cli seja instalado de forma global, que é um passo necessário para usar o grunt no terminal sem informamos o PATH do seu executável; a flag --save-dev para que as dependências sejam automaticamente inseridas no seu arquivo package.json.

Com Grunt e grunt-traceur instalados, agora podemos configurar nosso Gruntfile. Crie um arquivo chamado Gruntfile.js (ou Gruntfile.coffee) na raíz do seu projeto. Abaixo um exemplo de um Gruntfile.js completo. Caso você já possua um, extraia apenas as partes relacionadas ao grunt-traceur.

module.exports = function (grunt) {
  'use strict';

  grunt.loadNpmTasks('grunt-traceur')

  var gruntConfig = {}

  gruntConfig.traceur = {
    options: {
      blockBinding: true // habilita `let` e `const`
    },
    custom: {
      files: {
        'static/app.js': [
          'assets/character.js',
          'assets/monster.js',
          'assets/main.js'
        ]
      }
    }
  }

  grunt.initConfig(gruntConfig)
}

No objeto files passamos como chave o arquivo de output e como valor um array com todos os arquivos que serão compilados, em ordem. No exemplo acima, os arquivos assets/character.js, assets/monster.js e assets/main.js serão todos compilados e concatenados no arquivo static/app.js.

Agora basta rodar no seu terminal o comando grunt traceur toda vez que você modificar seus arquivos JavaScript.

Mas isso obviamente vai ficar muito chato depois da terceira vez que você tiver que mudar para o terminal e digitar manualmente grunt traceur. Para deixar esse processo de build mais automatizado: “There is a Grunt task for that”.

Vamos usar a task watch do Grunt para que toda vez que modificarmos os arquivos JS escritos em ECMAScript 6, eles sejam compilados para o JavaScript de hoje.

Para instalar o pacote grunt-watch digite no seu terminal o comando abaixo:

npm install grunt-watch --save-dev

E agora vamos configurar a task. Vamos adicionar um objeto watch ao nosso objeto de configuração do Grunt.

grunt.loadNpmTasks('grunt-watch')

gruntConfig.watch = {
  traceur: {
    files: ['./caminho/para/arquivos/ecmascript6/*.js'],
    tasks: ['traceur']
  }
}

Com isso, basta rodarmos no terminal o comando grunt watch:traceur e, toda vez que um arquivo for modificado, ele será traduzido/compilado/transpilado para o JavaScript compatível hoje na maioria dos browsers.

Integrando no Gulp

E se você, JS hipster, acha o Grunt uma ferramenta muito mainstream, não se preocupe: também existe um módulo para Gulp. Ele foi escrito pelo @sindresorhus e você pode ver mais detalhes do pacote na página do projeto no GitHub.

Instruções para instalar? Se você usar o Gulp com certeza não precisa de instruções para instalar. Você lê o código diretamente, não é isso?

CSS Transform'ers 2D Interativo

2014-01-08T00:00:00-08:00

Há pouco tempo li o excelente livro CSS Transforms: An Interactive Guide escrito pela Vicki Murley, uma evangelista web ex-Apple. Esta foi uma das melhores e mais fáceis leituras que já fiz relacionado a CSS. Além de tratar com muito domínio sobre o assunto, o que mais me chamou atenção foi o modo como é demonstrado cada nova função, tornando um assunto por vezes muito abstrato em algo prático e fácil de ser entendido.

Então, fortemente inspirado em seu livro, vou agora tentar explicar CSS Transforms de um modo similar ao modo que Vicki aborda em seu livro e, também, da mesma forma que sempre tentamos fazer por aqui: na prática.

Breve introdução

Com o lançamento do primeiro iPhone em 2007, seu rápido ganho em popularidade e sua falta de suporte ao Adobe Flash, ficou claro que era necessário uma tecnologia web nativa — sem plug-ins de terceiros — para animações mais avançadas e de alta performance. Então, no mesmo ano de 2007, um engenheiro da Apple enviou para a mailing list da W3C a proposta para CSS Transforms. Esta especificação foi primeiramente implementada no WebKit, pois era de interesse da Apple, mas foi ganhando popularidade aos poucos, por se mostrar uma tecnologia mais performática, livre e cross-browser.

Hoje o CSS Transforms já está implementado em todos os grandes navegadores e seu uso em produção é bem comum e, inclusive, aconselhado. Ele torna possível adicionarmos efeitos visuais à web que antes só podiam ser implementados através de plug-ins de terceiros. Também servem de base para animações mais complexas e podem ser aplicados em qualquer elemento HTML. E são eles que vamos estudar e experimentar na prática como funcionam.

Translate

A função translate é usada para movermos um elemento nos eixos X, Y, ou ambos. Caso seja passado apenas um parâmetro para a função, o elemento será movido em relação ao eixo X. Já com dois parâmetros, o primeiro será o valor usado para a movimentação no eixo X, e o segundo para o eixo Y.

img {
  transform: translate(13px, 10px); /* move elemento 13px em X e 10px em Y */
  transform: translate(13px); /* move elemento 13px no eixo X */
  transform: translateX(13px); /* move elemento 13px no eixo X */
  transform: translateY(10px); /* move elemento 10px no eixo Y */
}

Além de px, também podemos passar valores expressos em %. Neste caso, 100% será equivalente a dimensão do elemento no eixo em que vamos efetuar o translate. Em outras palavras: se vamos movimentar o elemento no eixo X, 100% será igual a sua largura; se a movimentação ocorrer no eixo Y, 100% equivalerá a altura do elemento. No experimento abaixo vocês podem ver a função translate em ação de uma forma mais interativa e menos abstrata, basta mover os handlers dos inputs do Translate X e Translate Y.

Reparem que valores negativos também são aceitos. Valores negativos em X movimentam o elemento para a esquerda. Valores negativos em Y movimentam o elemento para cima. Um transform: translateX(-10px); moverá o elemento 10 pixels para a esquerda. Enquanto um transform: translateY(-5px); moverá o elemento 5 pixels para cima.

Skew

A função skew irá “entortar” um elemento em relação a um dos eixos.

img {
  transform: skewX(30deg); /* “entorta” o elemento horizontalmente */
  transform: skewY(30deg); /* “entorta” o elemento verticalmente */
}

As funções usadas para efetuarmos o skew são skewX e skewY. Cada uma recebe apenas um parâmetro, estes expressos em graus (deg). No experimento abaixo fica bem mais fácil entender o que acontece quando aplicamos o skew. Assim como no experimento acima, basta mover os handlers da parte esquerda inferior para alterar os valores e ver o efeito desta mudança na direita.

Também existe uma função skew, que, na teoria, funcionaria como um atalho para as funções skewX e skewY. Mas o seu resultado final não é o mesmo que o das funções skewX e skewY usadas de forma separada com os mesmos parâmetros de skew. O próprio MDN desaconselha seu uso.

Rotate

A função rotate … rotaciona. Simples assim. Ela recebe um único parâmetro que pode ser expresso em graus (deg), radianos (rad) ou voltas (turn).

img {
  transform: rotate(30deg); /* rotaciona 30' no sentido horário */
  transform: rotate(-45deg); /* rotaciona 45' no sentido anti-horário */
  transform: rotate(2rad); /* rotaciona ~ 144,59' no sentido horário */
  transform: rotate(0.5turn); /* rotaciona meia-volta no sentido horário */
}

Valores positivos rotacionam o elemento no sentido horário, enquanto que valores negativos rotacionam o elemento no sentido anti-horário. O experimento abaixo mostra o rotate em ação.

Scale

Altera o tamanho do elemento em ambos os eixos ou apenas em um eixo específico. Esta função aceita um ou dois parâmetros. Caso seja passado apenas um, a alteração irá ocorrer tanto na altura como na largura. Caso sejam passados dois, o primeiro argumento irá alterar a largura e o segundo irá alterar a altura.

Os valores passados como parâmetros não possuem unidades. Eles funcionam como “multiplicadores” do tamanho do elemento. Um transform: scale(2) irá duplicar o tamanho do elemento. Um transform: scale(0.5) irá reduzi-lo pela metade.

img {
  transform: scale(2); /* dobra o tamanho do elemento em todas as direções */
  transform: scale(2, 3); /* dobra a largura e triplica a altura */
  transform: scaleX(0.5); /* reduz largura do elemento pela metade */
  transform: scaleY(2); /* deixa o elemento duas vezes mais alto */
}

Além da função scale, podemos usar as funções específicas de cada eixo: para o eixo X a scaleX e para o eixo Y a scaleY. Abaixo também podemos interagir com esta função e ver na prática como se comporta.

Observem no experimento acima que, ao passarmos valores negativos, nós invertemos a imagem. Se passarmos um valor de -1 para scaleX, é como se estivéssemos espelhando o elemento. -1 para scaleY e o elemento irá ficar de cabeça para baixo (invertido na vertical).

Múltiplas transformações

É possível usar várias funções transform ao mesmo tempo em um elemento. Para isso, é só declarar todas as funções — com seus devidos valores — separados por um espaço.

img {
  transform: translateX(2px);
  transform: skewX(45deg); /* sobrescreve a transformação acima */
  transform: rotate(0.5turn) scale(2); /* rotaciona em 180º e duplica o tamanho */
}

Cuidado para não declarar várias regras transform no mesmo elemento, pois dessa forma a última regra sobrescreve todas as outras declaradas

Suporte

transform	4 `-webkit-`	3.1 `-webkit-`	3.5	9.0	10.5 `-webkit-`

Com a exceção do Internet Explorer (alguém surpreso?), o CSS Transform já é suportado nos principais browsers há muito tempo. O IE só veio dar suporte na sua versão 9.0.

E para quem quiser se aprofundar mais no assunto, aconselho fortemente que comprem o livro CSS Transforms: An Interactive Guide da Vicki Murley. Nele, além de CSS Transforms 2D, também é abordado o assunto CSS Transforms 3D.

O código de todos os experimentos acima estão, como de costume, disponíveis no Github. Gostou? Dá uma estrela pro projeto =).

Loop Infinito

Hoisting e escopo em JavaScript

Escopo

Declaração e nomes no escopo

Hoisting

Variable hoisting

Function hoisting

ECMAScript 6

Protip

ECMAScript 6 Proxy

Show me the code

Aplicações

Validação

Log

Armadilhas

Get

Set

Has

Enumerate

Suporte

A metáfora do escritório

A Mãe de Todos os Demos

PARC

A metáfora

Impactos

O grande encontro do HTML com o HTTP

A motivação

HTML ♥ Forms

Métodos HTTP

method=“PUT”

method=“DELETE”

Atributo payload

payload=“action“

payload=“header“

payload=“body“

Autenticação HTTP

Login

Logout

Curiosidades

PUT e DELETE no Firefox

PUT e DELETE no HTML5

Miniaturas simplificadas com CSS3

object-fit

fill

none

cover

contain

scale-down

object-position

Ah, e mais uma coisinha…

Suporte

2 anos, um olá e um adeus

2 anos

Quantidade de posts

Ranking de localidades

Ranking de navegadores

Conferências

Um olá

Um adeus?

Livro Coletânea Front-end

Segredos do Chrome Developer Tools

Compartilhar e analisar uma Timeline gravada por outro

Emulando dispositivos

Emulando acelerômetro

Contador de FPS

Debugar requisições Ajax de forma mais fácil

Procure por uma string entre todos os arquivos

Replay de chamadas Ajax

Copiando requisições como comando cURL

Troque rapidamente entre abas

Preservar o log do console durante navegação

Benchmark usando console.time

Limpando o histórico do console

Mais um segredo

Vibration API

Curiosidade

Uma API enorme

navigator.vibrate()

Utilidades

Suporte