Dans le didacticiel Angular de base, il semble que tout ce qu'il fait est de récupérer du JSON dans une API et de l'afficher. Il y a aussi sa double magie de liaison.
Mais pourquoi devrais-je l'utiliser au lieu d'une solution de backend (comme Rails) qui crée la vue dans le backend et la sert à l'utilisateur, avec tout en place déjà? Quels sont les cas d'utilisation?
Réponses:
TLDR;
Angular vous aide à gérer la complexité inhérente aux interfaces utilisateur riches. À mesure que la complexité de l'interface utilisateur augmente, le modèle traditionnel de génération de pages sur le serveur devient beaucoup plus complexe. Angular vous permet de décomposer votre interface utilisateur en morceaux gérables et vous permet de séparer l'interface utilisateur de l'implémentation. Cela rend la génération de pages côté serveur beaucoup plus facile, mais Angular prend tout son sens lorsque vous passez à des applications basées sur du javascript pur. Trello est un bon exemple d'une telle application .
La longue histoire
Angular n'est pas vraiment destiné aux sites que vous pouvez facilement implémenter en générant tout sur le serveur et en l'envoyant. En outre, bien qu'il s'agisse d'une approche parfaitement bonne qui fonctionne pour de nombreux sites et applications sur Internet, il devient de plus en plus complexe (donc difficile) de maintenir cette approche en marche lorsque vous essayez d'augmenter le niveau d'interactivité de votre site.
En fin de compte, la façon de résoudre ce problème consiste à pousser de plus en plus votre interface utilisateur dans le côté Javascript de l'équation. Angular vous permet de diviser votre interface utilisateur en composants, vous offrant une séparation claire entre l'apparence et la façon dont cela fonctionne. Vous pouvez ensuite créer des pages assez simples sur le serveur et le frontal JS est utilisé pour créer une interface utilisateur riche qui effectue des appels séparés vers votre serveur pour les données dont ils ont besoin.
Il arrive un moment, cependant, où tout ce que vous voulez faire est de serveur une page de stub qui charge une application entièrement basée sur javascript. L'exemple le plus connu du type de cas d'utilisation où Angular brille vraiment est probablement Trello (il utilise Backbone, pas Angular, mais c'est le même cas d'utilisation). Il existe un site http://builtwith.angularjs.org/ qui contient plus d'exemples de sites utilisant Angular.
Donc, la réponse courte? Angular facilite la création d'interfaces utilisateur riches et hautement interactives en vous permettant de décomposer votre interface utilisateur en composants, et finalement de passer complètement en javascript.
Il s'agit de créer des interfaces utilisateur plus réactives. La double liaison, l'injection de dépendances, etc. permet de créer assez facilement des pages dynamiques. Vous pouvez écrire des directives en angulaire qui vous donne un moyen déclaratif de construire une vue.
Par exemple, dans un projet en cours, nous avons une vue qui utilise plusieurs centaines de lignes de code JavaScript afin de rendre une expérience utilisateur réactive. Même si la page est un peu boguée et très difficile à maintenir. Nous avons commencé à chercher une meilleure option et avons examiné backbone.js et knockout.js. Finalement, nous avons essayé Angular. Nous avons pu créer une page beaucoup plus réactive et maintenable avec seulement quelques lignes de code. Fini tout le code de manipulation DOM. Finies toutes les créations maladroites de vues d'arrière-plan qui devaient être récupérées et insérées aux bons endroits. Fini tout le code écrit pour garder le modèle et la vue synchronisés. Avec cette expérience, la décision de déménager à Angular est devenue plus facile et jusqu'à présent, nous ne l'avons pas regretté.
Angular est destiné au développement d'applications à page unique, il aide à fournir un squelette solide pour votre application. Il est également bon avec les formulaires, pas si bon avec des interfaces utilisateur complexes et encombrées avec beaucoup de données. La liaison de données bidirectionnelle est "magique" au début, mais vous devez être conscient que les cadres les plus récents (y compris Angular 2 lui-même) s'éloignent de la liaison de données bidirectionnelle pour une approche plus simple du flux de données vers le bas / du flux d'événements (en disant que histoire serait trop longue ici).
Je dois également vous avertir qu'Angular n'a pas de façon définitive de faire les choses et propose parfois trop de façons d'écorcher un chat, ce qui peut rendre la courbe d'apprentissage plus abrupte. De plus, si vous souhaitez faire évoluer une application Angular, vous devrez comprendre ses mécanismes internes et son impact possible sur les performances. Une fois que vous avez fait cela et que vous avez établi des modèles de conception solides cohérents, le ciel est la limite. Mais vous devez y consacrer du temps.
Cela dit, votre question semble concerner davantage les cas d'utilisation des SPA plutôt que Angular lui-même.
Les cas d'utilisation des applications à page unique sont destinés à avoir des applications Web avec une interface utilisateur / interface utilisateur robuste et une meilleure sensation d'application globale. En n'ayant pas à recharger votre page, vous économisez du temps de rendu et de la bande passante. Vous séparez également les données et la présentation, ce qui est génial. Votre candidature devient: