AngularJS: estruturando um aplicativo da web com vários aplicativos ng

A blogosfera possui vários artigos sobre o tópico das diretrizes de estruturação do aplicativo AngularJS, como estas (e outras):

• http://www.johnpapa.net/angular-app-structuring-guidelines/
• http://codingsmackdown.tv/blog/2013/04/19/angularjs-modules-for-great-justice/
• http://danorlando.com/angularjs-architecture-understanding-modules/
• http://henriquat.re/modularizing-angularjs/modularizing-angular-applications/modularizing-angular-applications.html

No entanto, um cenário que ainda não encontrei para obter diretrizes e práticas recomendadas é o caso em que você tem um aplicativo da Web grande contendo vários aplicativos "mini-spa" e os aplicativos mini-spa compartilham uma certa quantidade de código.

Não estou me referindo ao caso de tentar ter várias ng-appdeclarações na mesma página; em vez disso, quero dizer seções diferentes de um site grande que possuem sua própria ng-appdeclaração exclusiva .

Como Scott Allen escreve em seu blog OdeToCode :

Um cenário que não achei muito bem resolvido é o cenário em que vários aplicativos existem no mesmo aplicativo Web maior e exigem algum código compartilhado no cliente.

Existem abordagens recomendadas a serem tomadas, armadilhas a serem evitadas ou boas estruturas de amostra desse cenário que você possa apontar?

Atualização - 10/09/2015
Um projeto com uma interessante estratégia organizacional é o MEAN.JS e sua pasta de módulos.
https://github.com/meanjs/mean
https://github.com/meanjs/mean/tree/master/modules

Outro exemplo é do exemplo do ASP.NET Music Store SPA. https://github.com/aspnet/MusicStore https://github.com/aspnet/MusicStore/tree/master/src/MusicStore.Spa/ng-apps

Aqui está o design com o qual trabalho. Achei útil em dois projetos maiores que construí e que ainda não atingiram nenhum obstáculo.

Estrutura de pastas

your-project/
  apps/
    global.html
    app1/
      index.html
      app1.module.js
      app1.js
      parts/
        foo.js
        foo.html
        ...
    app2/
  libs
    lib1/
      lib1.module.js
      parts/
        directive1.js
        directive1.html
    lib2/
  third-party/

• Configure a estrutura da web do servidor para descobrir apps/app1/index.htmlquando é recebida uma solicitação /app1. Use URLs amigáveis ​​(por exemplo, em the-first-application/vez de app1/e mapeie-as usando a tecnologia do servidor, se necessário.
• Sua tecnologia de servidor deve incluir global.htmlno index.htmlporque contém o fornecedor inclui (veja abaixo).
• Inclua os recursos exigidos pelo aplicativo em index.html(veja abaixo).
• Coloque o ng-appe a raiz <div ui-view></div>no index.html.
• Cada aplicativo e lib é um módulo angular separado.
• Todo aplicativo obtém um <app-name>.module.jsarquivo que contém a lista de definições e definições de módulos angulares.
• Todo aplicativo obtém um <app-name>.jsarquivo que contém os blocos de configuração e execução dos módulos e a configuração de roteamento como parte dele.
• Todo aplicativo obtém uma partspasta que contém os controladores, visualizações, serviços e diretrizes dos aplicativos em uma estrutura que faz sentido para o aplicativo específico . Não considero subpastas como controllers/, views/etc, úteis, porque elas não escalam, mas YMMV.
• As bibliotecas seguem a mesma estrutura dos aplicativos, mas deixam de fora as coisas que não precisam (obviamente).

Comece com serviços e diretrizes dentro do aplicativo onde eles são usados. Assim que você precisar de algo em outro aplicativo também, refatorar para uma biblioteca. Tente criar bibliotecas funcionalmente consistentes, não apenas bibliotecas com todas as diretivas ou todos os serviços.

Ativos

Minifico os arquivos JS e CSS para compilações de versão, mas trabalho com arquivos não minificados durante o desenvolvimento. Aqui está uma configuração que suporta isso:

• Gerenciar inclui globalmente o fornecedor global.html. Dessa forma, o material pesado pode ser carregado do cache durante a navegação entre os SPAs. Verifique se o cache funciona adequadamente.
• Os ativos por SPA são definidos em index.html. Isso deve incluir apenas os arquivos específicos do aplicativo, bem como as bibliotecas usadas.

A estrutura de pastas acima facilita a localização dos arquivos corretos para as etapas de compilação da minificação.

Os aplicativos de página única (SPAs) não devem ser usados ​​da maneira sugerida por um aplicativo muito grande e vários mini-SPAs no principal. O maior problema será o tempo de carregamento da página, pois tudo precisa ser carregado com antecedência.

Uma maneira de resolver isso é usar uma página de navegação que o levará a SPAs individuais. A página de navegação será bastante leve e, em seguida, você carregará apenas um SPA por vez, com base no que foi selecionado. Você pode fornecer uma barra de links com links de navegação em cada um de seus SPAs, para que os usuários nem sempre tenham que voltar à página de navegação quando precisarem ir para outra área.

O uso dessa abordagem pode criar alguns desafios com informações persistentes nos SPAs. Mas estamos falando de algo que os SPAs não pretendiam fazer. Existem algumas estruturas que podem ajudar na persistência de dados do lado do cliente. A brisa é a primeira que vem à mente, mas existem outras.

Em relação ao layout - várias perguntas dos programadores abordam o layout do projeto, dependendo de suas necessidades particulares. Me deparei com este e este . Não há nada mágico nos SPAs que afetaria o layout do aplicativo além do que já foi respondido nessas perguntas.

Dito isto, existem diferentes abordagens que funcionam melhor para diferentes projetos. Eu recomendaria manter o layout base, conforme fornecido pelo projeto de semente angular. Crie pastas separadas das fornecidas para seus pacotes personalizados e código fonte. E dentro da pasta de origem, use um layout de projeto que faça sentido para suas necessidades.

Se seu aplicativo precisar de várias declarações ng-app na mesma página, será necessário inicializar manualmente o módulo AngularJS, injetando um nome de módulo, como mostrado abaixo:

angular.element(document).ready(function() {
  angular.bootstrap(document, ['TodoApp']);
});

Este desentupidor descreve como podemos inicializar manualmente o AngularJS.