“Pra sempre” em se tratando de Web significa coisa de 1/2 a 1 década, e sim, usaremos Babel pra sempre.

Nos cursos da Produto Reativo (Modelo de educação técnica que venho realizando dentro da sede da Greenmile para a comunidade Cearense) a Babel é a pedra filosofal para trazer o futuro pra hoje, um aluno certa vez falou uma sacada genial quando eu falo das vantagens de usar ES7 já:

“Milfont, então sempre usaremos Babel, porque quando os Browsers estiverem compatíveis com ES7 já teremos ES8 ou mais…”

Perfeito, principalmente porque a ES7 (ou ES2016) já foi publicada e até agora o Chrome (com 97%) ainda está próximo da compatibilidade 100% com a ES6 (ou ES2015) exemplificando essa frase. O Edge com 95% na frente dos outros concorrentes me enche de esperança na humanidade e um futuro longe das distopias.

Mostre código, por favor

---

Visualiza o código React seguinte em ES6 clássico como recomendado:

https://gist.github.com/cmilfont/2c17803534c6f22bcac1ccad0cbc2fb9#file-es6-js

Independente de recursos fantásticos como Async/Await, são pequenos detalhes de recursos sintáticos que melhoram a manutenção de código.

Começamos com recurso de propriedades tanto de instância quanto de classe disponível no ES7. Analisando esse código anterior, o padrão ES6 é:

https://gist.github.com/cmilfont/f33962f158c10bb09d7d62a080566623

A nova versão inclui propriedades de classe e instância com a seguinte sintaxe:

https://gist.github.com/cmilfont/ed86c9b820b50fbeeb537c1795d68407

E para não precisar sobrescrever o constructor para fazer o Bind de functions da própria instância podemos usar o recurso de Fat Arrow Function na variável de propriedade que faz o autobind:

https://gist.github.com/cmilfont/cb8afa7285b2b38a7d05210fe132b721

Eu não sou favorável de usar outras linguagens para “transpilar” para Javascript, apesar de ser simpático com ClojureScript. Por questões de princípios, prefiro aprender e fazer com EcmaScript que tem todos os recursos dessas outras linguagens e me manter o mais próximo possível da Spec.

Mas um recurso específico eu gosto de usar nos meus projetos, o Decorator, que apesar de ter ficado ainda fora da ES7 eu tenho certeza que cedo ou tarde entrará na linguagem e a forma de consumir praticamente será a mesma que usamos hoje em dia.

Código para ligar o componente React com o Redux:

https://gist.github.com/cmilfont/5522f59f8684e6fd8dcd9cbbc1565133

Usando Decorator (já que a API permite) melhora a legibilidade:

https://gist.github.com/cmilfont/f3e97901bc0fff650317b4d44faa0775

Meu .babelrc para compilar esse código.

https://gist.github.com/cmilfont/523d03d6bf4f7cfc32d455f8190fd423

Código transformado para ES7 com Decorator:

https://gist.github.com/cmilfont/9d47f37efe39f583db8bfd216634a379

A Babel é ferramenta que permite uma transição gradual e “tranquila” para o futuro como nunca antes conseguimos, meu maior objetivo é criar mecanismos para nos manter atualizados dentro da realidade saudável, porque não temos como refazer todos os projetos sempre a cada mudança de mindset/tecnologia.

Fico na dependência do Babel pra sempre sem problema na consciência por essa ferramenta até agora conseguir me ajudar nesse objetivo.

Vídeo anterior O que podemos aprender com o Snapchat.

3 Regras de UI para a boa usabilidade.

Siga um guideline, mas aprenda a quebrar as convenções em prol da usabilidade seguindo essas regras:

1. Vá direto ao ponto;
2. Não atrapalhe;
3. Economize movimentos.

Link comentado no vídeo de um projeto de estudo sobre a Netflix.

Um conceito que confundo a cabeça dos alunos no curso de Front End é que devemos seguir as boas práticas sem nos prender a elas, ou seja, depois de demonstrar o Material Design e recomendar o uso, nós simplesmente quebramos os conceitos de Layout que ele sugere e trabalhamos algumas tendências de regras de UI para uma boa usabilidade [post e vídeo em breve sobre].

O excelente livro Designed for Use: Create Usable Interfaces for Applications and the Web tem uma definição que considero genial e define tudo que acredito:

Good design is design that works. This seems like an obvious point, and yet people often confuse good design with design that follows its host system’s UI guidelines, or design that is consistent with other, similar products, or design that follows some other convention. When in doubt, following conventions is a good idea. Conventions are there for a reason. Google invested a lot in its material design spec, for example, and you could do a lot worse than follow its lead. But it’s possible that you could also do a lot better. If you think that following conventions makes your product harder to use, more difficult to learn, or less efficient to use, you should challenge these conventions. Find the best solution for the users’ needs.

Em uma tradução livre e apressada:

Um bom design é o design que funciona. Isso parece ser um ponto óbvio e ainda assim as pessoas muitas vezes confundem um bom design com um design que segue as diretrizes definidas de UI já colocadas ou o design que é consistente com outros produtos similares ou design que segue a alguma outra convenção. Em caso de dúvida, seguir convenções é uma boa idéia. Convenções estão lá por um motivo. O Google investiu muito em sua especificação Material Design, por exemplo, e você poderia fazer muito pior do que apenas seguir seu conselho. Mas é possível que você também poderia fazer muito melhor. Se você acha que seguindo convenções torna o seu produto mais difícil de usar, mais difícil de aprender ou menos eficientes ao uso, você deve desafiar essas convenções. Encontrar a melhor solução para as necessidades dos usuários.

No vídeo que gravei fazendo uma análise sobre “O que podemos aprender com o Snapchat” eu comentei sobre o quão ousado o produto foi em quebrar essas convenções. Recomendo que assista.

Em uma das aulas nós construímos uma Interface para a idéia de um produto sobre Feedback.

A prototipação nasce sempre tradicional, pensando no template do Material Design (com React no caso desse curso).

Quando fomos construir um protótipo funcional, empilhamos os componentes e ajustamos para algo que fizesse sentido com a Story.

Então o desafio é começar a trabalhar alguns conceitos como Formless, não precisar fazer o usuário pensar, não solicitar ou notificar sobre algo que o usuário não precisa agir, entre outros. O layout fica bem desafiador, bem econômico e direto ao ponto.

Imagina um convite, não tem botão, não tem formulário, apenas um pedido de seu amigo para o avaliar e ao escrever já está informado.

Eu chamo de 3 regras do UI para uma boa usabilidade, é um crivo que analiso uma feature e vamos ajustando até que se adequa o melhor possível dentro das “leis”.

Em breve vou gravar um vídeo sobre a técnica que utilizamos, aguarde!