Jean Emer

Types in JavaScript: why you should care

Mon, 13 Nov 2017 00:00:00 +0000

In simple terms, a type helps group similar values on which common operations can be performed. Based on our Mathematical knowledge, it is easy to identify that it is possible to sum the values in the sequence 11, 3, 67, and 89. At the same time, we know that we can't multiply the values in the following sequence JS, is, and cool, but we can naturally merge them. Numbers and strings are the most popular types.

In a programming language, the types are what determine the amount of memory allocated to save a value. The type of a value also determine the operations and methods allowed to be performed on it.

JavaScript has six primitives types: string, number, undefined, null, boolean, and symbol. There is also a compound type or object. Interestingly, the primitive types are immutable and don't have properties. For example, because of the String object you can retrieve the length of a string. The code "a".length is evaluated as new String("a").length by the interpreter like magic. There are also the objects Number, Boolean, and Symbol which also add properties to its own primitives.

The types in JavaScript look simple and useless but knowing how they work is important. They help give a better understanding of the language and its behavior.

Dynamic type checking

Types are one of the main foundations of a programming language. Many execution errors in JavaScript are type errors. For example, when we try to multiply a number by a string we get a silent error in the form of Not a Number returned. Have you ever called a function and received the error undefined is not a function? This happens when we try to access a property that is not defined. Since Javascript cannot locate the property it returns its default fallback value: undefined.

Another common type-related mistake is when we try to change or access a property from a value that is null or undefined. Keep in mind that there aren't constructors like Undefined or Null to save us here. We end up with an error. Not to mention all the times that we mistake the value type of this and try forbidden things on it.

A good type system helps us avoid these common mistakes. By definition JavaScript is an interpreted and dynamic language and it requires that the type system works during the code execution. The language also tries to help by silently converting value types. It works in your favor when you multiply 2 by '3' and not so much when you are trying to sum a number with a string that contains a number. :sweat_smile:

Type changing or coercion is the reason many developers switch over to strictly using === for checking the equality of values, but there is a lot more to it than that as Fixing Coercion, Not The Symptoms explains.

In essence, types in JavaScript are a moving target, it is difficult to hit them. Besides it isn't possible to predict or assure the variable type since the language is weakly typed and that type may change.

Static type checking

Static type checking ensures that the program is correct, at least statically prior to execution. There are alternative ways to annotate the value types in JavaScript. It avoids you to bug the user trying to operate different types in a crazy way.

The code below calculates the price of a Product. From lines 4 to 6, we define the type of the Product properties with the Flow annotation. The rest of the code is plain JavaScript but notice there is a value incompatibility at the line 19. This is the kind of code that gifts you with a NaN value. Fortunately, the Flow analyzer warns you know about that potential error while writing the code.

/* @flow */

class Product {
  name: string
  cost: number
  tax: number

  constructor (name, cost, tax) {
    this.name = name
    this.cost = cost
    this.tax = tax
  }

  price() {
    return this.cost * (1 + this.tax)
  }
}

const item = new Product("Banana", 2, "%30")

The Flow annotation allows you to define all the different primitives, objects, constructors/classes (Date, Array, ...) and even literals. There are some advanced types like any which accepts all types; nullable or maybe, to indicate a type or null; and also unions and intersections of types and interfaces (more about that below).

IMHO, the most powerful annotations are the new types or aliases, that allow you to give a name to a group of types for exclusive properties; interfaces which define a non-exclusive group of important properties or methods that a context is concerned about; and generics. This last one, allows you to define the type of an array's values or the type of the result of a Promise for example.

According to Kris Jenkins, through type definition, it is possible to predict design problems. A function that returns many different types could mean a fault in planning. The creation of new types helps the programmer define the problem's entities. In any case, type annotation is a good resource to write safer and more understandable code.

A Type System is, first and foremost a communication mechanism - Sarah Mei

Besides Flow, there is also TypeScript language which is statically typed with a syntax close to JavaScript. But bear in mind that Flow or TypeScript code needs conversion to JavaScript before running on the client machine. Type annotation requires effort not without meaningful outcome. The paper To Type or Not to Type: Quantifying Detectable Bugs in JavaScript concludes that a type analyzer could catch around 15% of production bugs in a reviewed and test covered codebase. It is quite impressive.

IO Data

