O evento que vamos utilizar é o “onBeforeUnload”.

Este evento é sempre invocado quando o usuário tenta sair da página atual, mas, ele por si só não resolve o problema, para resolvermos, precisamos dizer ao browser o que fazer quando isto acontecer.

Um exemplo de código seria:

$('body').on('click', function(){
    window.onbeforeunload = function(){
        return 'Os dados do formulário não foram salvos, deseja permanecer nesta página?';
    };
});

Desta forma, quando o evento foi setado, ao mudar de página ou qualquer ação que faça ele fechar a página, será enviada uma mensagem ao browser, como o exemplo abaixo:

Então, uma forma de fazer isto em um formulário seria, quando carregar a página salvar o estado do formulário para comparar, caso ele tome alguma ação que saia da página, sendo quê, temos que desconsiderar o “SUBMIT”, pois neste caso a ação é desejada.

Exemplo de código:

$( function(){

	var init_form = $('#id_form').serialize();
	// Result example: "name=&email=&message="

	// Cancel event onbeforeunload when Submit form
	$(':submit').click(function() {
		window.onbeforeunload = null;
	});
	
	window.onbeforeunload = function(){
		var check_form = $('#id_form').serialize();
		
		if( check_form === init_form )
		return null;
		
		return 'Os dados do formulário não foram salvos, deseja permanecer nesta página?';
	};
});

Conclusão:

Isto pode ser utilizado para diversas formas, avisar o preenchimento de um formulário não enviado, salvar o rascunho de um e-mail/mensagem, dar um desconto em um produto caso o usuário feche a tela de concluir a compra e outras milhares de formas que vocês imaginarem.

Dicas e sugestões:
Deixem nos comentários.

A forma de utilizar é muito simples, basta adicionar o arquivo css animation e inserir a classe ao objeto que deve ser animado, exemplo:

Inserção do CSS das animações:

<link rel="stylesheet" href="css/animations.css">

Adicionando classe ao objeto que será animado:

<div id="object" class="slideUp">

Abaixo você pode conferir o resultado das animações, clique nos links para ver os diversos efeitos:

CSS:

Javascript:

Html:

Para fazer com que a animação seja ativada quando o usuário ver o item, você deve colocar este código em Javascript e css, sendo que, deve ser carregado o Jquery antes:

CSS:

#object{
	background-color: #fe5652;
	visibility: hidden;
}

JS:

<script>
	$(window).scroll(function() {
		$('#animatedElement').each(function(){
		var imagePos = $(this).offset().top;

		var topOfWindow = $(window).scrollTop();
			if (imagePos < topOfWindow+400) {
				$(this).addClass("slideUp");
			}
		});
	});
</script>

Para ver o exemplo, acessem este LINK.

Esperamos que tenham gostado e aprendido, dúvidas e sugestões deixem nos comentários, isto incentiva-nos a sempre compartilhar conhecimento cada vez mais!

$(function () {
    var selections = [];
    $(".niners").click(function () {
        selections.push(this.prop ("name"));
    });
});

A equipe da Turbosite repassamos esse conhecimento com a postagem abaixo.

O que é um closure?

Um closure é uma função interior que tem acesso a variáveis de uma função exterior – cadeia de escopo. O closure tem três cadeias de escopo: o seu próprio escopo; escopo externo, tendo acesso as variáveis da função exterior; e tem acesso as variáveis globais.

A função interior tem acesso não somente as variáveis da função exterior, mas também aos parâmetros dela. Note que a função interior não pode chamar o objeto(arguments) da função exterior, entretanto, pode chamar parâmetros da função externa diretamente.

Você cria um closure adicionando uma função dentro de outra função.

function showName (firstName, lastName) {
    var nameIntro = "Your name is ";
 
    //esta função interior tem acesso as variáveis da função exterior, incluindo os parâmetros
    function makeFullName () {
        return nameIntro + firstName + " " + lastName;
    }
 
    return makeFullName ();
}
 
showName ("Michael", "Jackson"); //Your name is Michael Jackson

Regra dos Closures e Efeitos Colaterais

1. Closures tem acesso a variável das funções exteriores mesmo após o retorno da função exterior

