A espinha dorsal é ...
... uma biblioteca muito pequena de componentes que você pode usar para ajudar a organizar seu código. Ele vem empacotado como um único arquivo JavaScript. Excluindo comentários, ele possui menos de 1000 linhas de JavaScript real. É sensatamente escrito e você pode ler a coisa toda em algumas horas.
É uma biblioteca front-end, você a inclui em sua página da web com uma tag de script. Isso afeta apenas o navegador e fala pouco sobre o servidor, exceto que, idealmente, deve expor uma API tranquila.
Se você possui uma API, o Backbone possui alguns recursos úteis que o ajudarão a conversar com ela, mas você pode usar o Backbone para adicionar interatividade a qualquer página HTML estática.
A espinha dorsal é para ...
... adicionando estrutura ao JavaScript.
Como o JavaScript não impõe nenhum padrão específico, os aplicativos JavaScript podem se tornar muito confusos muito rapidamente. Qualquer pessoa que tenha criado algo além do trivial no JavaScript provavelmente terá dúvidas como:
- Onde vou armazenar meus dados?
- Onde colocarei minhas funções?
- Como unirei minhas funções para que sejam chamadas de maneira sensata e não se transformem em espaguete?
- Como posso tornar esse código sustentável por diferentes desenvolvedores?
O Backbone procura responder a essas perguntas fornecendo a você:
- Modelos e coleções para ajudá-lo a representar dados e coleções de dados.
- Visualizações, para ajudar você a atualizar seu DOM quando seus dados forem alterados.
- Um sistema de eventos para que os componentes possam ouvir um ao outro. Isso mantém seus componentes desacoplados e evita spaghettification.
- Um conjunto mínimo de convenções sensatas, para que os desenvolvedores possam trabalhar juntos na mesma base de código.
Chamamos isso de padrão MV *. Modelos, vistas e extras opcionais.
A espinha dorsal é leve
Apesar das aparências iniciais, o Backbone é fantasticamente leve, quase não faz nada. O que ele faz é muito útil.
Ele fornece um conjunto de pequenos objetos que você pode criar e que podem emitir eventos e ouvir um ao outro. Você pode criar um pequeno objeto para representar um comentário, por exemplo, e depois um pequeno objeto commentView para representar a exibição do comentário em um local específico no navegador.
Você pode dizer ao commentView para ouvir o comentário e redesenhar-se quando o comentário mudar. Mesmo se você tiver o mesmo comentário exibido em vários lugares da sua página, todas essas visualizações poderão ouvir o mesmo modelo de comentário e permanecer sincronizadas.
Essa maneira de compor o código ajuda a impedir que você se enrole, mesmo que sua base de código se torne muito grande com muitas interações.
Modelos
Ao iniciar, é comum armazenar seus dados em uma variável global ou no DOM como atributos de dados . Ambos têm problemas. Variáveis globais podem entrar em conflito umas com as outras e geralmente são de má forma. Os atributos de dados armazenados no DOM podem ser apenas cadeias de caracteres, você precisará analisá-las novamente. É difícil armazenar coisas como matrizes, datas ou objetos e analisar seus dados de forma estruturada.
Os atributos de dados são assim:
<p data-username="derek" data-age="42"></p>
O backbone resolve isso fornecendo um objeto Model para representar seus dados e métodos associados . Digamos que você tenha uma lista de tarefas, você teria um modelo representando cada item dessa lista.
Quando seu modelo é atualizado, ele dispara um evento. Você pode ter uma visão vinculada a esse objeto específico. A visualização ouve eventos de alteração de modelo e se processa novamente.
Visualizações
O backbone fornece os objetos View que falam com o DOM. Todas as funções que manipulam o DOM ou escutam eventos DOM vão aqui.
Uma Visualização geralmente implementa uma função de renderização que redesenha toda a visualização, ou possivelmente parte dela. Não há obrigação de implementar uma função de renderização, mas é uma convenção comum.
Cada visualização é vinculada a uma parte específica do DOM; portanto, você pode ter um searchFormView, que apenas escuta o formulário de pesquisa, e um shoppingCartView, que exibe apenas o carrinho de compras.
As vistas também costumam estar vinculadas a modelos ou coleções específicos. Quando o modelo é atualizado, ele dispara um evento que a exibição ouve. A visualização pode chamar de render para se redesenhar.
Da mesma forma, quando você digita em um formulário, sua visualização pode atualizar um objeto de modelo. Todas as outras visualizações que ouvem esse modelo chamarão sua própria função de renderização.
Isso nos dá uma separação clara de preocupações que mantém nosso código limpo e arrumado.
A função de renderização
Você pode implementar sua função de renderização da maneira que achar melhor. Você pode colocar algum jQuery aqui para atualizar o DOM manualmente.
Você também pode compilar um modelo e usá-lo. Um modelo é apenas uma string com pontos de inserção. Você o passa para uma função de compilação junto com um objeto JSON e recebe de volta uma string compilada que pode ser inserida no seu DOM.
Colecções
Você também tem acesso a coleções que armazenam listas de modelos; portanto, um todoCollection seria uma lista de modelos de tarefas. Quando uma coleção ganha ou perde um modelo, muda sua ordem ou um modelo em uma coleção é atualizado, a coleção inteira aciona um evento.
Uma exibição pode ouvir uma coleção e se atualizar sempre que a coleção for atualizada.
Você pode adicionar métodos de classificação e filtro à sua coleção e fazer com que ela se classifique automaticamente, por exemplo.
E Eventos para Amarrar Tudo Juntos
Tanto quanto possível, os componentes do aplicativo são dissociados. Eles se comunicam usando eventos, para que um shoppingCartView possa ouvir uma coleção shoppingCart e se redesenhar quando o carrinho for adicionado.
shoppingCartView.listenTo(shoppingCart, "add", shoppingCartView.render);
Obviamente, outros objetos também podem estar ouvindo o ShoppingCart e podem fazer outras coisas, como atualizar um total ou salvar o estado no armazenamento local.
- As visualizações ouvem Modelos e renderizam quando o modelo é alterado.
- As visualizações ouvem coleções e renderizam uma lista (ou uma grade, um mapa etc.) quando um item da coleção é alterado.
- Os modelos ouvem Views para que possam mudar de estado, talvez quando um formulário é editado.
Separar seus objetos assim e se comunicar usando eventos significa que você nunca se enredará em nós, e é fácil adicionar novos componentes e comportamento. Seus novos componentes apenas precisam ouvir os outros objetos que já estão no sistema.
Convenções
O código escrito para o Backbone segue um conjunto amplo de convenções. O código DOM pertence a uma exibição. O código da coleção pertence a uma coleção. A lógica de negócios entra em um modelo. Outro desenvolvedor que pegar sua base de código poderá entrar em ação.
Resumindo
O backbone é uma biblioteca leve que empresta estrutura ao seu código. Os componentes são dissociados e se comunicam por meio de eventos, para que você não fique confuso. Você pode estender sua base de código facilmente, simplesmente criando um novo objeto e fazendo com que ele escute adequadamente os objetos existentes. Seu código será mais limpo, mais agradável e mais sustentável.
Meu livrinho
Eu gostei tanto do Backbone que escrevi um pequeno livro de introdução sobre isso. Você pode lê-lo online aqui: http://nicholasjohnson.com/backbone-book/
Também dividi o material em um pequeno curso on-line, que você pode encontrar aqui: http://www.forwardadvance.com/course/backbone . Você pode concluir o curso em cerca de um dia.