JavaScript

Quando usar sessionStorage e localStorage?

Olá, Web Developers!

Hoje vou falar sobre um erro comum que vejo muitos colegas cometerem: usam o localStorage para armazenar variáveis temporárias.

Quem usa sabe que o localStorage nos permite armazenar dados de forma simples e sem expiração, ou seja, ficam lá enquanto não apagarmos por código ou pelo próprio navegador.

localStorage.setItem('name', 'Treinaweb');  // <- prefira esta forma
localStorage['name'] = 'Treinaweb';

Porém, já vi situações em que é necessário armazenar um valor logo que o usuário abre a página e manter esse valor enquanto o usuário estiver navegando, mesmo que ele mude de página.

Por ter a possibilidade do usuário clicar em um link e mudar de página (ou recarregá-la), uma variável comum não servirá, pois terá seu valor perdido.

Por isso, muitos desenvolvedores que conhecem o localStorage aproveitam-se dele para esse objetivo. No entanto, o localStorage não tem seus valores apagados, o que causa a necessidade do programador verificar se o usuário acabou de entrar na página para poder apagar ou reiniciar os valores que armazenou no localStorage.

É exatamente para essas ocasiões que existe o sessionStorage. Seu funcionamento e API são idênticos aos do localStorage, com a diferença de que os dados só duram durante a sessão. O usuário pode até mesmo ir para outro site, e as variáveis permanecerão. Elas só serão apagadas quando o usuário fechar o navegador.

sessionStorage.setItem('name', 'Treinaweb');
sessionStorage.getItem('name');

Imagine que o usuário está preenchendo um formulário e pensa em verificar uma informação em outra parte do seu site. Você poderia armazenar os dados do formulário para ele continuar quando voltar. Ao voltar ao formulário, o trabalho dele ainda estará lá.

Se não tem sentido o formulário continuar preenchido caso o usuário tenha fechado o navegador, sem problemas, pois isso irá apagar o sessionStorage, e quando ele voltar, o formulário estará em branco, pronto para um novo preenchimento.

Desta maneira você poderá iniciar suas variáveis temporárias, acessar seus valores enquanto o usuário navega (mesmo que seja para outro site), e não precisará se preocupar em apagar os valores, pois serão apagados automaticamente quando o usuário fechar a janela.

Então, quando precisar de uma variável temporária, lembre-se que o sessionStorage existe para isso. Use o localStorage apenas para dados que devem se manter gravados mesmo com o fechamento do navegador.

Até a próxima!

Funcionalidades do jQuery com a API nativa do JavaScript

Olá, Web Developers!

Em outro post falamos sobre quando usar e quando não usar o jQuery. Agora nós vamos ver sobre as principais funcionalidades do jQuery que podemos executar apenas com JavaScript nativo. Lembre-se que a maioria dessas funcionalidades estão presentes apenas em navegadores modernos.

JavaScript Básico
Curso de JavaScript Básico
CONHEÇA O CURSO

Busca de elementos

A principal funcionalidade do jQuery é a busca de elementos. Quando no JavaScript tínhamos funções com nomes compridos e diferentes para cada tipo de seleção (nome do elemento, ID, nome da classe, etc), o jQuery facilitava nossa vida oferecendo uma busca por seletores escritos com a sintaxe do CSS. Hoje em dia isso é possível com a função querySelectorAll().

Também podemos usar essa função para fazer uma busca dentro do elemento selecionado.

// jQuery
var el  = $('div #abc .def');  
$(el).find('button.close');

// JS
var el = document.querySelectorAll('div #abc .def');  
el.querySelectorAll('button.close');  

Requisições Ajax

Uma das funcionalidades mais usadas é a função $.ajax(). Ela é bem mais simples e direta do que trabalhar com o velho objeto XMLHttpRequest.

Hoje em dia nós possuímos a função fetch(), que é tão simples quanto a função $.ajax() e nos permite trabalhar com Promises:

// jQuery
$.ajax({
  'url': '/my/url',
  'type': 'POST',
  'data': JSON.stringify(data)
});

// JS
fetch('/my/url', {  
  'method': 'POST',
  'body': JSON.stringify(data)
})

Classes CSS

Também é comum trabalharmos com a inserção e remoção de classes dos elementos. Poucos usam as funções do JavaScript (muitos nem as conhecem) porque normalmente manipulam com jQuery ou usam algum framework que acaba manipulando os elementos automaticamente.

// jQuery
$(el).addClass('my-class');
$(el).removeClass('my-class');
$(el).toggleClass('my-class');
$(el).hasClass('my-class');

// JS
el.classList.add('my-class');  
el.classList.remove('my-class');  
el.classList.toggle('my-class');  
$(el).hasClass('my-class');

Extend

Esta função permite que os valores de um ou mais objetos sejam atribuidos em outro objeto.

// jQuery
$.extend({}, objA, objB);

// JS
Object.assign({}, objA, objB);  

Uma diferença aqui é que o jQuery permite que os campos de nível mais profundo do objeto sejam misturados, enquanto a função nativa do JavaScript só permite uma união nos níveis mais rasos do objeto.

Eventos

Esse é bem conhecido: adicionar e remover listeners em elementos.

O que não atrai muito (como a maioria das funcionalidades) é a diferença do tamanho do nome das funções.

// jQuery
$(el).on(eventName, eventHandler);
$(el).off(eventName, eventHandler);