Uma da mais importante e delicada característica dos closures é que a função interior continua tendo acesso as variáveis da função exterior mesmo após ela ter retornado.  Quando funções no JavaScript executam, elas usam a mesma cadeia de escopo que estava em vigor quando foram criadas. Isso significa que mesmo depois da função exterior retornar, a função interior continua tendo acesso as variáveis da função exterior. Portanto, você pode chamar a função interior depois em seu programa. Este exemplo demonstra isso:

function celebrityName (firstName) {
    var nameIntro = "This celebrity is ";
 
    //essa função interior tem acesso as variáveis da função exterior, incluindo os parâmetros
    function lastName (theLastName) {
        return nameIntro + firstName + " " + theLastName;
    }
    return lastName;
}
 
var mjName = celebrityName ("Michael");
//Nesta conjuntura, a função exterior celebrityName foi retornada
 
//O closure (lastName) é chamado aqui depois da função exterior ter retornado acima
//Sim, o closure continua tendo acesso as variáveis da função exterior e parâmetros
mjName ("Jackson"); //This celebrity is Michael Jackson

2. Closures armazenam referências para as variáveis da função exterior

Eles não armazenam o valor real. Closures ficam mais interessantes quando o valor da variável da função exterior muda antes que o closure seja chamado, e esta poderosa característica pode ser aproveitada de formas criativas, como este exemplo de variável privada primeiramente demonstrada por Douglas Crockford:

function celebrityID () {
    var celebrityID = 999;
    //Nós retornamos um objeto com algumas funções interiores
    //Todas as funções interiores têm acesso as variáveis'da função exterior
    return {
        getID: function () {
            //Esta função interior vai retornar a variável celebrityID ATUALIZADA
            return celebrityID;
        },
        setID: function (theNewId) {
            //Esta função interior vai mudar a variável da função exterior a qualquer hora
            celebrityID = theNewId;
        }
    }
}
 
var mjID = celebrityID (); //Nesta atual conjuntura, a função exterior celebrityID já retornou
mjID.getID(); //999
mjID.setID(567); //Muda a variável da função exterior
mjID.getID(); //567 - retorna o valor atualizado da variável celebrityID

3. Closures que deram errado

Por causa dos closures terem acesso ao valor atualizado das variáveis das funções exteriores, eles podem também conduzir a erros quando a variável da função exterior muda com um loop for. Assim:

//Este exemplo é explicado em detalhe abaixo (logo após este bloco de código)
function celebrityIDCreator (theCelebrities) {
    var i;
    var uniqueID = 100;
    for (i = 0; i < theCelebrities.length; i += 1) {
        theCelebrities[i]["id"] = function () {
            return uniqueID + i;
        }
    }
 
    return theCelebrities;
}
 
var actionCelebs = [{name:"Stallone", id:0}, {name:"Cruise", id:0}, {name:"Willis", id:0}];
 
var createIdForActionCelebs = celebrityIDCreator(actionCelebs);
 
var stalloneID = createIdForActionCelebs[0];
 
console.log(stalloneID.id()); //103

No exemplo anterior, quando a função anônima é chamada, o valor de i é 3 (a contagem do array e então seus incrementos). O número 3 foi adicionado ao uniqueID para criar 103 para TODOS os celebrityID. Então cada posição no array retornado obteve o id = 103, ao invés do valor pretendido 100, 101, 102.

A razão para isso acontecer foi porque, assim como nós discutimos no exemplo anterior, o closure (função anônima neste exemplo) teve acesso a variável da função exemplo por referência, não por valor. Então, igual ao exemplo anteriormente mostrado onde nós acessamos o valor atualizado da variável com o closure, neste exemplo, similarmente acessamos a variável i quando ela foi alterada, depois que a função exterior rodou o loop for inteiro e retornou o último valor, que foi 103.

Para consertar este efeito colateral (bug) nos closures, você pode usar uma Expressão de Função Imediatamente Invocada (IIFE – Immediately Invoked Function Expression), como no exemplo seguinte:

