Arquitetura de backbone com pacotes

Question

Estou tentando escolher uma arquitetura de backbone que melhor atenda ao meu aplicativo.

Estou construindo uma aplicação grande que será composta por diversos componentes ou "pacotes" que podem ser habilitados ou desabilitados.

Para simplificar, digamos que meu aplicativo de página única seja uma galeria que possui vários componentes, como uma galeria de fotos e uma galeria de vídeos.

• Qualquer "instalação" do meu aplicativo pode escolher quais componentes ("pacotes") carregar - vídeo, foto ou ambos
• O vídeo e a galeria de fotos possuem alguns códigos comuns e classes abstratas.
• Quero que cada instalação carregue apenas os componentes necessários, em um único arquivo (otimizado) - o que significa que se uma instalação usar apenas a galeria de fotos, ela não deverá carregar a galeria de vídeos - para economizar recursos.

Analisei várias soluções - como requireJs com seu otimizador r, marionette e Lumbar, mas cada uma tem algumas desvantagens:* Requerjs com otimizador ou marionete - não consigo ver como posso agrupar arquivos em pacotes * lombar - parece que ele resolve a maior parte do meu problema, mas mal consegui encontrar qualquer documentação ou suporte comunitário (mal mencionado aqui no Stackoverflow) Portanto, não sei se posso confiar nele para um grande projeto de software.

Answer 1

Eu decidi que lombar é o caminho a percorrer.Parece que resolve todas as minhas das minhas necessidades de carregar apenas pacotes "habilitados", usando seu carregamento de módulo baseado em rota, conforme descrito aqui: http://addyosmani.github.io/backbone-fundamentais/#Route-based-módulo-carregando Ao declarar cada módulo no arquivo de configuração Lombar.json, ele criará um arquivo JS separado e combinado para cada módulo definido - e carregará o módulo somente se sua rota foi correspondida. Você pode ver como fazer isso em tórax-semente: https://github.com/walmartlabs/torax-seed/blob/master/Readme.md

Answer 2

Bem, isso certamente é subjetivo e você tem muitas opções, mas talvez algumas informações básicas sobre algumas de suas escolhas possam ajudar e eu vou me arriscar e recomendar Chaplin.

Marionette é bom por vários motivos, incluindo o fato de ter sido desenvolvido como um projeto de código aberto no Github.Ele foi projetado para ser extremamente leve e parece que seu problema decorre de seu conjunto de recursos intencionalmente limitado.

Chaplin é uma estrutura em cima de Backbone.js biblioteca, como Marionette e várias de suas outras opções.Ambos buscam facilitar o desenvolvimento de aplicativos JavaScript de página única.Nessas aplicações, o cliente executa tarefas que normalmente eram executadas no servidor, como renderizar dados brutos em HTML.

Backbone em si foi projetado como uma biblioteca minimalista em vez de uma estrutura completa. Backbone só pode fornecer a base de uma arquitetura de aplicativo JavaScript.Ambos Marionette e Chaplin surgiu porque Backbone fornece muito pouca estrutura para aplicativos do mundo real.Eles respondem aos mesmos problemas.Portanto, há muitas semelhanças entre os dois – talvez mais do que diferenças.

Comparado à marionete, Chaplin atua mais como uma estrutura.É mais opinativo e tem convenções mais fortes em diversas áreas.Foram retiradas ideias de estruturas MVC do lado do servidor, como Ruby on Rails, que seguem o princípio da convenção sobre configuração.O objetivo de Chaplin é fornecer diretrizes comprovadas e um ambiente de desenvolvimento conveniente.CoffeeScript e POO

Chaplin é escrito em CoffeeScript, uma metalinguagem que compila em JavaScript.No entanto, as aplicações Chaplin não precisam ser escritas em CoffeeScript.No final das contas, Chaplin é apenas mais uma biblioteca JavaScript.

Usar o CoffeeScript faz parte da ideia de Chaplin de tornar o desenvolvimento de aplicativos mais fácil e robusto.CoffeeScript aplica as diretrizes do livro “JavaScript – The Good Parts” de Douglas Crockford.Assim como Marionette, Chaplin está defendendo o Modo Estrito ECMAScript 5.

