TypeScript

[wp_ad_camp_3]

O TypeScript é uma linguagem criada pela microsoft para ajudar na criação de aplicações JavaScript adicionando recursos poderosos como por exemplo: tipagem e propriedades estáticas. As classes foram introduzidas oficialmente no ecossistema do javascript no ES6 mas por razões de compatibilidade o TypeScript permite que você faça a transpilação para o ES5 para aumentar a compatibilidade do seu código.

O que é transpilação?

Transpilação nada mais é que pegar seu código e converter ele para outro em tempo de compilação ou seja, o programador escreve seu código em uma linguagem e após compilar ele converte esse código para um equivalente em outra linguagem de programação.

Problema?

[wp_ad_camp_2]

Geralmente quando desenvolvemos fazendo o uso do TypeScript seguimos a lógica de modelar todas as nossas informações (o que é sensacional e deve ser feito) e para isso geralmente seguimos nossos conhecimento de orientação a objetos e saímos criando nossas classes de modelos (as models). O problema é que o uso de classes gera um over head muito grande no código transpilado e isso aumenta o tamanho de nossos arquivos JS e com isso o tamanho de nosso aplicativo.

Abaixo deixo uma imagem de uma classe no TypeScript:

O resultado do código acima após ser transpilado seria um código mais ou menos como esse na imagem abaixo:

É muito código para uma definição de uma classe não concordam?

E a solução?

[wp_ad_camp_1]

Em JavaScript a tipagem não existe ou seja o tipo da variável é o que tem dentro dela. O TypeScript ajuda no desenvolvimento implementando controles como esses minimizando erros e melhorando a performance no desenvolvimento. Ao criar uma interface o TypeScript faz o uso dela na compilação e após isso não faz a transpilação para o JavaScript. Já as classes são definições, elas possuem métodos com regras aplicadas e isso precisa ser transpilado.

Mas calma, não se apavorem! Muitas classes realmente precisam e devem ser implementadas dessa forma mas nas classes de modelo não tem essa necessidade, afinal de contas não é comum você implementar métodos em suas models não é mesmo? Para isso podemos simplesmente substituir nossas classes de modelos por “interfaces” assim ao transpilar elas não vão gerar esse código “desnecessário” em nossa aplicação.

Abaixo deixo o exemplo de definição para a mesma classe só que fazendo uso de interface:

O resultado do código transpilado é exatamente como na imagem abaixo:

O resultado da transpilação não gera código JavaScript isso é importante porque diminui o tamanho do build e melhora o tempo de processamento para tarefas como concat e minify.

Conclusão

Uma simples mudança ajuda na diminuição de tamanho do build de nossos sistemas e melhora o seu tempo de compilação. O Angular é um exemplo que usa esse pensamento em suas bibliotecas, eles simplesmente exportam as interfaces para serem utilizadas nos projetos.

Deixo como dica o site http://www.typescriptlang.org/play/ entrem lá coloquem o conteúdo de todas as suas models e façam vocês mesmo os testes.

The post TypeScript: Interface ou Classes? appeared first on Hiago Silva Souza.

Antes de criticarmos ou falar que algo é ruim, é bom entendermos o motivo pelo qual aquilo existe.

Porque o CORS existe?

O CORS (do inglês cross-origin resource sharing) é um mecanismo que permite que os conteúdos de domínios diferentes sejam compartilhados. Ele existe para evitar que o conteúdo de um determinado domínio seja utilizado por outro sem a autorização do mesmo.

Exemplo: supondo que eu queira exibir os conteúdos do youtube em meu site, faço uma análise das requisições HTTP’s feitas pelo youtube, obtendo os parâmetros da chamada criaria uma UI para usar as informações do youtube, tirando assim proveiro dos dados deles. O CORS impediria que essa ação fosse executada na camada do navegador, ou seja é uma segurança para você!

Como funcionar o CORS?

O CORS vai analisar se o recurso que você tenta carregar está sob o mesmo domínio e porta. Com isso mesmo que você tenha sua API rodando no endereço “http://localhost:8080” e sua aplicação ionic/angular rodando em suas respectivas portas (8100/4200) ao chamar a API com toda certeza vai ter sua requisição bloqueada e vai receber a mensagem de CORS.