function celebrityIDCreator (theCelebrities) {
    var i;
    var uniqueID = 100;
    for (i = 0; i < theCelebrities.length; i += 1) {
        theCelebrities[i]["id"] = function (j) { //a variável paramétrica j é o i passado na invocação da IIFE
            return function () {
                return uniqueID + j;
                //cada iteração do loop for passa no valor atual de i dentro desta IIFE e salva o valor correto no array
            } () //Adicionando () no fim da função, nós estamos executando-a imediatamente e retornando somente o valor de uniqueID + j, ao invés de retornar uma função
        } (i); //invocando imediatamente a função passando a variável i como um parâmetro
    }
    return theCelebrities;
}
 
var actionCelebs = [{name: "Stallone", id:0}, {name: "Cruise", id:0}, {name: "Willis", id:0}];
 
var createIdForActionCelebs = celebrityIDCreator (actionCelebs);
 
var stalloneID = createIdForActionCelebs [0];
console.log(stalloneID.id); //100
 
var cruiseID = createIdForActionCelebs [1];
console.log(cruiseID.id); //101

JavaScript puro ou Vanilla JavaScript (felizmente) está voltando. E com força. Mas, quando você decide continuar nos estudos e começa a inspecionar códigos alheios, inevitavelmente você se depara com algo como:

(function (window, document, undefined) {
    //
})(window, document);

Frequentemente desenvolvedores descobrindo (ou redescobrindo) o JavaScript puro se perguntam sobre IIFE (Expressão de Função Imediatamente Invocada ou Immediately-Invoked Function Expression), frequentemente apresentado da seguinte maneira:

(function (window, document, undefined) {
    //
})(window, document);

Escopo privado em IIFE

JavaScript tem maneiras interessantes de trabalhar com escopo de função; então, primeiramente essa expressão cria um “âmbito privado” (private scope). Por exemplo:

(function (window, document, undefined) {
    var name = 'Foo';
})(window, document);
console.log(name); // "name" não definido, está em um escopo diferente

Como funciona IIFE

Uma função normal se parece com isso:

var logMyName = function (name) {
    console.log(name);
};
logMyName('Foo');

Ela é chamada (invoke) quando necessário, por escolha do programador, em qualquer ponto do código em que se queira e/ou seja possível.

A razão pela qual essa IIFE em JavaScript foi criada, foi para ser uma expressão de função imediatamente invocada, o que significa que elas são imediatamente chamadas em tempo de execução – também, não é possível chamá-la novamente, já que elas só rodam uma vez, mais ou menos assim:

var logMyName = (function (name) {
    console.log(name); // Todd
})('Todd');

(function () {
})();

O par de parênteses extra é necessário. Isso não funciona:

function () {
}();

!function () {
}();

+function () {
}();
 
-function () {
}();
 
~function () {
}();

Mas não é preciso se forçar a decorar isso para usar a todo momento para fazer uma IIFE.

Argumentos da IIFE

Agora que foi explicado como isso funciona, passemos para os argumento da IIFE:

(function (window) {
})(window);

Então, o que mais é possível fazer? Passar tudo o que for necessário! Por exemplo, passar o Objeto document:

(function (window, document) {
    // é possível usar "window" e "document" normalmente
})(window, document);

A resolução de variáveis ​​locais é mais rápida que a de variáveis ​​globais, mas esta está numa escala enorme e dificilmente alguém vai perceber o aumento da velocidade – mas vale a pena considerar se há muitas referências a globais!

E sobre o undefined?

Em ECMAScript 3, undefined é mutável. Isso significa que o valor poderia ser transferido com, por exemplo, undefined = true;…! Felizmente, no ECMAScript 5 em modo estrito ('use strict';) o parser lança um erro quando se depara com isso. Antes disso, começou-se a proteger uma IIFE da maneira já vista:

(function (window, document) {
    // é possível usar "window" e "document" normalmente
})(window, document);

(function (window, document, undefined) {
})(window, document);

undefined = true;
(function (window, document, undefined) {
    // "undefined" é uma variável local undefined
})(window, document);

Minificando

Ao minificar as variáveis ​​locais é que a grandiosidade do padrão IIFE realmente pode ser vista. Nomes de variáveis ​​locais não são realmente necessários se estas foram passadas dessa maneira​​, então, é possível dar o nome que quiser para elas.

Por exemplo, mudar disso:

(function (window, document, undefined) {
    console.log(window); // Object window
})(window, document);