// JS
el.addEventListener(eventName, eventHandler);  
el.removeEventListener(eventName, eventHandler);  

Finalizando

Uma lista bem completa de funcionalidades do jQuery feitas com JavaScript puro pode ser encontrada em:

http://youmightnotneedjquery.com/

Porém, como dito anteriormente, deve-se analisar bem as necessidades do projeto para poder dizer se devemos incluir ou não o jQuery.

JQuery Completo
Curso de JQuery Completo
CONHEÇA O CURSO

Compartilhe as suas ideias com a gente aí nos comentários? o/

Ainda vale a pena utilizar o jQuery?

Olá, Web Developers!

Hoje trago aqui algumas reflexões sobre a biblioteca JavaScript mais famosa, o jQuery. Será que ainda vale a pena utilizá-lo?

Ainda é muito comum ver empresas, tanto no Brasil quanto no exterior, cobrando o conhecimento de jQuery. Normalmente ocorre um dos dois motivos para esse requisito: falta de conhecimento de quem escreveu o perfil da vaga ou necessidade de dar suporte a um código legado.

A API do jQuery é bem simples de se aprender, então, nesse caso, será um ponto positivo em seu currículo (mesmo que provavelmente você nem precise utilizar na nova empresa), e não te tomará tanto tempo assim.

Conhecimento nunca é demais. Não precisa estar totalmente atualizado sobre as novidades e conhecer tudo o que está na documentação. Pelo menos saber como ele funciona, sim, vale muito a pena. Há muitos cenários possíveis no mundo da programação e pode aparecer um caso em que a ferramenta se encaixe perfeitamente para a sua necessidade.

Quando devo usar jQuery?

A maior parte dos desenvolvedores dirão “nunca!” para essa pergunta logo de prima. Mas, vamos analisar alguns pontos positivos:

1) Caso precise trabalhar com o DOM, o uso do jQuery pode ajudar, já que sua API é mais elegante e simples do que o JavaScript puro.

2) Caso esteja criando um projeto pequeno, como um site simples, não fará sentido usar um framework poderoso. Se for trabalhar com muitas funções das quais o jQuery possua, ele pode ser um belo aliado para se escrever menos código.

3) Outra vantagem é sua simplicidade. Normalmente a maioria dos desenvolvedores novatos conseguem aprender a usar jQuery mais rapidamente do que outros frameworks ou a API do DOM. Assim, eles já conseguem criar efeitos, animações, requisições e lidar com eventos.

4) Há muitos plugins e ferramentas que usam jQuery. É comum encontrar boas soluções para algumas situações e, nesses casos, o jQuery acaba sendo uma dependência obrigatória. Mas, se possível, prefira procurar algo independente de jQuery para não ter que incluí-lo apenas por causa de uma funcionalidade.

5) O jQuery era muito apreciado por normalizar as diferenças de funcionalidades que existiam entre navegadores. Então, caso ainda precise dar suporte a navegadores mais antigos, o jQuery pode ser uma boa pedida.

6) Por ser simples e direto ao ponto, pode ser perfeito caso esteja apenas precisando criar um protótipo rápido. Eu adoro tentar fazer várias coisas com CSS puro e evitar o máximo de JavaScript, mas tenho que admitir que animações e efeitos com jQuery são bem mais rápidos e simples de se escrever.

JQuery Completo
Curso de JQuery Completo
CONHEÇA O CURSO

Quando evitar?

1) Hoje em dia temos várias funcionalidades do jQuery no próprio JavaScript e as animações são melhores quando feitas com CSS3. Caso só precise dar suporte aos navegadores modernos, provavelmente não precisará do jQuery.

2) Não é bom ficar acessando o DOM diretamente. Caso precise atualizar muito as informações na tela, exibir muitas informações ou acessar o DOM frequentemente, prefira um framework ao invés de usar jQuery ou JavaScript puro, pois eles já são otimizados para se trabalhar com templates, acessando o DOM o mínimo possível. Há também bibliotecas leves que servem apenas para criar componentes com uma ótima performance.

3) O jQuery tem como principal objetivo facilitar o uso de funcionalidades simples do JavaScript (“write less, do more”). Porém, em muitas aplicações será muito comum a necessidade de funcionalidades mais complexas como: roteamento, componentização, formatação, modularização, validações, etc. Nesses casos, para realmente escrever menos, você provavelmente precisará de um framework, o qual terá tantas funcionalidades que dispensará o uso de jQuery.

4) Ao escrever várias funcionalidades com jQuery, é muito comum misturar HTML no meio do JavaScript, dentro de funções. O uso de frameworks modernos nos ajuda a separar e manter o código mais organizado.

5) Em aplicações grandes, você terá muito mais trabalho para gerenciar cada pedaço do que cada código faz. Com jQuery, muitas funcionalidades serão escritas por você, enquanto que com um framework, muitas coisas já estarão prontas e testadas. Tem pessoas que tem medo de frameworks com muita “mágica”, porém, se você souber como usar estas “mágicas” a seu favor, você desenvolverá muito mais rápido e sem erros. As próprias linguagens de programação são “mágicas” em certas funcionalidades. Nós simplesmente aprendemos a utilizá-las ao invés de ficar pensando em como cada bit de informação será processado.