Programs in general and special interface code get a lot of external values to work with which means static analyzers require a contract declaring the types of the external data. The TypeScript code below indicates that the API response is a list of strings:

interface ItemsResponse {
  results: string[]
}

http.get<ItemsResponse>('/api/items')
  .subscribe(data => {
    this.results = data.results
  })

From this annotation, the rest of of the code is analyzed to ensure that all references match. The static analyzer, however, works if this contract is respected. If the production API returns something other than strings, the risk of a runtime execution error is high.

The any is the type of all JavaScript APIs that return data from abroad. And by definition, the any could be converted to a more specific type. Quoting the Flow documentation: using any is completely unsafe, and should be avoided whenever possible. But talking about external data it looks like anything could be done. It looks...

Elm

There is a language catching a lot of attention that ensures there are no runtime execution errors at all. Elm is a statically typed language for the web with a syntax and paradigm different than JavaScript.

Let's go back to our Product with price calculation. In the code below you'll see that the way to solve the problem isn't close to the Object Oriented JavaScript World™. Lines 1 to 5, 7, 11, and 14 are strictly responsible for type annotation. Lines 8 and 9 define the global price calculation and line 12 defines a sample product. Finally, the price calculation is performed on line 15.

type alias Product =
  { name : String
  , cost : Float
  , tax : Float
  }

price : Product -> Float
price {cost,tax} =
  cost * (tax + 1)

item : Product
item = { name = "Banana", cost = 2, tax = 0.3 }

itemPrice : Float
itemPrice = price item
-- 2.6 : Float

All of this is pretty impressive for the purpose of this post, the most important takeaway is the decoders. Elm requires you to define and test all the types of the IO data. A decoder can return Err with a message (like on the line 6 below) or an Ok with the decoded data (line 10).

import Json.Decode exposing (..)

resultsDecoder = field "results" (list string)

decodeString resultsDecoder "bla"
Err "Given an invalid JSON: Unexpected token b in JSON…"
    : Result.Result String (List String)

decodeString resultsDecoder "{ \"results\": [\"1\", \"2\"] }"
Ok ["1","2"] : Result.Result String (List String)

The code must thread the two possible cases in runtime execution: the Ok and the Err. This is one of the secrets for how maintain a language without runtime exceptions.

JavaScript counter-attacks

The JavaScript ecosystem already has libraries which check value types at runtime. The code below throws an exception if the API we already know returns something other than strings:

var t = require("tcomb")

const Results = t.interface({
  results: t.list(t.String)
}, "Results")

Results({
  results: ["1", "2"]
})

Results({
  results: [2]
})
// TypeError: [tcomb] Invalid value 2 supplied to Results/results: Array<String>/0: String

Libraries like tcomb and typify check types on the client machine. As a proof of concept, I drafted a simple example using the Elm Result (Ok and Err) concept with typify in JavaScript.

Now that you're aware of all of the problems and outcomes, remember that you just need to cover all of the possible cases of your code scope (using any language or library) to avoid runtime execution errors. Type annotation and runtime type checking are great allies that help with that task.

Thanks to Ira Santiago.

Client, Network, Server and Application Caching on the Web

Mon, 17 Apr 2017 00:00:00 +0000

Front-end (React) Snapshot Testing with Jest: What is it for?

Tue, 11 Apr 2017 00:00:00 +0000

Você é irresponsável por não escrever testes de Front-end?

Thu, 06 Apr 2017 00:00:00 +0000

Nesta semana tivemos o 1º Meetup do Facebook Developer Circle — React em Porto Alegre. O evento atraiu uma audiência bem diversa e graças a seu formato, trouxe uma discussão muito interessante: qual a importância de testes no desenvolvimento de código.

Apesar de o assunto não ser novidade para mim, já ouço falar sobre testes há quase uma década, toda vez que acompanho uma discussão a respeito, aprendo um pouco mais. Com certeza não sou um especialista no assunto, estou bem longe disto, mas gostaria de sumarizar neste texto aquilo que já aprendi.

Em primeira análise, é importante destacar que existem diferentes tipos de testes que garantem o correto funcionamento e adequação de diferentes aspectos de um projeto. Aqui, irei me deter muito mais aos testes unitários, que são aqueles que se propõe a garantir o correto funcionamento das menores porções de uma aplicação.

