javascript - ejemplo - ¿AngularJS es solo para aplicaciones de una sola página(SPA)?
ng-view ejemplo (5)
Estamos buscando opciones para construir la parte frontal de una aplicación que estamos creando y estamos tratando de evaluar una herramienta que funcionará para nosotros y nos dará la mejor plataforma para avanzar.
Este es un proyecto Node.js Nuestro plan inicial era utilizar Express y seguir esa ruta, pero decidimos que antes de comenzar esta etapa, sería mejor revisar lo que hay ahí fuera. Nuestra aplicación tiene varias áreas que no creemos que se ajusten al modelo de una sola página, ya que están relacionadas desde la perspectiva de una aplicación, pero no desde una vista.
Hemos visto algunos de los marcos que podríamos usar para construir el cliente como Backbone.js , Meteor , etc. y también AngularJS.
Esta puede ser una pregunta bastante obvia, pero parece que no podemos descifrar si AngularJS es puramente para aplicaciones de una sola página o puede usarse para aplicaciones de varias páginas como Express, por ejemplo.
ACTUALIZACIÓN 17 de julio de 2013 Solo para mantener a las personas informadas, actualizaré esta pregunta a medida que avancemos en el proceso. Vamos a construir todo juntos por ahora, y veremos qué tan bien funciona. Hemos contactado con algunas personas que están más calificadas con AngularJS que nosotros y planteamos la pregunta sobre la división de aplicaciones más grandes que comparten contexto, pero puede ser demasiado grande trabajar en una sola página.
El consenso fue que podríamos servir múltiples páginas estáticas y crear aplicaciones AngularJS que funcionen solo con esas páginas, creando efectivamente una colección de SPA y vinculando esas aplicaciones mediante el enlace estándar. Ahora nuestro caso de uso es muy específico, ya que nuestra solución tiene varias aplicaciones y, como dije, vamos a probar primero el código único y optimizarlo desde allí.
ACTUALIZACIÓN 18 de junio de 2016 El proyecto se cayó de un precipicio, por lo que nunca pudimos hacer demasiado. Lo hemos retomado recientemente, pero ya no estamos usando angular y estamos usando React en su lugar. Seguimos usando la arquitectura descrita en la actualización anterior, donde usamos aplicaciones exprés y autocontenidas, así que, por ejemplo, tenemos una ruta /chat
en expreso que sirve nuestra aplicación de chat React, tenemos otra ruta /projects
que presta servicio La aplicación de proyectos y así sucesivamente. La forma en que lo vemos es que cada aplicación es una raíz agregada en términos de su conjunto de características, debe ser capaz de ser independiente para que se considere una aplicación en sí misma. Técnicamente, toda la información está disponible, es solo un expreso básico y cualquiera que sea el sabor de la bondad de creación de aplicaciones del lado del cliente que desee utilizar.
De ningún modo. Puedes usar Angular para construir una variedad de aplicaciones. El enrutamiento del lado del cliente es solo una pequeña parte de eso.
Tiene una gran lista de características que lo beneficiarán fuera del enrutamiento del lado del cliente:
- enlace de dos vías
- templando
- formato de moneda
- pluralización
- controles reutilizables
- Manejo de api REST
- Manejo de AJAX
- modularización
- inyección de dependencia
Es una locura pensar que todo eso "solo podría usarse en una aplicación de una sola página". Por supuesto que no ... es como decir "Jquery es solo para proyectos con animaciones".
Si se ajusta a tu proyecto, úsalo.
Luché con el "cómo" al principio con Angular también. Entonces un día me di cuenta: "AÚN sigue siendo javascript". Hay un montón de ejemplos sobre los entresijos de Angular (uno de mis favoritos junto con el libro https://github.com/angular-app/angular-app ). Lo más importante que debes recordar es cargar los archivos js como lo harías en cualquier otro proyecto. Todo lo que tiene que hacer es asegurarse de que las diferentes páginas hagan referencia al objeto angular correcto (controlador, vista, etc.) y que esté apagado y en ejecución. Espero que esto tenga sentido, pero la respuesta fue tan simple que la pasé por alto.
Si todo lo que necesita es un par de páginas con el enlace de datos del cliente, iría con Knockout y Javascript Namespacing.
Knockout es genial, especialmente si necesita compatibilidad con versiones anteriores sin complicaciones y tiene páginas bastante sencillas. Si está utilizando componentes de terceros, los enlaces personalizados de Knockout son sencillos y fáciles de utilizar.
El espacio de nombre de Javascript le permite mantener su código separado y manejable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
Y en una etiqueta de script una vez cargados los otros scripts
<script>
myCo.init();
</script>
La clave es que use la herramienta que desee para cuando la necesite. ¿Necesita enlace de datos? Knockout (o lo que quieras). ¿Necesita enrutamiento? sammy.js (o lo que quieras).
El código del cliente puede ser tan simple o complicado como lo desee. Intenté integrar Angular en un sitio muy complicado con un marco propietario existente, y fue una pesadilla. Angular es excelente si está comenzando de nuevo, pero tiene una curva de aprendizaje y lo atrapa en un flujo de trabajo muy ajustado. Si no lo sigues, tu código puede enredarse realmente rápido.
Tal vez mi experiencia sea de utilidad para alguien. Dividimos nuestro proyecto lógicamente. Un SPA que usamos para el feed, otro para trabajar con el mapa, otro para editar un perfil de usuario, etc. Por ejemplo, tenemos tres aplicaciones: feed, usuario y mapa. Lo uso en las urls separadas, así:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Cada una de estas aplicaciones tiene sus propias asignaciones de enrutamiento locales entre los estados de la aplicación. Creo que es una buena práctica porque cada aplicación funciona solo con su propio contexto y las dependencias de carga que realmente necesita. Además, es una práctica muy buena para los procesos de depuración e integración.
De hecho, puede hacer una mezcla de aplicaciones SPA muy fácilmente, por ejemplo, el feed será url con la aplicación angularjs, la aplicación de usuario con reactjs y el mapa para la aplicación backbone.js.
En respuesta a su pregunta:
Angular no solo para los SPA, el juego angular es bueno y rápido para las aplicaciones del SPA, pero nadie se molesta en desarrollar la aplicación MPA de una variedad de aplicaciones del SPA. Pero pensando en la arquitectura de su URL no olvide la disponibilidad de SEO de sus aplicaciones.
También apoyo la idea:
¿Cuál es la diferencia entre un proyecto y una aplicación? Una aplicación es una aplicación web que hace algo, por ejemplo, un sistema Weblog, una base de datos de registros públicos o una aplicación de encuesta simple. Un proyecto es una colección de configuración y aplicaciones para un sitio web en particular. Un proyecto puede contener múltiples aplicaciones. Una aplicación puede estar en múltiples proyectos.
Yo diría que Angular es una exageración si solo estás buscando desarrollar un SPA. Claro, si ya te sientes cómodo desarrollando con él, adelante. Pero si eres nuevo en el marco y solo necesitas desarrollar un SPA, me gustaría algo más simple con una serie de ventajas propias. Recomiendo mirar en Vue.js o Aurelia.io .
Vue.js utiliza enlace de datos bidireccional, MVVM, componentes reutilizables, recolección fácil y rápida, menos código para escribir, etc. Combina algunas de las mejores características de Angular y React.
Aurelia.io , con toda honestidad, no sé mucho acerca de. Pero he echado un vistazo alrededor y parece una alternativa que vale la pena analizar, similar a la anterior.
Campo de golf:
https://vuejs.org/
http://aurelia.io/