6) O site http://youmightnotneedjquery.com/ possui uma grande lista de funcionalidades do jQuery e como fazer o mesmo com JavaScript puro. Várias funcionalidades são simples de aprender, e as mais complexas você pode encapsular em uma função, evitando ter que incluir a biblioteca inteira caso precise apenas de uma ou outra, apenas.

Vue.js - Criação de interfaces web
Curso de Vue.js - Criação de interfaces web
CONHEÇA O CURSO
Angular - Criação de interfaces web
Curso de Angular - Criação de interfaces web
CONHEÇA O CURSO

Então, devo ou não utilizá-lo?

Como sempre, a maioria das coisas em programação resume-se em “depende”.

A melhor maneira de saber se deve ou não usar alguma coisa é ter um bom conhecimento sobre as ferramentas disponíveis, conhecimento da equipe, quais as necessidades do projeto, tempo disponível, etc.

Não há uma resposta absoluta. O melhor mesmo é ter a cabeça aberta para se fazer uma boa análise do que será necessário fazer no projeto e escolher as melhores ferramentas. Fuja de pessoas que usam a palavra “sempre” para alguma biblioteca ou framework pois, normalmente, possuem pouco conhecimento em outras ferramentas.

Espero que os pontos levantados aqui te ajudem a se decidir em seu próximo projeto. Caso tenha outras ideias de quando usar ou evitar, compartilhe com a gente aí nos comentários. =)

Aprenda a formatar as mensagens do console do navegador

Olá, Web Developers!

Muitos aqui sabem que os navegadores possuem console e que podemos executar o comando console.log() para imprimir mensagens e objetos, o que nos ajuda muito na hora de fazer debug.

JavaScript Básico
Curso de JavaScript Básico
CONHEÇA O CURSO

Porém, quando entramos em sites como, por exemplo, o Facebook e abrimos o console, podemos ver a seguinte mensagem:

Facebook Console

Muitas pessoas não sabem, mas as mensagens do console podem ser estilizadas em alguns navegadores. Para o exemplo a seguir, abra o console em seu computador e clique na aba Result:

Você terá o seguinte resultado:

Console JavaScript - Formatação de Cores

Para poder estilizar as mensagens do console, basta colocar %c junto ao texto que você está passando para o comando console.log() (ou qualquer outra função que imprima algo no console, como console.warn()). Em seguida, basta passar a estilização como um segundo parâmetro. Ela é feita via CSS mesmo:

console.log('%c Meu Texto','color: white; background-color: red;');

Mas, já que estamos falando de CSS, que tal também imprimir uma imagem?

No console, execute o seguinte comando:

console.log('%c', 'padding: 40px 45px;line-height:100px;background:url("http://i65.tinypic.com/dnixjm.png") no-repeat;background-size: cover;');

Você terá o seguinte resultado:
Console com Imagem

Ok, mas o console é mais para debug. Por que eu usaria isso?

Um cenário é quando a sua equipe usa muito o console para monitorar algo durante o desenvolvimento e deixa várias mensagens sendo impressas. Poder formatá-las, colocar imagens, etc, pode ajudar a deixá-lo mais organizado, facilitando a leitura dos conteúdos impressos. Mas há de se ter cautela, pois muitas mensagens sendo impressas com o console aberto podem afetar a performance da sua página e isso vai te atrapalhar no processo de desenvolvimento.

Um ótimo caso é fazer algo parecido com o Facebook. Se há possibilidade dos seus usuários abrirem o console para tentar algo, você pode chamar a atenção deles avisando que eles mesmos podem estar correndo algum tipo de risco.

O terceiro motivo é quando a intenção é exatamente fazer com que o usuário abra o console para usá-lo. Quando você entra no site da biblioteca RxJS e abre o console, você é recebido com uma simples mensagem dizendo que você pode experimentar os códigos da biblioteca diretamente por ele. Nesse caso, você poderia receber o usuário com o logo do seu projeto e uma mensagem com uma formatação simples (se o navegador dele suportar).

RxJS Console

E aí, o que achou? Já usou essa funcionalidade? Compartilhe com a gente aí nos comentários!

React Native - Autenticação com Firebase Authentication
Curso de React Native - Autenticação com Firebase Authentication
CONHEÇA O CURSO

Usando o Async / Await do JavaScript

Olá, Web Developers!

Vamos falar hoje sobre a possibilidade de criar funções assíncronas e como trabalhar com elas de forma bem simples com as novas instruções async e await do JavaScript.

Vamos imaginar a seguinte situação:

function func1(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(77 + number) , 1000)
    })
}

function func2(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(22 + number) , 1000)
    })
}

function func3(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(14 * number) , 1000)
    })
}

// Usando as funções
func1(4)
   .then(number => {
        console.log('Hello');
        return func2(number);
   })
   .then(number => {
        console.log('World');
        return func3(number);
   })
   .then(result => console.log(result))

Usar essas funções assíncronas com Promises nos poupam do “Callback Hell”, mas mesmo assim, precisamos passar uma função de Callback para cada then().

Com async e await podemos trabalhar com código assíncrono em um estilo mais parecido com o bom e velho código síncrono. Vamos reescrever o exemplo anterior, partindo da parte onde consumimos as nossas três funções assíncronas:

async function myAsyncFunction(){
    var number = await func1(4);

    console.log('Hello');
    number = await func2(number);

    console.log('World');
    var result = await func3(number);

    console.log(result);
}

Primeiro de tudo, temos o comando async. Ele faz com que uma função automaticamente retorne uma Promise. Então:

// retorna o número 5
function example1(){
    return 5;
}

// retorna uma Promise com o valor 5
function example2(){
    return Promise.resolve(5);
}

// faz exatamente o mesmo que a função "example2()"
async function example3(){
    return 5;
}

Depois, dentro de myAsyncFunction(), veja que usamos o comando await antes de chamar as funções que retornam Promises:

async function myAsyncFunction(){  
   var number = await func1(4);

Veja que, ao invés de usar o then() com uma função de callback, nós simplesmente estamos jogando o retorno da função em uma variável, como fazemos com códigos síncronos.

O comando await basicamente pausa a função myAsyncFunction() até que a Promise dentro da função func1() seja resolvida. Então o valor retornado é atribuído à variável e o código de myAsyncFunction() continua de onde parou.

Lembre-se: o comando await só pode ser executado dentro de uma função marcada como async. Por isso que para executar as funções eu criei a função myAsyncFunction().

Como estamos falando de funções assíncronas, não pense que essa “pausa” que o await causa irá travar o seu código todo. Lembre-se que essa é só uma nova sintaxe para se trabalhar com Promises. Então, quando o await pausar a sua função, outras funções poderão estar sendo executadas.

JavaScript Intermediário
Curso de JavaScript Intermediário
CONHEÇA O CURSO

Devo usar Async / Await ao invés de then()?

Isso vai depender muito da situação. Muitos desenvolvedores vão pelo gosto, outros definem um padrão único a se seguir para o projeto e outros decidem o que é melhor para cada caso.

Em meus projetos eu prefiro usar o que irá permitir uma melhor leitura e entendimento do código. No exemplo lá em cima, vimos um caso em que usar as funções com await deixou o código mais legível do que ficar criando vários then() (apesar de sempre atribuir o valor na mesma variável).

Vamos a um exemplo em que o then() pode deixar nosso código mais legível:

function example1(){  
    return func1(4)
        .then(func2)
        .then(func3);
}

async function example2(){  
    var number = await func1(4);
    number = await func2(number);
    number = await func3(number);
    return number;
}

// ou
async function example3(){  
    return func3(await func2(await func1(4)))
}

O example2() e example3() usam o async/await. Veja que, nesse caso que só encadeamos funções, o uso do then() em example1() acaba sendo bem mais simples que example2() e mais legível que example3().

Sem contar que o comando await só funciona dentro de uma função async. Se estivermos dentro de uma função que não é async, teríamos que criar uma função async apenas para poder executar o comando await, enquanto as Promises podem ser usadas em qualquer lugar.

Concluindo

Async / Await aumentam as nossas possibilidades, mas também temos que analisar quando é o melhor momento para utilizá-los.

Os navegadores modernos e o Node.js já dão um bom suporte para eles, então, aproveite (com moderação)! 😉

JavaScript Avançado
Curso de JavaScript Avançado
CONHEÇA O CURSO

JSON vs Objeto JavaScript – Qual a diferença?

Olá, Web Developers!

Há algum tempo eu escrevi um post onde eu chamei um objeto de JSON, e um leitor me corrigiu. Ele estava completamente certo!

Muitas pessoas (inclusive eu) possuem a mania de chamar qualquer objeto JavaScript de JSON e muitas acreditam que são a mesma coisa. Isso está errado e eu notei que há muitas pessoas perguntando essa diferença, inclusive em grupos do Facebook e no StackOverflow.

TypeScript - Primeiros Passos
Curso de TypeScript - Primeiros Passos
CONHEÇA O CURSO

Qual a diferença entre um Objeto Literal e o JSON?

Muitos sabem que o nome JSON vem de “JavaScript Object Notation”. Então, por que objetos JavaScript escritos de forma literal nem sempre são JSON?

{
   "a": 2,
   "b": 3
}

O exemplo acima pode ser considerado tanto um objeto literal em JavaScript quanto um JSON. Acontece que o JSON é um formato usado para a transferência de dados, independente de linguagem de programação, assim como o XML, CSV ou YAML.

Apesar da sintaxe de um objeto literal e do JSON serem muito parecidas (a ponto de podermos usar um JSON como objeto literal), o JSON possui especificações. Se sairmos dessas especificações, não estamos mais falando de um JSON.

Principais Diferenças entre JSON e Objeto Literal JavaScript

Chaves – As chaves no JSON devem vir entre aspas duplas. No Objeto Literal, as chaves podem ser strings com aspas simples, duplas, sem aspas, variáveis ou Symbols.

Valores – O Objeto Literal JavaScript aceita qualquer tipo de dado presente na linguagem (como Date) e até funções.

O JSON só aceita os seguintes tipos de valor:

  • string
  • number
  • boolean
  • null
  • array
  • outro JSON

Por essas limitações que o MongoDB usa o chamado BSON ao invés do JSON para armazenar dados. Além de armazenar o JSON em um formato binário, também adiciona suporte a outros tipos de dados, como:

  • integer
  • double
  • date
  • byte array
  • objeto BSON
  • array BSON
  • código JavaScript
  • dados binários em MD5
  • expressões regulares

Finalizando

Então, quando estamos transferindo dados, estamos falando de JSON, um formato de transferência de dados. Quando o JSON é interpretado por uma linguagem de programação, ele é convertido para um objeto (pode ser C#, Ruby(hash), Python(dictionary), Java, etc). Mesmo que no JavaScript a sintaxe de um objeto literal seja igual, ele não é um JSON.

React - Introdução
Curso de React - Introdução
CONHEÇA O CURSO

JavaScript Generators e onde usá-los

Olá, Web Developers!

Anteriormente escrevi aqui sobre os Generators. Agora vamos ver duas das principais situações onde eles vêm sendo bastante utilizados.

JavaScript Básico
Curso de JavaScript Básico
CONHEÇA O CURSO

Iterators

Iterator é um objeto que nos fornece o método next() para acessar cada um dos valores que ele contém. Um Array e uma String já possuem Iterators por natureza. Por exemplo: O Iterator da String "TreinaWeb" nos retornaria uma letra por vez a cada execução do método next().

Iterators são criados com o Symbol @@iterator, mas também podemos usar Generators para criá-los de uma maneira bem mais simples:

function* fibonacci(){
    var n1 = 1,
        n2 = 1;
    while(true){
        var current = n2;
        n2 = n1;
        n1 += current;
        yield current;
    }
}

var fib = fibonacci();
console.log(fib.next()); // 1
console.log(fib.next()); // 1
console.log(fib.next()); // 2
console.log(fib.next()); // 3
console.log(fib.next()); // 5

Fluxo Assíncrono

Já que o Generator para a execução e nos dá a possibilidade escolhermos quando continuar, ele pode ser de grande ajuda em códigos assíncronos. Muitos desenvolvedores estão utilizando-o para fazer com que códigos com Promises fiquem mais parecidos visualmente com um código síncrono.

Vamos imaginar a seguinte situação:

function func1(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(77 + number) , 1000)
    })
}

