templates - ngtemplateoutlet - ng-template let

Estructura del proyecto AngularJS escalable recomendada?

Question

He visto varias plantillas de proyectos AngularJS: el proyecto inicial en el sitio web oficial, Yeoman ''s generated y AngularFun .

¿Hay alguna otra plantilla (no) obstinada que debería ver, o cualquier patrón relacionado que sugiera para un proyecto escalable de AngularJS?

Me refiero a escalable

• ser capaz de dividir controladores, directivas, filtros, etc. en sus propios archivos;
• poder cargar estos archivos a pedido en lugar de hacer que el navegador cargue todo;
• poder tener componentes comunes entre proyectos (por ejemplo, directivas comunes, filtros o servicios).

Answer 1

Advertencia: enchufe desvergonzado.

Definitivamente deberías echar un vistazo a generator-angular-xl .

Su objetivo principal es crear aplicaciones AngularJS a gran escala agrupando el código lógicamente, realizando pruebas de unidad de andamio e inyectando automáticamente sus archivos js y css en index.html, etc. También ayuda al crear un back-end simulado para sus datos, haciéndolo de manera efectiva una buena elección al desarrollar prototipos que también pueden convertirse en aplicaciones completas. NO genera ningún código de back-end, por lo que puede elegir la tecnología de back-end que desee.

Answer 2

Deberías probar ng-boilerplate. La plantilla de kickstart más prometedora para proyectos AngularJS más grandes: http://joshdmiller.github.io/ng-boilerplate/#/home

Answer 3

Diría que todos sus puntos se pueden alcanzar fácilmente, al menos sin modificaciones a Angular.

• ser capaz de dividir controladores, directivas, filtros, etc. en sus propios archivos;

esto puede hacerse, por supuesto, con Angular básico, ya que puede incluir tantas etiquetas de script con controladores / servicios como desee. Por supuesto, no es escalable en absoluto, por lo que la mejor opción sería usar módulos AMD, como RequireJS. Esta es una de las semillas que tienen este tipo de configuración: https://github.com/elsom25/angular-requirejs-html5boilerplate-seed

• poder cargar estos archivos a pedido en lugar de hacer que el navegador cargue todo;

Como pkozlowski sugirió en los comentarios, ya hay una entrada con alguna descripción del problema, verán que también estaba trabajando para resolver esto, y en realidad obtuve algunos resultados. Tengo un ejemplo práctico de carga de controladores, plantillas y directivas bajo demanda usando RequireJS y el parámetro de resolución de la configuración de ruta.

• poder tener componentes comunes entre proyectos (por ejemplo, directivas comunes, filtros o servicios)

Teniendo los puntos anteriores resueltos, podría alcanzarse fácilmente utilizando los módulos RequireJs.

Me he estado preguntando si sería una buena idea comenzar un proyecto agularjs-lazy-seed. ¿Hay alguna demanda para eso? Incluso podríamos ir más allá y mover las configuraciones de rutas fuera de la configuración habitual, digamos que tiene un archivo views.json (idealmente un servicio que responde con json) con las vistas que desea incluir en su aplicación:

{
    "views" : {
        ....
        "account" : {             
             "path" : "/account" // route path
             "name" : "Account", // view name
             "partial" : "views/account/account.html", // partial file
             "controller" : "account/main" // RequireJS module
             "directives" : [ "directives/version", "directives/menu" ] // directives used in the view
        }
        ....
    }
}

De esta manera usted podría:

• desarrollar las vistas en separación y construir la aplicación basada en este jsson bootstrap
• tener algunas directivas y componentes comunes
• cuando arranque después del inicio de sesión, puede filtrar las vistas que el usuario puede ver
• todo lo que está dentro de ngView se cargará a pedido

Por supuesto, su aplicación debería ser realmente grande para que hacer todo este trabajo adicional tenga sentido;)

Answer 4

Este proyecto suena prometedor http://vesparny.github.io/ng-kickstart

Te permite dividir tu código base por función y mantener tu código reutilizable, así como la carga en vivo gracias a una tarea personalizada de Grunt.

El proyecto también está orientado a las pruebas unitarias y viene con una "tarea dist" personalizada que le permite crear una versión optimizada y lista para producción.

Answer 5

Estoy de acuerdo con los puntos que otras personas han dicho hasta ahora; es muy fácil dividir las cosas en módulos separados y hacer que los módulos dependan el uno del otro con cosas regulares de AngularJS. Entonces su código JS se puede dividir en los archivos y directorios que prefiera.

Solo pensé en mencionar lo que estamos haciendo en el proyecto de código abierto hawtio basado en AngularJS. Hemos llevado la modularidad a un extremo :) hawtio usa plugins que pueden descubrirse en tiempo de ejecución en el servidor en ejecución (por ejemplo, implementar y anular la implementación de las funciones de la interfaz de usuario en el tiempo de ejecución). Por lo tanto, en función de alguna consulta REST o detección JMX, podemos eliminar complementos de forma dinámica o eliminarlos.

por ejemplo, aquí están todos nuestros complementos predeterminados actuales

En términos de diseño, cada complemento tiene sus propios directorios para el código (js), html partials (html) y cualquier otra cosa (por ejemplo, directorios css / img) que hace que sea fácil mantener las cosas agradables y modulares. Por ejemplo, aquí está el plugin camel que tiene sus propias carpetas html, js e img.

Luego, un complemento específico define su propio módulo AngularJS, directivas, filtros y que luego puede depender de otros módulos.

Sin embargo, hasta el momento no hemos propuesto terriblemente muchas convenciones de nomenclatura útiles para los archivos fuente :). Nos parece más sencillo escribir un archivo por controlador; pero aparte del archivo fooPlugin.ts y el archivo helpers.ts (para las funciones auxiliares específicas del módulo general) aún no hemos encontrado ninguna otra convención significativa de nomenclatura hasta el momento.

Answer 6

Puede echar un vistazo a una aplicación de demostración que Pawel Kozlowski y yo estamos reuniendo: https://github.com/angular-app/angular-app .

No proporciona ningún soporte para cargar archivos a pedido, pero puede ver que escupimos los módulos en archivos separados y configuramos las pruebas como un componente de primera clase. Tenemos un proceso de compilación (usando Grunt) que concatena (y minimiza en el lanzamiento) los archivos js y puede ejecutar pruebas unitarias y de extremo a extremo.

Hemos elegido dividir nuestros módulos en dos grupos, áreas de aplicación funcional y código de biblioteca transversal común, en lugar de una simple división en directivas, filtros, servicios, etc. Además de un área funcional, podríamos tener algunos servicios, directivas, controladores y plantillas.

Esto facilita el desarrollo en un área funcional ya que todos los elementos relevantes están en un solo lugar.

El proyecto se basa en un servidor nodeJS simple para entregar los archivos (compatible con el enlace profundo de modo HTML5) y también para proporcionar servicios de autenticación y autorización.