It’s absolutely irresponsible not to write automated [unit] tests as part of software development and you should avoid jobs at companies that don’t do it.

O trecho acima, extraído de uma discussão sobre empresas em que programadores não escrevem testes unitários, poderia facilmente encerrar qualquer debate sobre a necessidade ou não de se manter testes de código. Porém, Desenvolvimento Web nem sempre é sobre Desenvolvimento de Software e saber como e o que testar nem sempre é algo simples.

Tipos de projetos

A primeira metade da minha carreira dediquei ao desenvolvimento de páginas Web estáticas e bem simples. Passei mais de meia década criando diversos Websites institucionais e não tenho vergonha alguma de dizer que, naquela época, não sabia ao menos como escrever uma única linha de testes.

Web development can range from developing the simplest static single page of plain text to the most complex web-based internet applications, electronic businesses, and social network services. — Wikipedia

Até mesmo hoje, ainda mantenho alguns projetos sem nenhum teste. Indo um pouco além, acredito que projetos que são simples e que serão desenvolvidos em poucas semanas, não necessitam da escrita de testes. Mesmo porque, é inegável que existe um custo atrelado a esta prática.

Por outro lado, 1) projetos que tomarão meses para serem escritos, 2) projetos que terão alguns ciclos de desenvolvimento ou 3) possuem lógicas até mesmo pouco complexas, são Aplicações Web ou Projetos de Software e devem ser acompanhados por testes. Nestes casos, o custo de escrita de testes torna-se rapidamente um investimento.

Aplicações Web sem testes

Como apontado em Refactoring Without Good Tests, em códigos sem testes não é possível identificar se mudanças irão quebrar outras partes da aplicação. Não existe refactoring em código sem testes. Além disto, testes unitários reforçam boas práticas, podem antecipar a identificação de falhas no código e servem como documentação de funcionalidades.

Este círculo vicioso explica facilmente a falácia de desenvolvedores muito ocupados para escrever testes: 1) estes perdem muito tempo experimentando o impacto de novas funcionalidades, 2) corrigindo bugs que já estão em produção ou 3) tentando entender decisões de design de código infelizes as quais tem medo de alterar.

Alguns dos argumentos contra a escrita de testes apontam que a suíte para determinado projeto seria impraticável e lenta e que um roll-out faseado (deploy para uma pequena porção de clientes) permite melhor identificar bugs através de usuários reais. O que foi apontado até aqui e ainda mais pagar o preço da frustração de alguns usuários tornam argumentos como estes inválidos. Ainda, estes argumentos evidenciam decisões ruins de design e arquitetura de um projeto.

Aplicações Web mantidas sem nenhum tipo de teste e com uma equipe de desenvolvimento sem planos para reverter esta situação indicam uma cultura de desenvolvimento envenenada. — eu mesmo é que acho isto!

Aprendendo a testar

Apesar de existirem diversas teorias que você já deve conhecer, enxergar valor na escrita de testes vai muito além do bê-a-bá do Test-driven Development (TDD). A falta de prática e experiência é um dos principais motivos de vermos tantos projetos com testes pouco úteis ou ausentes.

O que melhor funcionou nos projetos em que já trabalhei foi enxergar as porções de código que não são declarativas e garantir que estas sejam testadas. Código Front-end sempre terá muitas porções declarativas e não costumo escrever testes unitários para estas porções. Nunca tive pretenção de seguir TDD a risca.

Em outras palavras, acredito apenas que código que possui diferentes fluxos deva ser testado. Simples assim. Seguindo esta prática, o código abaixo não teria testes:

const CartItem = ({ _id, image, quantity }) => {
  return (
    <div className="ui item">
      <div className="ui tiny image">
        <img src={image} alt={`Product ${_id}`} />
      </div>
      <div className="middle aligned content">
        <div className="ui tiny header">Product {_id}</div>
        <div>Quantity: {quantity}</div>
      </div>
    </div>
  )
}

Por outra lado, o código abaixo, apesar de parecer mais simples, possui a lógica relacionada a capacidade de um produto ser adicionado ao carrinho de compras. Este código deve ser testado.

const AddToCartButton = ({ _id, stock, addToCart }) => {
  const disabled = stock.remaining <= 0

  return (
    <button disabled={disabled} onClick={() => !disabled && addToCart(_id)}>
      Add to cart
    </button>
  )
}