Pra isso:

(function (a, b, c) {
    console.log(a); // Object window
})(window, document);

Imagine todas as referências a bibliotecas e window e document minificadas. Claro que você não precisa parar por aí; é possível passar jQuery, também, ou qualquer outra coisa que esteja disponível dentro no escopo léxico:

(function ($, window, document, undefined) {
    // use $ para se referir à jQuery
    // $(document).addClass('test');
})(jQuery, window, document);
 
(function (a, b, c, d) {
    // Se torna
    // a(c).addClass('test');
})(jQuery, window, document);

Isso também significa que você não precisa chamar jQuery.noConflict(); ou qualquer coisa como $ é atribuído localmente ao módulo. Aprender como escopos e variáveis ​​globais/locais funcionam ajuda ainda mais.

Passar o código por um bom minificador certamente garantirá a renomeação de undefined para c (por exemplo, e apenas se for usado). É importante atentar para o fato de que o nome undefined é irrelevante; só é preciso saber que o Objeto referenciado é indefinido (undefined) e, como undefined não tem qualquer significado especial – undefined é o valor que o JavaScript dá às coisas que são declaradas mas não têm nenhum valor (nem em IIFE).

Ambientes globais não-navegador

Devido a algumas tecnologias, Node.js, o navegador não é sempre o Objeto global, o que pode ser realmente problemático se você está tentando criar uma IIFE para funcionar em múltiplos ambientes. Por esta razão, há determinadas “alternativas”, como isso:

(function (root) {
})(this);

Em um navegador, o ambiente global this se refere ao Objeto window, de modo que não é preciso passar em window, é sempre possível reduzir para this.

Alguns preferem o nome root, já que ele pode se referir tanto a ambientes não-navegador, quanto à raiz do browser.

Se você estiver interessado em uma solução universal (muito útil para ser usada para a criação de módulos em projetos de código aberto) é o UMD (Universal Module Definition):

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        define(factory);
    } else if (typeof exports === 'object') {
        module.exports = factory;
    } else {
        root.MYMODULE = factory();
    }
})(this, function () {
    // 
});

A função está sendo invocado com outra função sendo passada para ela. É possível, então, atribuí-la ao ambiente relevante “de dentro”. No navegador, root.MYMODULE = factory(); é o módulo IIFE; em qualquer outro ambiente (como Node.js), será usado module.exports ou requireJS se define === 'function' && define.amd resolver como true.

Conclusão

Como foi visto, usar IIFE (Expressão de Função Imediatamente Invocada ou Immediately-Invoked Function Expression) é extramente benéfico. Além de ajudar na performance, por permitir que não seja preciso lookups no código a procura de variáveis globais, permite que seu código possa ficar “isolado”, protegendo o escopo de uma porção de código ou módulo do ambiente em que foi colocado.

O fato de diversos frameworks e bibliotecas JavaScript de renome como jQuery, Backbone.js, Modernizr e outros usarem IIFE já é bastante significativo. Use código de qualidade para fazer código de qualidade.

Namespacing em JavaScript pode ser considerado algo um pouco nebuloso no começo, mas a organização (e, de certa forma, proteção) de seu código é algo essencial, que deve ser encarado com muita seriedade e feito com bastante atenção. JavaScript não possui uma construção formal de namespace, então é preciso saber como “simular” namespaces para que se possa desfrutar das vantagens que eles oferecem.

Variáveis ​​globais devem ser reservadas a objetos que têm relevância para todo o sistema e estas devem ser nomeadas para evitar ambiguidades e minimizar o risco de colisões de nomes. Na prática, isso significa que você deve evitar a criação de objetos globais a menos que eles sejam absolutamente necessários. Mas você já sabia disso, certo?!

Você deve evitar a criação de objetos globais a menos que eles sejam absolutamente necessários.

Então, o que você faz sobre isso? A “sabedoria popular” mostra que a melhor estratégia de redução de risco é criar um pequeno número de objetos globais que servirão como namespaces de facto para módulos subjacentes e subsistemas. A seguir, várias abordagens para namespacing em JavaScript interessantes, que você pode usar em seus projetos imediatamente.

Namespacing Estático (Static Namespacing)