Quando você não está sob o mesmo domínio você vai notar na parte de redes que uma requisição http gera 2 outras chamadas. A primeira chamada usa o verbo http OPTIONS, ele é utilizado pelo navegador para perguntar ao  seu servidor/aplicação quais os tipos de requisição sua aplicação permite e é no OPTIONS que você deve informar suas configurações do CORS através de Headers.

Opções para o CORS

1. Access-Control-Allow-Origin: Header utilizado para informar quais domínios você permite que use o seu conteúdo.
2. Access-Control-Allow-Methods: Header utilizado para informar quais verbos http você permite a partir dos domínios liberados.
3. Access-Control-Allow-Headers: Header utilizado para informar quais “Headers” os domínios liberados podem enviar para você.
4. Access-Control-Max-Age: Header utilizado para informar quanto tempo é válido essas configurações de CORS.

O que não devo fazer?

[wp_ad_camp_3]

Bom acho que a primeira coisa que você deve se questionar é: Preciso realmente liberar o CORS em seu ambiente? Mesmo em aplicações ionic a liberação não é necessária. O mesmo para Angular, vendo que em produção o domínio será o mesmo (ou não rs).

Mas vamos lá, supondo que você chegou a conclusão que liberar o CORS é realmente necessário, não faça isso “Access-Control-Allow-Origin: *” ao fazer isso você está simplesmente tirando uma camada de segurança que foi criada para você. Caso você esteja rodando uma aplicação ionic (já compilada), não é necessário liberar o CORS mas caso queira liberar é necessário apenas  permitir o endereço http://localhost:8080/ que é o endereço que o ionic utiliza para carregar sua aplicação compilada ou seja a liberação correta (caso deseje fazer) é “Access-Control-Allow-Origin: http://localhost:8080“.

Outra coisa bem importante é o Access-Control-Max-Age geralmente nos tutoriais ninguém comenta sobre ele. Lembra aquela segunda requisição? A do tipo OPTIONS, então ela é feita quando expira o Access-Control-Max-Age então se você não falar para o navegador que essas definições só mudam de X em X tempos todo e qualquer request que você fizer o seu servidor vai receber duas requisições (cada browser tem seu tempo padrão). Em ambiente de desenvolvimento, geralmente desabilitamos os cache’s e com isso o Access-Control-Max-Age não vai fazer efeito. Mas em ambiente de produção é algo muito importante.

Como assim não preciso liberar o CORS para o ionic?

Sim é isso mesmo, não precisa! E já vou explicar o motivo. Quando você desenvolve seu aplicativo, você geralmente testa seu projeto seu navegador e ele implementa o Same-Origin-Policy por isso que você tem problemas com CORS e acaba fazendo tudo quanto é tipo de liberação. Porém quando o seu aplicativo é compilado para APK ou IPA o ionic de forma nativa consegue desabilitar o CORS da WebView (e eles já fazem isso).

Vale lembrar que para o iOS o ionic sempre usou o UIWebView só que agora eles migraram para o MKWebView e no iOS eles não conseguem desabilitar o CORS nessa webview em especifico =/. Então ou você faz um downgrade da webview, ou você libera o CORS para a origem “http://localhost:8080” ai é uma decisão pessoal, basta acessar a documentação com as melhorias propostas pela MKWebView e colocar na balança.

Para fazer o downgrade da WebView basta colocar o conteúdo abaixo em seu config.xml para a plataforma iOS:

<preference name="CordovaWebViewEngine" value="CDVUIWebViewEngine" />

E meu ambiente de desenvolvimento, como faço?

Então para você desabilitar a checagem do CORS em seu ambiente de desenvolvimento você pode fazer uso de uma extensão do google chrome mas eu não recomendo, tive muitos problemas com essa extensão. Ela liberou o CORS mas sempre me trouxe problema com encodings em outros sites que eu acessava.

Não quer usar a extensão?