Existem diversas ferramentas para testar código Front-end. Por este exemplo se tratar de código React, uma das melhores alternativas da atualidade para escrita de testes unitários é o framework Jest com a biblioteca Enzyme. O Jest é o framework padrão do projeto Create React App.

describe('<AddToCartButton />', () => {
  describe('with remaning stock', () => {
    const addToCart = jest.fn()
    const wrapper = shallow(<AddToCartButton _id='123' stock= addToCart={addToCart} />)

    it('should render a enable button', () => {
      expect(wrapper.prop('disabled')).toBe(false)
    })

    it('should call add to cart on click', () => {
      wrapper.simulate('click')

      expect(addToCart).toHaveBeenCalledWith('123')
    })
  })

  describe('with no remaning stock', () => {
    const addToCart = jest.fn()
    const wrapper = shallow(<AddToCartButton _id='123' stock= addToCart={addToCart} />)

    it('should render a disabled button with', () => {
      expect(wrapper.prop('disabled')).toBe(true)
    })

    it('should call add to cart on click', () => {
      wrapper.simulate('click')

      expect(addToCart).not.toHaveBeenCalled()
    })
  })
})

Note que o exemplo acima explora muito bem os dois possíveis fluxos de execução do nosso componente: 1) quando há items em estoque e 2) quando não há items em estoque. A partir destes fluxos, o botão pode estar habilitado ou inabilitado e a função addToCart é chamada ou não a partir do clique do usuário.

Criando uma cultura de testes

Escrever testes não deve ser difícil ou doloroso. O primeiro passo para incorporar o hábito de testar código em um projeto é escolher e configurar de maneira adequada as ferramentas que permitam sua escrita. Todos os desenvolvedores devem prezar pela evolução e funcionamento do ecossistema de testes.

A partir deste ponto, é importante revisar o código dos pares e promover tech talks para aprimorar o conhecimento e experiência de escrita de testes na equipe. Os testes devem ser executados de maneira automatizada a cada mudança de código.

So, if you are going to touch the code, for bug fixes or refactoring, then first write the unit tests. For bugs unit tests will help prove where the problem is, as you can duplicate it. — James Black on Stack Overflow

Para projetos legados que não tenham testes, escrever testes antes de alterar qualquer porção de código é uma ótima regra que pode e deve ser incorporada na equipe. Isto aumenta aos poucos a cobertura de testes do projeto e permite praticar refactoring.

Além dos testes unitários

Testes automatizados de navegador, conhecidos como Smoke Tests são uma ótima alternativa para garantir que as principais funcionalidades da Aplicação estejam operando adequadamente. Smoke Tests inclusive servem muito bem para introduzir algum tipo de teste em projetos legados.

Este artigo foca quase que apenas em testes unitários e funcionais. Porém, tratando-se de Desenvolvimento Front-end é importante destacar que existem também: 1) Performance Tests, 2) Visual/CSS Regression Tests e 3) Cross-Browser Testing.

A conclusão mais rasa é que você deve testar código se almeja trabalhar com sanidade e de maneira responsável em uma Aplicação Web. Além disto, aprender os conceitos e sobretudo praticar a escrita de testes unitários expande a maneira que você pensa a respeito de código e o torna um profissional melhor.

*Artigo orinalmente postado no Medium.

CSS on Steroids: a era dos pós-processadores

Wed, 10 Feb 2016 00:00:00 +0000

No longínquo ano de 2013 escrevi o artigo CSS on Steroids que é muito sobre como escrever CSS de forma mais eficiente. Alguns anos se passaram e uma série de tecnologias nasceram, enquanto outras estagnaram.

A premissa do artigo original é apresentar alguns dos problemas mais comuns em folhas de estilo e sugerir soluções apoiadas no uso de pré-processadores e outras ferramentas como os pós-processadores. O plano aqui é revisitar as soluções e analisar novas estratégias de escrita de código. Conhecer as principais funcionalidades dos pré-processadores de CSS é pre requisito para esta leitura.

Os pós-processadores são utilitários difundidos e apoiados principalmente pela ferramenta PostCSS. A ferramenta permite a escrita de plugins em JavaScript que podem ter acesso ao seu código CSS e aplicar transformações ou validações. Ao longo do artigo aprofundaremos mais o assunto e veremos alguns exemplos de plugins e sua aplicação.