function func2(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(22 + number) , 1000)
    })
}

function func3(number){
    return new Promise(resolve =>{
        setTimeout(() => resolve(14 * number) , 1000)
    })
}

// Usando as funções
func1(4)
   .then(number => {
        console.log('Hello');
        return func2(number);
   })
   .then(number => {
        console.log('World');
        return func3(number);
   })
   .then(result => console.log(result))

Fizemos um exemplo bem genérico, onde temos três funções assíncronas, e entre as respostas delas, fazemos uma operação com console.log().

Você pode imaginar isso como, por exemplo, fazer requisição a um servidor, processar os dados, fazer outra requisição com os dados processados, receber os dados e finalmente, exibí-los na tela.

Veja como podemos deixar com um visual mais parecido com código síncrono, usando a biblioteca co:

var co = require('co');

// As funções de antes
co(function* (){
  var a = yield func1(4);

  console.log('Hello');
  var b = yield func2(a);

  console.log('World');
  var c = yield func3(b);

  console.log(c)
})

Criamos uma função anônima como Generator e a passamos para a função co da biblioteca que importamos. A cada execução de uma Promise, passamos o yield junto. Na linha seguinte podemos continuar escrevendo normalmente, como um código síncrono comum. Nada de ficar encadeando then.

Esse comportamento pode ser feito com o Async/Await. A maioria dos navegadores modernos já estão dando suporte e o Node.js já suporta desde a versão 7.

Concluindo

Os Generators já possuem um bom suporte nos navegadores modernos. Eles nos possibilitam trabalhar de novas formas, e cada vez mais a forma como escrevemos JavaScript vem sendo mudada.

Como sempre, em programação podemos fazer a mesma coisa de várias maneiras, e o Generator é uma poderosa adição ao nosso arsenal. É uma boa ferramenta para trabalharmos com código assíncrono.

Caso você esteja interessado em saber mais sobre código assíncrono, programação reativa e funcional, veja o nosso curso de RxJS.

RxJS - Programação reativa
Curso de RxJS - Programação reativa
CONHEÇA O CURSO

Requisições Ajax no JavaScript com a Fetch API

Olá, Web Developers!

Há muito tempo que, ao fazer requisições, os desenvolvedores costumam usar a função ajax() do jQuery, pois ela é muito mais simples de usar do que o método nativo do JavaScript, o XmlHttpRequest().

if (window.XMLHttpRequest) { // Mozilla, Safari, ...
  request = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
  try {
    request = new ActiveXObject('Msxml2.XMLHTTP');
  } 
  catch (e) {
    try {
      request = new ActiveXObject('Microsoft.XMLHTTP');
    } 
    catch (e) {}
  }
}

request.addEventListener('load', function(){ 
  console.log(this.responseText) 
});

request.open('GET', 'https://api.github.com/search/repositories?q=javascript', true);

request.send(null);
Webpack - Empacotando aplicações
Curso de Webpack - Empacotando aplicações
CONHEÇA O CURSO

Só para pegar o XmlHttpRequest() já era chatinho. Depois, era necessário criar um listener, passando uma função de callback, uma função para mandar abrir a conexão e, por fim, executar a função que iria enviar a requisição.

Muitos desenvolvedores iniciantes até chegam a inserir o jQuery em seus projetos apenas por causa da função $.ajax(), enquanto outros criam funções para facilitar o uso do XmlHttpRequest(). O AngularJS até nos disponibilizava o serviço $http, para facilitar as requisições, e assim não era preciso incluir o jQuery para esse propósito.

O fetch() faz a mesma coisa, mas com uma API nova, mais flexível e simples de usar. Ela tem a premissa de substituir a antiga XMLHttpRequest.