Com o CoffeeScript, as declarações de classe e a herança baseada em classe são mais compactas em comparação com o recurso de extensão do Backbone.Enquanto Marionette tenta contornar superchamadas, Chaplin adota a substituição de métodos e tenta fazer com que a herança baseada em classes funcione sem problemas.Por exemplo, se você declarar manipuladores de eventos em uma classe derivada e em sua superclasse, ambos serão aplicados.Modularização usando CommonJS ou AMD

Chaplin exige que você estruture seu código JavaScript em módulos CommonJS ou AMD.Cada módulo precisa declarar suas dependências e pode exportar um valor, por exemplo, uma função construtora ou um único objeto.Em Chaplin, um arquivo normalmente contém uma classe e define um módulo.

Ao dividir seu código em módulos reutilizáveis ​​e declarar dependências de forma legível por máquina, o código pode ser carregado e empacotado automaticamente.

Usar AMD não é fácil, você precisa se familiarizar com carregadores como Require.js e otimizadores como r.js.Como alternativa, você pode usar o formato do módulo CommonJS e Brunch como processador.

Chaplin fornece uma estrutura central de aplicativo bastante fixa.Ele lida com o fluxo principal do seu aplicativo.

The Application is the root class that starts the following parts
The Router replaces Backbone.Router
The Dispatcher starts and stops controllers when a route matches
The Layout is the top-level view that observes clicks on links

Em Chaplin, existe um local central onde definir todas as rotas.Uma rota aponta para uma ação do controlador.Por exemplo, o padrão de URL /cars/:id aponta para cars#show, que é o método show do CarsController.

Um controlador é o local onde você cria modelos.Também é responsável por criar a visualização da área de conteúdo principal.Portanto, um controlador geralmente representa uma tela da interface do seu aplicativo.

A ideia principal de Chaplin são controladores descartáveis.A regra básica é:O controlador atual e todos os seus filhos (modelos, coleções, visualizações) são descartados quando outra rota corresponde.Mesmo que a rota aponte para outra ação do mesmo controlador, a instância do controlador é descartada e uma nova é criada.

Jogar objetos fora quando outra rota coincide é uma regra simples e eficaz para limpar referências.É claro que alguns objetos precisam permanecer na memória para serem reutilizados posteriormente.O Chaplin.Composer permite compartilhar modelos e visualizações de forma controlada.Você precisa marcá-los explicitamente como reutilizáveis.Se o objeto salvo não for reutilizado na próxima ação do controlador, ele será automaticamente descartado.

Em um Chaplin app, todo objeto deve ser descartável.Todos Chaplin as classes têm um método de descarte que tornará o objeto inutilizável e cortará todos os vínculos.

Uma regra bem conhecida da programação JavaScript é evitar variáveis ​​globais.Chaplin tenta impor esta melhor prática.Classes são módulos CommonJS/AMD que estão ocultos em um escopo de fechamento.Todas as instâncias devem ser privadas.Duas instâncias não devem ter referências entre si, a menos que estejam intimamente relacionadas, como uma visualização e seu modelo.

Os objetos podem se comunicar de forma desacoplada usando o padrão Publish/Subscribe.Para isso existe o Chaplin.Mediador.O mediador também pode ser usado para compartilhar instâncias selecionadas globalmente, como o objeto de usuário.Depois de criar as propriedades necessárias, o objeto mediador é lacrado para não se tornar a pia da cozinha do seu aplicativo.

Chaplin também é forte em view management.Possui regiões nomeadas em todo o aplicativo e gerenciamento de subvisualizações.Chaplin adota uma abordagem diferente ao renderizar visualizações e anexá-las ao DOM.As visualizações podem ter um sinalizador autoRender e uma opção de contêiner.Com estes habilitados, as visualizações são renderizadas na criação e são automaticamente anexadas ao DOM.Em vez de contêiner, você pode especificar a região para anexar a visualização a uma região registrada anteriormente.

Em Chaplin além das regiões de todo o aplicativo, não há classes de abstração como Marionette.Layout e Marionette.Region.Em um aplicativo Marionette, você normalmente cria vários Layouts e Regiões aninhados.Em um aplicativo Chaplin, você tem menos regiões principais e aninha visualizações diretamente dentro delas.É claro que você pode criar visualizações reutilizáveis ​​que se comportem como Marionette.Layout, por exemplo, um ThreePaneView.