O que é apresentado a seguir tem base em projetos que vivenciei e portanto são frutos de algumas das minhas experiências. Cada projeto e equipe constituem seu próprio contexto e, como sempre, algumas coisas (ou até mesmo tudo) podem não se aplicar em sua integridade.

Variáveis de código: cores e medidas

Medidas e cores normalmente são os maiores causadores de ruídos em uma folha de estilo. Interpretar as cores ou decifrar a relação entre medidas apenas batendo o olho no código não é tarefa fácil. As variáveis dos pré-processadores são de grande ajuda, veja abaixo um exemplo consolidando práticas apresentados no artigo original.

$site-width: 960px;
$site-gap: 20px;
$speaker-list-width: 400px;

$grey-color: #3F4955;
$main-color: $grey-color;

body {
  width: $site-width;
}

.header {
  width: $site-width - $site-gap;
}

.speaker-list {
  width: $speaker-list-width;
  border: 1px solid $main-color;
}
.speaker-list__item {
  width: $speaker-list-width / 2;
}

Alguns editores já possuem plugins para facilitar a interpretação das cores hexadecimais. Mas é importante ponderar a necessidade de cada variação de cor ao consolidar arquivos de layout vindos do Photoshop, Sketch e demais ferramentas. Um novo aliado é o utilitário de pós-processamento CSS Colorguard que identifica variações desnecessárias de uma mesma cor.

De qualquer maneira, variáveis com cores ainda auxiliam muito na tarefa de manter o controle sobre as cores utilizadas no projeto. Possuir um único arquivo no projeto contendo todas as cores ajuda a construir um projeto mais enxuto e organizado, o que facilita alterar ou replicar componentes.

A não ser que você esteja escrevendo o sucessor do Twitter Bootstrap, arquivos imensos cheios de variáveis que tem seu valor acessado uma única vez e que são associadas a componentes e especificidades do layout não fazem sentido. Arquivos como este apenas dão trabalho de manutenção e podem criar uma falsa impressão de flexibilidade ao projeto. Poder alterar as características de um componente é mais fácil quando existe um único arquivo para cada componente responsável por toda sua estilização.

Por outro lado, variáveis são úteis quando componentes do projeto estão relacionados e precisam compartilhar determinado valor. Lembrando que casos como estes devem ser evitados ao máximo por tornarem o código do projeto mais acoplado e dificultar seu reuso. Ainda, as variáveis podem ser utilizadas em escopos isolados de um componente para facilitar o entendimento de algum cálculo ou relação principalmente quando estiver lidando com medidas.

Abra mão de variáveis como $main-color e $speaker-list-width que criam indireção com pouco benefício. Abuse de variáveis como $dark-grey, $soft-grey e $grey que garantem identidade ao projeto e também $width facilitam o entendimento de algum cálculo em um escopo isolado. O exemplo acima revisado fica dividido em dois arquivos como estes:

// file: colors.scss
$grey: #3F4955;

// file: speaker-list.scss
@import 'colors.scss';

.speaker-list {
  $width: 400px;

  width: $width;
  color: $grey;

  &__item {
    width: $width / 2;
  }
}

Frameworks e mixins

Os maiores representantes desta classe são o Compass e Bourbon. Esta dupla já solucionou muitos problemas no passado. Porém o próximo passo é nos livrarmos destas tecnologias.

O motivo para nos livrarmos do Compass poderia ser o fato deste ser um projeto abandonado, mas existem outros mais. O Compass é um projeto muito generalista ao tentar gerar sprites, definir resets, trazer consigo alguns utilitários, incluir fontes e images e ainda gerenciar vendor prefixes. Existem soluções individuais muito melhores para cada um dos pontos que o projeto endereça:

Sprites: lembre-se que SVG está em alta, mas se mesmo assim precisar de sprites, vá de Spriteful ou spritesmith. Fazer uso do pós-processador postcss-sprites é uma ótima alternativa não invasiva que permite deixar de usar a técnica de spriting facilmente no futuro quando não mais necessária.
CSS resets: esta é fácil demais, basta rodar npm install --save normalize.css.
Mixins: como Miller já apontou em The problem with CSS pre-processors, os mixins muito bem podem ser classes utilitárias dentro do seu projeto. Classes utilitárias também eliminam o uso de @extend.
Vendor prefixes: Algumas propriedades do CSS passam por uma fase de adaptação e especificação e por causa disto ganham um prefixo com base no fabricante do navegador. Apesar de não ser aconselhado fazer uso de propriedades em fase de experimentação, muitos projetos aplicam gradientes até hoje da seguinte maneira @include background(linear-gradient($blue, $light-blue));. Os navegadores atualmente lançam versões com um frequência incrível e é comum ter definições de projeto do tipo: daremos suporte para as duas últimas versões do Chrome. Soluções de pós-processamento como o Autoprefixer são muito melhores pois não exigem estudar e lembrar de aplicar diferentes mixins além de não tornarem seu projeto escravo de um framework.
Assets: o Compass possuía uma série de utilitários para cuida dos assets permitindo determinar tamanho de imagens, adicioná-las à folha de estilo através de Data URI (apesar da técnica já ter sido envolvida em algumas polêmicas) dentre outras features. Uma alternativa, se o projeto estiver utilizando a ferramenta para bundle Webpack, são os loaders css-loader, file-loader e url-loader que endereçam algumas destas features e ainda garantem cache busting. Na categoria de pós-processadores, o postcss-assets é uma boa alternativa para projetos que não utilizam Webpack.

Muitos dos argumentos que desencorajam o uso de Compass também se aplicam para o Bourbon. Em linhas gerais, fuja destas tecnologias. A excessão é que o Bourbon pode prestar muito bem para prototipações e como substituto do Twitter Bootstrap quando em conjunto com a tríade Neat, Bitters e Refills.

Nesting: agrupando regras

Agrupar regras de CSS na minha opinião é a feature mais interessante dos pré-processadores. Aplicar media queries localizadas e facilitar o uso do BEM são atualmente meus casos de uso favoritos.

.speaker-list {
  @media screen and (min-width: 1200px) {
    width: 50%;
  }

  &__item {
    color: $red;
  }
}

O ponto do uso de nesting continua sendo tomar cuidado e sempre ter em mente a folha de estilo gerada para não extrapolar no peso dos seletores.

Utilitários de pós-processamento como postcss-modules e React CSS Modules também permitem manter o escopo dos componentes em um projeto. Tratando especificamente de postcss-modules, seu uso exige que seu HTML tenha relação com o CSS gerado, em outras palavras, seu projeto precisará no mínimo de uma template engine.

O React CSS Modules tem uma adoção mais simples para quem estiver em um projeto React e utilizando uma ferramenta de bundle. De qualquer maneira, soluções mais avançadas como estas parecem promissoras e merecem atenção.

Indo além com pós-processadores

Já vimos uma série de pós-processadores que podem ser aplicados ao seu workflow. O próximo passo, como você já deve imaginar é eliminar até mesmo os pré-processadores. O pacote PreCSS amarra uma série de outros pós-processadores que permitem substituir as principais features dos pré-processadores e ainda oferecer mais.

A grande vantagem dos pós-processadores é permitir facilmente escrever ou ativar novos scripts para experimentar alguma especificação CSS ainda em fase de rascunho e ou atender um conjunto de funcionalidades limitadas do SASS que são realmente úteis para seu projeto e equipe.

Conclusão

A experiência de reler o artigo original e ver o quanto a comunidade front-end evoluiu a maneira de utilizar e enxergar código CSS é incrível. A aposta em tecnologias mais específicas em desfavor das generalistas Compass, Bourbon e até mesmo SASS é uma grande tendência.

O Compass já é um projeto declaradamente extinto e investir em um workflow baseado unicamente em pós-processadores é a bola da vez. Minha aposta é que na próxima revisão eu não mais mencionarei pré-processadores.

Qual a sua opinião? Gostou do artigo? Comente abaixo!

O dilema do único na Web

Tue, 09 Feb 2016 00:00:00 +0000

As construções que fundamentam uma página Web são todas únicas. Cada página assume uma aba do navegador, com um endereço único, um <body> de um lado e outro window do outro. É tudo global, meu amigo.

A unicidade é tão absurda que JavaScript, HTML e CSS compartilham do mesmo fluxo de execução. Caso um demore a fazer seus cálculos, os demais sofrerão. Acontece.

Na Web, nada se parte pela metade. Mesmo quando desafiamos com alguns scripts postos a executar em modo assíncrono, além da garantia que irão executar um por vez, temos a garantia que o farão até terminar.