fetch('https://api.github.com/search/repositories?q=javascript')
.then(response => response.json())

Uau!

O único parâmetro obrigatório do fetch() é uma String que indica o endereço de onde iremos fazer a requisição. Com isso, faremos uma requisição GET.

O fetch() nos retorna uma Promise. Essa Promise retorna um objeto Response com informações da resposta do servidor. Como queremos pegar a resposta em formato JSON, basta executar a função json().

Configurando a requisição

O fetch() aceita um segundo parâmetro, onde podemos passar um objeto de configuração. É nele onde indicamos o método da requisição, cabeçalho, corpo, etc.

fetch('https://myexample.com', {
    method: 'POST',
    headers: {'Content-Type':'application/x-www-form-urlencoded'}, 
    body: 'foo=bar&blah=1'
})
.then(response => response.json())
  • method – GET | POST | PUT | DELETE | HEAD
  • url – URL da requisição
  • headers – cabeçalho
  • body – corpo da requisição
  • referrer – referência da requisição
  • mode – cors | no-cors | same-origin
  • credentials – indica se os cookies devem ser enviados junto com a requisição
  • redirect – follow | error | manual
  • integrity – valor de integridade da fonte
  • cache – modo do cache (default | reload | no-cache)

Finalizando

Veja então que o fetch() é bem mais simples de usar e, atualmente, ele já tem um bom suporte por parte dos navegadores modernos, como você pode visualizar aqui no caniuse. Qualquer coisa, pode-se criar um fallback para dar suporte a navegadores antigos (se for muito necessário para o seu projeto :P).

Você já tem usado o fetch()? Compartilhe com a gente aí nos comentários!

JavaScript Avançado
Curso de JavaScript Avançado
CONHEÇA O CURSO

JavaScript Assíncrono com Generators

Olá, Web Developers!

Você já usou Generators? Possuímos a mesma coisa em linguagens como Ruby, por exemplo. Para quem nunca viu, esse nome pode assustar no começo. Mas os Generators são apenas funções. A diferença é que podemos pausar essa função em uma determinada linha e depois mandá-la continuar de onde parou.

Essa é uma funcionalidade que veio no ES2015 para nos auxiliar no desenvolvimento de código assíncrono. Vejamos um exemplo simples de Generator:

function* myCounter(){
    var i = 0;
    while(true){
        yield i++;
    }
}

var counter = myCounter();

A primeira diferença que notamos com uma função comum é o “*” depois de “function”. Isso indica que essa função é um Generator. Dentro da função criamos um looping infinito que incrementa uma variável.

Dentro do looping colocamos o comando yield. Pense nesse comando como um return. O yield retornará o valor passado para ele e irá pausar a função. Note que eu disse que a função foi pausada, e não finalizada.

Depois, executamos a nossa função, que é um Generator, e guardamos o seu retorno na variável counter. Porém, counter não irá receber o valor que passamos para o yield. Receberemos um objeto que nos informa o valor e se o Generator foi finalizado.

Para pegar o valor que passamos no yield, basta executar a função next().

var counterValue = counter.next();

Múltiplos yields

Podemos ter vários yield em uma função, como:

function* myGenerator(){
    yield 5;
    console.log("we’re back!");
    yield 10;
}

Ao executar o Generator, a função irá parar no primeiro yield. Ao executar next() pela primeira vez, obteremos o valor 5. Ao executar next() pela segunda vez, a mensagem “we’re back!” será impressa e receberemos o valor 10.

Lista de retornos

Ao invés de um looping para ficar exibindo itens de um Array, podemos mandar o Generator retornar um valor por vez:

function* myGenerator1(){
    yield [1,2,3,4,5];
}

function* myGenerator2(){
    yield* [1,2,3,4,5];
}

No myGenerator1, ao executar o next() receberemos um array. Mas no myGenerator2, receberemos primeiro o 1, depois o 2, depois o 3, etc, conforme formos executando o next(). Para esse comportamento, basta colocar o * junto ao comando yield.

Finalizando

Os Generators já possuem um bom suporte nos navegadores modernos. Caso haja necessidade de dar suporte a navegadores mais antigos, você pode usar o Babel para transformar o seu código em ES5.

É uma boa ferramenta para trabalharmos com código assíncrono. Caso você esteja interessado em saber mais sobre código assíncrono, Programação Reativa e Funcional, veja o nosso curso de RxJS:

RxJS - Programação reativa
Curso de RxJS - Programação reativa
CONHEÇA O CURSO

Não conhecia o Generators? O que achou? Já conhecia ou precisou em algum projeto?

Compartilhe com a gente nos comentários!

Precisamos falar sobre o TypeScript

Ultimamente muita gente tem torcido o nariz para um novo superset do JavaScript. Sim, estamos falando do TypeScript.

O TypeScript é um caso interessante. Percebo ultimamente que, ou você o adora (o que é meu caso) ou você simplesmente o odeia. Parece não haver um consenso intermediário de maneira geral na comunidade. Por que será que isso acontece? Será que existem conceitos errôneos difundidos na comunidade sobre o TypeScript? Será que ainda há pontos cruciais a serem melhorados nele? Vamos discorrer sobre isso! 🙂

TypeScript - Primeiros Passos
Curso de TypeScript - Primeiros Passos
CONHEÇA O CURSO

É da Microsoft…