O termo “namespacing estático” está sendo usado como um termo genérico para soluções em que a denominação “namespace” consta numa codificação, propriamente dita. É verdade, você pode reatribuir de um namespace para outro, mas o novo namespace vai referenciar os mesmos objetos como se fossem os antigos.

Atribuição Direta (Direct Assignment)

Essa é a abordagem mais básica. Exige mais código, mas é segura e inequívoca.

var myApp = {}
 
myApp.id = 0;
 
myApp.next = function() {
    return myApp.id++;  
}
 
myApp.reset = function() {
    myApp.id = 0;   
}
 
window.console && console.log(
    myApp.next(),
    myApp.next(),
    myApp.reset(),
    myApp.next()
); // 0, 1, undefined, 0

Você poderia tornar a manutenção futura um pouco mais fácil usando this para fazer referência a propriedades irmãs, mas isso é um pouco arriscado, já que não há nada que impeça suas funções no namespace de serem reatribuídas:

var myApp = {}
 
myApp.id = 0;
 
myApp.next = function() {
    return this.id++;   
}
 
myApp.reset = function() {
    this.id = 0;    
}
 
myApp.next(); // 0
myApp.next(); // 1
var getNextId = myApp.next;
getNextId(); // NaN whoops!

Notação de Objeto Literal (Object Literal Notation)

Nesta abordagem, é preciso fazer referência ao nome de namespace apenas uma vez, então, caso seja preciso alterar o nome mais tarde, isso é um pouco mais fácil de se conseguir (supondo que você não tenha referenciado o namespace muitas vezes). Há, ainda, o perigo de que o valor de this possa ser uma surpresa – mas é um pouco mais seguro assumir que os objetos definidos dentro de uma construção de objeto literal não serão reatribuídos.

var myApp = {
    id: 0,
 
    next: function() {
        return this.id++;   
    },
 
    reset: function() {
        this.id = 0;    
    }
}
 
window.console && console.log(
    myApp.next(),
    myApp.next(),
    myApp.reset(),
    myApp.next()
) // 0, 1, undefined, 0

Padrão de Módulo (Module Pattern)

Hoje em dia é bastante comum encontrar por aí o Padrão de Módulo (Module Pattern) em código JavaScript. A lógica é protegida do escopo global por uma função wrapper (geralmente numa IIFE) que retorna um objeto que representa a interface pública do módulo. Por imediatamente invocar a função e atribuir o resultado a uma variável de namespace, a API do módulo é “trancada” nesse namespace.

Além disso, todas as variáveis ​​não incluídas no valor de retorno permanecerão privadas, visíveis apenas para as funções públicas que lhes referenciam.

var myApp = (function() {
 
    var id = 0;
 
    return {
        next: function() {
            return id++;    
        },
 
        reset: function() {
            id = 0;     
        }
    };  
})();   
 
window.console && console.log(
    myApp.next(),
    myApp.next(),
    myApp.reset(),
    myApp.next()
) // 0, 1, undefined, 0

Namespacing Dinâmico (Dynamic Namespacing)

Esta seção também poderia muito bem ser chamada de “injeção de namespace” (ou namespace injection). O namespace é representado por um proxy que é referenciado diretamente dentro do wrapper da função – o que significa que não é mais preciso agrupar valores para o return no namespace. Isso faz com que a definição de namespace seja mais flexível e torna muito fácil ter várias instâncias independentes de um módulo existente em namespaces separados (ou até mesmo no contexto global).

Passando argumento de namespace

Aqui o namespace é simplesmente passado como um argumento de uma Expressão de Função Imediatamente Invocada. A variável id é privada porque não é atribuída ao contexto.

var myApp = {};
(function(context) { 
    var id = 0;
 
    context.next = function() {
        return id++;    
    };
 
    context.reset = function() {
        id = 0;     
    }
})(myApp);  
 
window.console && console.log(
    myApp.next(),
    myApp.next(),
    myApp.reset(),
    myApp.next()
) // 0, 1, undefined, 0

É possível até mesmo definir o contexto para o objeto global – com a mudança de uma palavra! Este é um grande trunfo para os fornecedores da bibliotecas (vendors), que podem envolver suas features numa IIFE e permitir que o programador decida se elas devem ser globais ou não (John Resig foi um dos primeiros a adotar esse conceito quando escreveu a jQuery).