Simples e fácil como parece. A plataforma Web joga fora toda a complexidade que a computação carregou ao longo de sua história e é única em como conquista adeptos.

2016 e o estado do desenvolvimento front-end

Wed, 13 Jan 2016 00:00:00 +0000

Há algum tempo reflito e tenho intenção de escrever um texto a respeito das ferramentas e tecnologias utilizadas no desenvolvimento front-end. Mas no fundo, sempre batia uma preguiça e nada me motivava o suficiente a botar a bunda na cadeira e escrever. Eis que surge o artigo The Sad State of Web Development (que foi recentemente apagado) e cá estou pra retrucar.

Vamos começar deixando algo bem claro: eu não considero o JavaScript uma linguagem tecnicamente extraordinária. Porém o ecossistema, liberdade e ubiquidade que a linguagem alcançou não tem precedentes. JavaScript é a linguagem mãe da Web. Qualquer profissional que pensa em passar perto de desenvolvimento para a Web precisa respeitar e dominar JavaScript.

A questão mais polêmica em volta do desenvolvimento front-end parece residir no fato das tecnologias nascerem e morrerem com uma certa frequência. Isto gera uma insegurança a respeito de qual tecnologia adotar em um novo projeto. Sem falar que, aprender tanta coisa em um espaço tão curto de tempo incomoda muita gente. O que poucos observam é que Web é a plataforma que mais evolui nos últimos anos. Não há tecnologia que tenha evoluído tanto, de forma aberta, e em tantas frentes. Lembre-se que a Web é a única plataforma que funciona adequadamente no seu celular, tablet e desktop.

Criar projetos que estejam alinhados com tamanha evolução de hardware e usuários ávidos por experiências impecáveis exige o surgimento e amadurecimento de soluções e ferramentas mais inteligentes. Acreditar que um projeto de Web vai durar anos mantendo um visual grosseiro e sem (re)evoluções é apostar em interfaces como a do Hacker News.

A medida que os projetos se tornam cada vez mais complexos, é uma tremenda burrice escrever código JavaScript sem nenhum padrão ou auxílio de tecnologias modernas. Mesmo no dia-a-dia, refatorar e aprimorar código adotando uma nova biblioteca ou framework pode trazer grandes benefícios. As ferramentas e tecnologias utilizadas invariavelmente influenciarão na experiência do usuário. Pronto, é por isto que a cada dia alguns desenvolvedores reinventam a roda: para que ela gire melhor.

Ir contra a adoção de tantas novas tecnologias é nadar contra a maré. Reflita se não pode ser preguiça sua ou mesmo desinformação. Saber a dose certa do uso de novas tecnologias é um grande desafio, mas antes disto é preciso entendê-las e aprendê-las. Pra quem só conhece martelo, tudo parece prego. Um 2016 de novos aprendizados para todos nós!

Fluxo de execução assíncrono em JavaScript – Generators e Async Functions

Tue, 05 Jan 2016 00:00:00 +0000

Screencast da apresentação Lapidando o Globo Play

Sun, 13 Dec 2015 00:00:00 +0000

A apresentação aborda os aspectos técnicos e de desenvolvimento do produto Globo Play para a Web. A palestra foi apresentada originalmente no evento Front in Floripa deste ano. Se preferir, os slides também estão disponíveis.

Fique a vontade para tirar suas dúvidas ou contestar qualquer aspecto no espaço abaixo.

Dicas para evoluir um front-end legado

Tue, 18 Aug 2015 00:00:00 +0000

Com a evolução das plataformas computacionais, os requisitos que as aplicações para a Internet devem atender têm se tornado mais e mais complexos. Em conformidade a isto, a disciplina de front-end é a que mais tem sofrido mudanças na sua gama de técnicas e práticas. A lista de novos frameworks, bibliotecas e modos de escrita de código de maneira geral cresce a cada dia.

Este artigo é focado em dicas gerais de como aplicar gradativamente as mais adequadas técnicas e práticas para modernizar o front-end de aplicações legadas.

Estude o projeto

O projeto precisa ser estudado a fundo para que suas principais fraquezas sejam descobertas. Alto acoplamento, falta de organização, duplicação e código mal escrito (ou exclusivo para atender navegadores bem antigos) serão problemas facilmente encontrados em projetos legados.