Acho que esse ponto talvez seja o mais complicado de se discutir. Muita gente simplesmente tem ódio do TypeScript simplesmente por ele ser da Microsoft. Em minha opinião, acho que é simplesmente perda de tempo deixar de utilizar alguma tecnologia por ela ser de alguma empresa específica. Acho que a qualidade técnica e a maneira como a companhia conduz a plataforma, além dos fatores externos (infraestrutura, contratos comerciais, etc.), deveriam ser os fatores cruciais para se decidir se determinado framework/linguagem/plataforma será adotada ou não. Porém, sabemos que por muitas vezes a paixão toma lugar da razão nesse tipo de tomada de decisão (eu comentei um pouco sobre esse tipo de cenário no artigo Não seja um profissional “intolerante”.

Eu concordo que a conduta que a Microsoft tinha há algum tempo não era a mais adequada com relação aos desenvolvedores. Mas também precisamos reconhecer que essa postura nos últimos anos mudou da água para o vinho! Em pouco mais de cinco anos, a Microsoft se tornou a maior contribuidora em software open source no GitHub. Duvida? Você pode comprovar através do próprio GitHub.

A Microsoft também se tornou uma das principais contribuidoras do kernel Linux. Ela ainda tem disponibilizado uma série de ferramentas que antes eram licenciadas (caso do Visual Studio e do Xamarin, por exemplo) de maneira completamente gratuita. As principais plataformas da Microsoft (o que inclui toda a plataforma do .NET Core e o próprio TypeScript) estão abertos no GitHub. Não há mais motivos para achar que a Microsoft “tem um plano maquiavélico/diabólico/capitalista de dominar a indústria de software” (embora esse acabe sendo um objetivo indireto de qualquer empresa no fim das contas).

A Microsoft mostra atualmente que já entendeu que ela precisa se tornar parte do mundo open source, além de já ter provado que sim, ela tem muita coisa interessante para a comunidade. Para mim, isso tudo reforça que essa mania de falar que o que é da Microsoft é ruim deveria já ter ficado no passado.

O TypeScript não quer substituir o JavaScript

Algumas pessoas que eu conheço têm pavor do TypeScript porque acham que ele vem para substituir o JavaScript, o que é um equívoco. O TypeScript nunca teve a intenção de substituir completamente o JavaScript. A própria documentação diz que ele é na verdade um superset do JavaScript. E o que isso quer dizer? Isso quer dizer que ele visa fornecer alguns recursos que o JavaScript não oferece por padrão. Entre esses recursos, temos por exemplo:

  • A oportunidade de termos tipos de dados mais definidos (tornando o JavaScript um pouco mais tipado);
  • Uma sintaxe e estrutura fortemente orientados à objetos (o TypeScript é fortemente influenciado pelo C# e F#), aproximando a experiência de desenvolvimento de linguagens tradicionalmente orientada a objetos como o C# e o Java;

Essas vantagens, por decorrência, trazem outras vantagens:

Por causa da existência de tipagem e também de uma sintaxe mais clara, as IDEs ganham a possibilidade de aprimorarem seus mecanismos de detecção de erros e de sintaxe em tempo de desenvolvimento. Isso quer dizer que, usando TypeScript, sua IDE poderá lhe avisar de alguma passagem de tipo incorreta ou mesmo sobre alguma sintaxe incorreta enquanto você ainda escreve o código. Ferramentas como o IntelliSense (conhecido por muitos como AutoComplete) também podem ser bem mais efetivas nesse cenário. Não quero dizer que, quando utilizamos JavaScript “convencional”, as IDEs não ofereçam esse tipo de suporte, mas o suporte das IDEs para o TypeScript é ou pelo menos tem a grande tendência de ser bem mais aprimorado;

Ainda temos, como decorrência do ponto anterior, a possibilidade de que o código escrito com TypeScript seja bem mais robusto, seguro e fácil para ser testado. Isso tudo, mais uma vez, graças aos conceitos de linguagens estáticas e tipadas que o TypeScript trouxe para o mundo das linguagens funcionais, na minha opinião, no nível certo. TypeScript não é JavaScript simplesmente tipado e estático, ele torna possível utilizar o melhor do mundo de linguagens de tipagem fraca e funcionais e do mundo de linguagens estáticas e de tipagem forte;

Aqui já é uma opinião bem mais pessoal, mas eu prefiro a sintaxe do TypeScript que a sintaxe do JavaScript, principalmente no que tange à orientação a objetos. Eu gosto das “regras de sintaxe” e a pseudo-tipagem que o TypeScript traz para o JavaScript. Ou você realmente acha que isso:

var __extends = (this && this.__extends) || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
};
var Animal = (function () {
    function Animal(name) {
        this.name = name;
    }
    Animal.prototype.move = function (distanceInMeters) {
        if (distanceInMeters === void 0) { distanceInMeters = 0; }
        console.log(this.name + " moved " + distanceInMeters + "m.");
    };
    return Animal;
}());
var Snake = (function (_super) {
    __extends(Snake, _super);
    function Snake(name) {
        return _super.call(this, name) || this;
    }
    Snake.prototype.move = function (distanceInMeters) {
        if (distanceInMeters === void 0) { distanceInMeters = 5; }
        console.log("Slithering...");
        _super.prototype.move.call(this, distanceInMeters);
    };
    return Snake;
}(Animal));

… é mais claro que isso?

class Animal {
    constructor(public name: string) { }
    move(distanceInMeters: number = 0) {
        console.log(`${this.name} moved ${distanceInMeters}m.`);
    }
}

class Snake extends Animal {
    constructor(name: string) { super(name); }
    move(distanceInMeters = 5) {
        console.log("Slithering...");
        super.move(distanceInMeters);
    }
}

Agora, nada impede de você utilizar JavaScript “tradicional” em conjunto com o TypeScript, mesmo porque no final o TypeScript é transpilado para JavaScript! No final, tudo vira JavaScript… Veja que no exemplo acima mesmo isso ocorre quando utilizamos o tradicional console no meio do código TypeScript. Isso reforça que a idéia da Microsoft não é substituir o JavaScript, nem nunca vai ser! A idéia é podermos ter a possibilidade de utilizar um ferramental mais poderoso para produzir um código mais robusto e legível.

Agora terei um código muito verboso

Não há como negar isso. As características técnicas (tipagem, vocação para orientação à objetos, etc.) fazem naturalmente que o código TypeScript torne-se um pouco mais verboso e com menos vocação para o lado funcional, principalmente para quem vem de linguagens fracamente tipadas e/ou funcionais. Na verdade, no final, o TypeScript faz uma mistura entre os conceitos dos dois paradigmas (funcional e orientado a objeto) e dos dois sistemas de tipagem (fracamente tipado e fortemente tipado).

E aí, já viu: isso pode provocar tanto admiração como também raiva. Algumas pessoas podem gostar bastante dessa mistura (meu caso) ou outras podem simplesmente odiar (já que o TypeScript corre o sério risco de desagradar tanto os adeptos do paradigma funcional como também do paradigma orientado à objetos). Temos verbosidade no TypeScript sim, mas ainda sim temos aspectos funcionais também presentes.

O TypeScript ainda não consegue lidar bem com todas as bibliotecas JavaScript

Para que o TypeScript consiga “conversar” com as APIs de outras bibliotecas (por exemplo, o jQuery), ele precisa de um arquivo com a extensão **.d.ts*. Este arquivo, conhecido como TypeScript Type Definition, traz os mapeamentos necessários para que através do TypeScript você possa acessar e utilizar os métodos expostos por uma biblioteca externa, mesmo que esta não tenha sido escrita com o TypeScript. Esse arquivo acaba funcionando como uma ponte entre uma biblioteca externa e o TypeScript.

Aí reside o problema: nem todas as bibliotecas possuem esse arquivo que as prepara para serem consumidas por código TypeScript. As mais famosas bibliotecas já possuem este arquivo preparado, mas se você utiliza uma biblioteca um pouco menos conhecida ou possui uma biblioteca proprietária, ela pode não ser de cara compatível com um código TypeScript de maneira completa. Nesse caso, não há outro cenário: será necessário que você mesmo escreva este arquivo de definições ou abra mão do TypeScript. E isso, de fato, pode vir a ser um empecilho dependendo do projeto…

O TypeScript não é o salvador da pátria

alt

O TypeScript pode trazer algumas confusões com relação a sua utilização… Já que o código TypeScript no final é sempre transpilado para um código JavaScript “normal”, podemos dizer que todo código JavaScript também é código TypeScript! Isso é legal porque justamente conseguimos ainda ter as características legais do JavaScript com o poder do TypeScript.

Por isso mesmo que o TypeScript não visa substituir o JavaScript, e sim o complementar. Algumas pessoas têm comentado ultimamente, chegando ao (absurdo, na minha opinião) de dizer que hoje TypeScript é a linguagem de alto nível enquanto o JavaScript é o assembly.

É cedo demais para dizer isso; assim como, em minha opinião, nem sempre o TypeScript pode ser a melhor saída. Para se escolher se você deve usar TypeScript ou não, não se esqueça de levar em consideração a quebra de paradigmas que ele pode causar na equipe de desenvolvimento, bem como o suporte às bibliotecas que você pretende utilizar. E esses são somente dois pontos que devemos considerar… TypeScript não é uma bala de prata..

Afinal, devo utilizar TypeScript ou não?

Mais uma vez, essa é uma questão muito subjetiva, onde não temos o certo e o errado. Tudo vai depender da situação como um todo. Eu gosto da idéia do TypeScript e o utilizo sem problema nenhum: o sistema de tipagem, a sintaxe mais clara e a aliança com o JavaScript (afinal, ainda temos JavaScript como produto final) me agradam bastante. Mas você pode ter uma opinião diferente… No final, nenhum de nós vai estar 100% certo ou 100% errado, hehe.

Agora, eu não acho perda de tempo estudar TypeScript. Para mim, está claro que ele é algo que veio para ficar. Além de tudo, ele ainda está muito alinhado com o ECMA 6, tendo muitos recursos que o ECMA 6 propõe. E tem mais um tempo: alguns frameworks, como Angular e Ionic, estão adotando o TypeScript, assim como outros estão pelo menos oferecendo suporte a ele. Por essas e outras, o TypeScript veio para ficar.

Melhor para nós! Mais uma opção de ferramenta legal que podemos utilizar em nossos projetos. 🙂 Que a guerra dos frameworks/bibliotecas/supersets do JavaScript continue! o/

Você quer aprender TypeScript? Veja esse nosso incrível curso:

TypeScript - Primeiros Passos
Curso de TypeScript - Primeiros Passos
CONHEÇA O CURSO

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200