web-dev-qa-db-fra.com

AngularJS est-il réservé aux applications à page unique (SPA)?

Nous examinons des options pour créer le frontal d'une application que nous créons et essayons d'évaluer un outil qui fonctionnera pour nous et nous fournira la meilleure plate-forme pour aller de l'avant.

Ceci est un projet Node.js . Notre plan initial consistait à utiliser Express et à suivre cette voie, mais nous avons décidé qu'avant de commencer cette étape, il serait peut-être préférable de passer en revue ce qui se passe. Notre application comporte plusieurs zones qui, à notre avis, ne correspondent pas au modèle à page unique, car elles sont liées du point de vue de l'application, mais pas du point de vue.

Nous avons vu quelques-uns des frameworks que nous pourrions utiliser pour compiler le client, tels que Backbone.js , Meteor , etc., ainsi que AngularJS.

Ceci peut sembler une question assez évidente, mais nous ne semblons pas en mesure de déchiffrer si AngularJS s’applique uniquement à une application d’une page ou s’il peut être utilisé pour des applications de plusieurs pages comme Express, par exemple.

UPDATE 17 juillet 2013 Juste pour tenir les gens au courant, je mettrai à jour cette question tout au long du processus. Nous allons tout construire ensemble pour le moment et nous verrons comment cela fonctionne. Nous avons contacté quelques personnes plus qualifiées avec AngularJS que nous et nous avons posé la question concernant le fractionnement d'applications plus volumineuses partageant le même contexte, mais risquant d'être trop volumineuses pour une seule page.

Le consensus était que nous pouvions servir plusieurs pages statiques et créer des applications AngularJS fonctionnant uniquement avec ces pages, créant ainsi une collection de SPA et reliant ces applications entre elles à l'aide de liens standard. Notre cas d'utilisation est maintenant très spécifique car notre solution a plusieurs applications et, comme je l'ai dit, nous allons d'abord essayer la base de code unique et l'optimiser.

UPDATE 18 juin 2016 Le projet est tombé à pic, donc nous n'avons jamais réussi à en faire trop. Nous l'avons repris récemment, mais nous n'utilisons plus angular, mais plutôt React. Nous utilisons toujours l'architecture décrite dans la mise à jour précédente, dans laquelle nous utilisons des applications express et autonomes, par exemple, nous avons une route /chat dans express qui sert notre application de chat React, nous avons un autre itinéraire /projects qui dessert l'application de projets, etc. Nous considérons que chaque application est une racine globale en termes de jeu de fonctionnalités. Elle doit donc être autonome pour pouvoir être considérée comme une application en elle-même. Techniquement, toutes les informations sont disponibles, il s’agit juste de la messagerie express de base et de la saveur des avantages de l’application côté client que vous souhaitez utiliser.

javascriptnode.jsangularjs
199
Modika

Pas du tout. Vous pouvez utiliser Angular pour créer diverses applications. Le routage côté client n'est qu'un petit élément de cela.

Vous disposez d'une vaste liste de fonctionnalités qui vous seront utiles en dehors du routage côté client:

  • liaison à double sens
  • templating
  • formatage monétaire
  • pluralisation
  • contrôles réutilisables
  • Traitement api RESTful
  • Manipulation AJAX
  • modularisation
  • injection de dépendance

C'est fou de penser que tout cela "ne peut être utilisé que dans une application d'une seule page". Bien sûr que non… c'est comme si on disait "Jquery ne concerne que les projets avec des animations".

Si cela correspond à votre projet, utilisez-le.

215
Ben Lesh

J'ai eu du mal avec le "comment" au début avec Angular également. Puis un jour, je me suis rendu compte: "C’est encore du javascript". Il y a une foule d'exemples sur les tenants et les aboutissants de Angular (un de mes favoris avec le livre https://github.com/angular-app/angular-app ). La chose la plus importante à retenir est de charger les fichiers js comme vous le feriez dans tout autre projet. Tout ce que vous avez à faire est de vous assurer que les différentes pages font référence au bon objet Angular (contrôleur, vue, etc.) et que vous êtes opérationnel. J'espère que cela a du sens, mais la réponse était si simple que je l'ai négligée.

16
Ron

Peut-être que mon expérience sera utile à quelqu'un. Nous divisons notre projet logiquement. Nous utilisons un SPA pour le flux, un autre pour travailler avec la carte, un autre pour la modification d'un profil d'utilisateur, etc. Nous avons par exemple trois applications: le flux, l'utilisateur et la carte. Je l'utilise dans les URL séparées, comme ceci:

https://Host/feed/#/top/
https://Host/user/#/edit/1/
https://Host/map/favorites/#/add/

Chacune de ces applications possède ses propres mappages de routage locaux entre les états de l'application. Je pense que c'est une bonne pratique car chaque application ne fonctionne qu'avec son propre contexte et les dépendances de charge dont elle a réellement besoin. En outre, cette pratique est très bonne pour les processus de débogage et d'intégration.

En effet, vous pouvez très facilement mélanger des applications SPA, par exemple, le flux sera l’URL avec l’application angularjs, l’application utilisateur avec les reactjs et le mappage vers l’application backbone.js.

En réponse à votre question:

Angular non seulement pour les SPA, Angular joue bien et rapidement pour les applications SPA, mais personne ne se soucie de construire MPA l'application d'une variété d'applications SPA. Mais en pensant à votre architecture url, n'oubliez pas la disponibilité de vos applications en référencement.

Je soutiens également l'idée:

Quelle est la différence entre un projet et une application? Une application est une application Web qui fait quelque chose - par exemple, un système Weblog, une base de données d'enregistrements publics ou une simple application de sondage. Un projet est un ensemble de configurations et d'applications pour un site Web particulier. Un projet peut contenir plusieurs applications. Une application peut être dans plusieurs projets.

6
theodor

Si tout ce dont vous avez besoin est quelques pages avec une liaison de données client, je choisirais Knockout et Javascript Namespacing.

La désactivation est excellente, surtout si vous avez besoin d’une compatibilité ascendante simple et si vous avez des pages assez simples. Si vous utilisez des composants tiers, les liaisons personnalisées de Knockout sont simples et faciles à utiliser.

Le nom-code Javascript vous permet de garder votre code séparé et facile à gérer.

var myCo = myCo || {};
myCo.page = {
    init: function(){ ... },
    ...
}

Et dans une balise de script après le chargement de vos autres scripts

<script>
    myCo.init();
</script>

La clé est que vous utilisez l’outil que vous voulez lorsque vous en avez besoin. Besoin de liaison de données? Knockout (ou ce que vous aimez). Besoin de routage? sammy.js (ou ce que vous aimez).

Le code client peut être aussi simple ou compliqué que vous le souhaitez. J'ai essayé d'intégrer Angular dans un site très complexe avec un framework propriétaire existant, et c'était un cauchemar. Angular est idéal si vous commencez à zéro, mais il nécessite une courbe d'apprentissage et vous bloque dans un flux de travail très serré. Si vous ne le suivez pas, votre code peut devenir vraiment très compliqué.

3
Fred