Procure seguir os principais fluxos de navegação e compreender bem o projeto antes de aplicar qualquer mudança. Estudar bibliotecas e demais dependências é também importante nesta etapa.

Testes

Uma suíte de testes é essencial para evoluir código legado. Caso seu projeto não possua nenhum tipo de teste, os funcionais são uma boa pedida para começar. Cubra ao máximo com testes uma funcionalidade antes de começar a mexer em seu código. Apenas assim há uma garantia (mas nunca de 100%) de que você não irá quebrar nada.

Dependências

Evoluir a versão das dependências de um projeto pode nem sempre ser uma tarefa fácil. Apesar disto, pode trazer muitos benefícios de perfomance e correção de bugs. Investigue quais as mudanças nas versões das dependências que irá evoluir. Mudar a versão da jQuery, por exemplo, não é uma boa ideia se sua aplicação não possui uma cobertura adequada de testes.

Separe o código em módulos

O mais comum dos problemas de um código CSS e JavaScript legado é a falta de separation of concerns. São várias as maneiras de modularizar seu código, mas a simples tarefa de dividir o código em diferentes arquivos é um ótimo começo. Durante este trabalho, será fácil identificar duplicações e criar novas abstrações.

Ferramentas como o Asset Pipeline do Rails e gerenciadores de tarefas como Gulp e Grunt são essenciais para concatenar arquivos e executar tarefas de pré e pós processamento. Adotar e ou melhor configurar uma destas ferramentas para o projeto será o primeiro passo desta etapa.

Pare de referenciar ids do HTML

Os ids servem como alvos para âncoras e portanto não podem ser duplicadas em um documento. Referenciar ids no CSS quebra completamente qualquer chance de reuso de código. Altere todos os seletores do CSS que referenciam ids para utilizarem classes.

As mudanças no seu JavaScript devem ser ainda mais drásticas. Evite usar ids ou classes (que servem para estilização) no seu código JavaScript. Os data attributes são ótimos para adicionar comportamento e dar acesso ao DOM.

Implemente um sistema de escrita de CSS

Apesar de não ser um assunto tão novo, a maioria dos projetos legados não segue nenhum tipo de sistema de escrita de CSS. Além disto, seletores muito generalistas e os odiados !important podem ser ervas daninhas que você terá que se livrar.

Há um tempo escrevi um artigo sobre os sistemas de escrita de CSS mais populares. A dica final de escrita de código apresentada no artigo pode servir de inspiração.

Não abandone os padrões do HTML

Muitos frameworks e bibliotecas modernas de front-end pegam a responsabilidade de redefinir o fluxo da aplicação. E isto não é uma má ideia. Porém, é bastante difícil evoluir um código legado para utilizar AngularJS, por exemplo. Neste ponto, as dicas do artigo que escrevi sobre como atribuir comportamento a componentes devem ajudar.

Em resumo, aplicar alguns padrões simples e bibliotecas como o Backbone.js são uma melhor estratégia. Apenas considere utilizar um framework quando seu código estiver em um estado mais maduro (e ainda assim, pense muito bem a respeito). Receber um HTML pronto do servidor e enviar dados utilizando formulários nunca será uma má ideia. Alguns frameworks privam você disto.

Componentes

Reconhecer quais componentes fazem parte do projeto e entender quais seus padrões visuais é uma tarefa árdua. O trabalho aqui é relacionar HTML, CSS, JS e demais recursos em uma única unidade.

Esta etapa poderá exigir que você inclua novas bibliotecas e ferramental de build para o projeto. Não se preocupe, você já conhecerá o suficiente do projeto para fazer estas escolhas de forma acertada.

Evoluir projetos legados exige um plano de ação bem definido. Ao contrário do senso comum, sair reescrevendo tudo ou criar um projeto novo quase sempre é uma má ideia. O ideal é estabelecer pequenas interações. Lembre-se de documentar e compartilhar seu plano de ação a medida que seu domínio sobre o projeto for aumentando.

Se cada vez você deixar um pouco melhor que antes, nunca vai degenerar - Juan Ibiapina.

Ao mesmo tempo, não se preocupe, algumas vezes etapas intermediárias deixarão o código mais verboso e até mais confuso. Foque no resultado final, umas escoras e tapumes poderão ser necessários para fazer sua obra.