var myApp = {};
(function(context) { 
    var id = 0;
 
    context.next = function() {
        return id++;    
    };
 
    context.reset = function() {
        id = 0;     
    }
})(this);   
 
window.console && console.log(
    next(),
    next(),
    reset(),
    next()
) // 0, 1, undefined, 0

this como proxy de namespace

O artigo “My Favorite JavaScript Design Pattern” aparentemente foi mal compreendido por muitos que pensaram que ele poderia simplesmente recorrer ao Module Pattern. O artigo mostra várias técnicas (o que provavelmente contribuiu para essa confusão), mas, em essência, é muito interessante e dá ensejo ao desenvolvimento de muita coisa boa relacionada a namespacing.

A beleza do padrão é que ele simplesmente usa a linguagem como foi projetada – nada mais, nada menos, sem truques, sem firulas. Além disso, já que o namespace é injetado através da palavra-chave this (que é estática dentro de um determinado contexto de execução), ele não pode ser acidentalmente modificado.

var myApp = {};
(function() {
    var id = 0;
 
    this.next = function() {
        return id++;    
    };
 
    this.reset = function() {
        id = 0;     
    }
}).apply(myApp);    
 
window.console && console.log(
    myApp.next(),
    myApp.next(),
    myApp.reset(),
    myApp.next()
); // 0, 1, undefined, 0

Ainda melhor, a API de apply (e call) provê separação natural entre contexto e argumentos; então, fica simples passar argumentos adicionais para o criador do módulo.

O exemplo a seguir demonstra isso e também mostra como executar o módulo de forma independente através de múltiplos namespaces:

var subsys1 = {}, subsys2 = {};
 
var nextIdMod = function(startId) {
    var id = startId || 0;
 
    this.next = function() {
        return id++;    
    };
 
    this.reset = function() {
        id = 0;     
    }
};
 
nextIdMod.call(subsys1);    
nextIdMod.call(subsys2,1000);   
 
window.console && console.log(
    subsys1.next(),
    subsys1.next(),
    subsys2.next(),
    subsys1.reset(),
    subsys2.next(),
    subsys1.next()
) // 0, 1, 1000, undefined, 1001, 0

E, se for preciso um gerador global de id:

nextIdMod();    
 
window.console && console.log(
    next(),
    next(),
    reset(),
    next()
) // 0, 1, undefined, 0

Mas essa ferramenta de gerar de ids mostrada como exemplo não faz jus a todo o potencial desse padrão. Envolvendo uma biblioteca inteira e usando a palavra-chave this como um suporte para o namespace, é fácil executar a biblioteca em qualquer contexto que se queira (incluindo o contexto global).

// Código de biblioteca
var protoQueryMooJo = function() {  
    // [...]
}
 
// Seu código
var thirdParty = {};
protoQueryMooJo.apply(thirdParty);

Considerações finais sobre Namespacing em JavaScript

É uma prática comum tentar evitar namespaces aninhados. Eles são mais difíceis de seguir (para ambos, humanos e computadores) e vão encher seu código de confusão desnecessária. Como Peter Michaux aponta, namespaces aninhados podem ser um legado de desenvolvedores Java nostálgicos tentando recriar aquelas cadeias longas de pacotes que eles conheciam e amavam…

É possível “propagar” um único namespace através de diversos arquivos.js (embora apenas por injeção de namespace ou atribuição direta de cada variável), contudo, é preciso ter cuidado com as dependências. Além disso, “ligar” um namespace a um arquivo pode ajudar o leitor a navegar mais facilmente pelo código.

Uma vez que JavaScript não possui uma construção formal de namespace, isso abre margem para vários tipos de soluções criativas para resolver a questão. Este artigo mostrou apenas algumas delas e, evidentemente, as melhores podem não terem sido abordadas, dada a vasta contribuição da comunidade a cada dia.

De qualquer forma, estas são algumas das mais conhecidas técnicas para namespacing em JavaScript e, garantimos, estudando um pouco além e sabendo aplicar corretamente em seus projetos, certamente você terá um incremento de qualidade de código considerável!