Então vamos lá, o ionic e o angular tem um recurso bem interessante e muito pouco conhecido que tem exatamente essa função (impedir problemas com CORS) são os proxies.  É algo bem simples, mas eles são apenas para ambientes de desenvolvimento. Então não se esqueça de criar uma configuração para seu endpoint  🙂

O que é um proxy? Como ele funciona?

Um proxy basicamente é um serviço intermediário entre você e seu servidor de aplicação, ele recebe sua requisição e repassa ela para o servidor original.

Vamos criar o seguinte cenário: Tenho a url (http://localhost:8888/) rodando um backend, então vamos criar um mapeamento para informar que tudo que for chamado na uri /api seja passado para o backend.

Vamos supor que você esteja desenvolvendo em uma aplicação ionic, ao digitar o endereço http://localhost:8100/api/criar-usuario ele vai redirecionar internamente no processo do ionic serve a requisição para http://localhost:8888/criar-usuario então sua aplicação vai estar chamando uma URL que está no mesmo domínio e na mesma porta assim a Same-Origin-Policy não vai ser aplicada e você pode seguir seu desenvolvimento sem necessidade de liberar o CORS para desenvolver.

Configurando o proxy no ionic

[wp_ad_camp_2]

Para configurar o proxy no ionic basta abrir o arquivo ionic.config.json e criar uma nova propriedade chamada proxies e nela definir seus paths.

Exemplo:

{
	"name": "app-meuapp",
	"app_id": "",
	"type": "ionic-angular",
	"proxies": [{
		"path": "/api",
		"proxyUrl": "http://localhost:8888/"
	}],
	"integrations": {
		"cordova": {}
	}
}

Configurando o proxy no Angular

Para fazer a configuração de seu proxy no Angular o processo é semelhante. Para isso é necessário criar um arquivo JSON com as configurações os paths desejados. Então vamos criar o arquivo proxy.conf.json e vamos colocar o conteúdo abaixo. Após isso basta você inicializar seu projeto com o comando ng serve –proxy-config proxy.conf.json.

Observação: Recomendo que coloque esse comando na chave start do package.json assim você só vai precisar rodar o comando npm start

Conteúdo para o proxy.conf.json

{
  "/api": {
    "target": "http://localhost:8888",
    "secure": false
  }
}

Conclusão

[wp_ad_camp_1]

O CORS é um recurso de segurança muito importante e precisamos gerenciar ele de acordo com as necessidades do nosso projeto, fazendo o uso das técnicas mencionadas nesse post é possível trabalhar sem dor de cabeça e claro ter um desenvolvimento saudável e seguro.

The post Ionic & Angular: Fazendo o CORS seu amigo appeared first on Hiago Silva Souza.

O que é uma promise?

A promise é uma abstração para representar fluxos de ações em códigos assíncronos. No JavaScript é um objeto e seu resultado representa uma operação assíncrona ela pode ser resolvida ou rejeitada.

A promise possui duas maneiras para retornar a informação, são as funções de callback resolve e reject. As duas chamam métodos retornados junto a promise. Os métodos then e catch, são retornados juntos a promise e eles são responsáveis por receber os métodos de callback para a operação.

Exemplos de uma promise:

// ATENÇÃO: Exemplo em javascript puro.
saldoConta = 100;
function sacar(valor) {
    return new Promise(function(resolve, reject) {
        setTimeout(function() {
            if (saldoConta < valor) {
                reject("Você não possui saldo suficiente");
            } else {
                saldoConta = saldoConta - valor;
                resolve("Saldo retirado com sucesso");
            }
        }, 3000);
    });
}

// agora vamos sacar 90 reais?
sacar(90).then(function(r) {
    alert('sucesso: ' + r);
}).catch(function(e) {
    alert('erro: ' + e);
});

// agora vamos sacar mais 11 reais?
sacar(11).then(function(r) {
    alert('sucesso: ' + r);
}).catch(function(e) {
    alert('erro: ' + e);
});

É simples assim, a promessa resolve ou rejeita sua solicitação.

O que é um Observable?

[wp_ad_camp_3]

Observables fornecem suporte para a transmissão de mensagens entre editores e assinantes em seu aplicativo. Os observables ​​oferecem benefícios significativos em relação a outras técnicas para manipulação de eventos, programação assíncrona e manipulação de vários valores.

Os observables ​​são declarativos – isto é, você define uma função para publicar valores, mas não é executado até que um consumidor assine a ele. O consumidor inscrito recebe notificações até que a função seja concluída ou até que elas sejam canceladas.

Um observable pode fornecer vários valores de qualquer tipo – literais, mensagens ou eventos, dependendo do contexto. A API para receber valores é a mesma, quer os valores sejam entregues de forma síncrona ou assíncrona. Como a lógica de configuração e de desmontagem são tratadas pelo observable, o código do seu aplicativo só precisa se preocupar em se inscrever para consumir valores e, quando terminar, desinscrever. Vou deixar abaixo o exemplo de um Observable para escutar mudança da posição geográfica do usuário usando a API geolocation.

// Cria um Observable que ouve as atualizações de geolocalização
// quando um consumidor se inscreve
const locations = new Observable((observer) => {
	// Obtenha os próximos retornos de chamada e erros. Estes serão passados quando
	// o consumidor assina.
	const {
		next,
		error
	} = observer;
	let watchId;

	// a API geolocation checa valores para publicar.
	if ('geolocation' in navigator) {
		watchId = navigator.geolocation.watchPosition(next, error);
	} else {
		error('Geolocation not available');
	}

	// Quando o consumidor cancelar a assinatura, limpe os dados prontos para a próxima assinatura.
	return {
		unsubscribe() {
			navigator.geolocation.clearWatch(watchId);
		}
	};
});

// Chame o subscribe() para ouvir as atualizações.
const locationsSubscription = locations.subscribe({
	next(position) {
		console.log('Posição Atual: ', position);
	},
	error(msg) {
		console.log('Erro ao recuperar localização: ', msg);
	}
});

// Para de ouvir após 10 segundos
setTimeout(() => {
	locationsSubscription.unsubscribe();
}, 10000);

Requisições HTTP

[wp_ad_camp_2]

Agora que já vimos sobre promises e sobre os observables, vamos imaginar eles aplicados em uma requisição HTTP. Saindo um pouquinho da caixa, requisições HTTP são utilizadas constantemente (obvio né? kkk) elas além de resolver e rejeitar tem uma série de fatores que podem acontecer em seu ambiente externo ou interno que necessitam de tratativas especiais.

Requisições HTTP podem falhar por problemas de conexão, requisições HTTP podem nos informar sobre seu progresso, requisições HTTP podem ser canceladas…

Sua requisição falhou, e agora?

Podemos dizer que é comum termos requisições que não são concluídas, quando isso ocorre geralmente mostramos um erro para o usuário ou então implementamos algum método para tentar novamente. Com o observable podemos tratar isso facilmente com o operador “retry”, com ele podemos especificar quantas vezes nosso observable pode tentar refazer a requisição. Legal né?

O usuário saiu da tela antes da requisição se completar, e agora?

É muito comum o usuário cancelar uma ação, seja por erro dele, ou por demora em obter a resposta, ele pode e com certeza ele vai sair da sua operação para tentar novamente. Como você iria cancelar essa operação caso esteja fazendo uso de uma promise? Para isso você teria que fazer alguma implementação externa ou usar algum framework para facilitar a operação. Já com observable você pode simplesmente chamar o operador “unsubscribe” e pronto, você já não está mais esperando uma resposta.

Conclusão

[wp_ad_camp_1]

O observable tem mais vantagens que as promises, e você pode definir quando deseja usar cada um dos recursos. Sobre o observable sua grande vantagem está nos “poderes” que ele nos dá com seus operadores. No exemplo acima ao cancelar um request quando o usuário sai da dela, poupou processamento e também conseguimos tratar possíveis problemas de falha, como o retry na perda de conexão. Já com promises é possível cancelar, e fazer os retry mas não usando sua definição e sim usando meios/frameworks alternativos.

Fontes:

1. Entendendo RxJS Observable com Angular
2. Promises em Javascript
3. Angular – Observables

The post Promise ou Observable? Quais as diferenças? appeared first on Hiago Silva Souza.