Permettez-moi maintenant de vous donner un bref aperçu des applications d'une seule page.
Que sont les applications d'une seule page ?
En quoi sont-ils différents des sites Web que vous auriez peut-être développés plus tôt ?
Par exemple, le site Web que vous avez développé dans le cours précédent de cette spécialisation,
où vous aviez plusieurs pages - pourquoi les applications d'une seule page sont-elles intéressantes
et qu'est-ce que vous devez être conscient de
lorsque vous concevez des applications d'une seule page ?
Cette conférence n'est pas destinée à être un traité entier sur les applications d'une seule page,
mais vraiment, vous donner assez d'introduction
pour vous faire commencer à penser aux applications d'une seule page,
en particulier dans le contexte d'Angular.
Avant de comprendre les applications d'une seule page, prenons un peu de recul
et regardons comment fonctionnent les sites Web traditionnels.
Dans les sites Web traditionnels, jusqu'à présent - si vous visitez un site Web,
vous pouvez demander l'accès à une page particulière.
Par exemple, vous demanderez une page index.html
lorsque vous naviguerez sur le site Web,
soit en cliquant sur un lien
, soit en tapant l'adresse du site Web dans la barre d'adresse de votre navigateur.
Donc typiquement, la page index.html est la première
que vous récupérez lorsque vous visitez un site Web.
Et quand la page est téléchargée depuis le serveur vers votre navigateur -
et alors cela sera affiché dans votre navigateur.
Maintenant, cela peut inclure non seulement la page index.html, mais aussi d'autres ressources
qui peuvent être téléchargées pour construire la page index.html.
Dans ce cas, la page index.html peut nécessiter des ressources supplémentaires,
comme des images ou des données, à télécharger avant que la page d'index puisse être construite.
Mais maintenant, par la suite, si vous naviguez vers une autre page de votre site
- disons, par exemple, une autre page comme contactus.html,
cela entraînera votre navigateur envoyer une autre demande au serveur
pour récupérer cette deuxième page.
Donc, il lancera une requête entière au serveur
et toutes les ressources nécessaires pour construire
la deuxième page devront être téléchargées à partir du serveur.
Ainsi, lorsque vous passez d'une page à une autre,
cela impliquera chaque nouvelle page à charger à partir du serveur
et cela impliquerait un temps aller-retour au serveur
pour récupérer toutes les ressources nécessaires à la construction de ces pages.
Maintenant, imaginez que votre site Web a beaucoup de pages.
Alors évidemment, chaque pièce que votre page web
nécessite pour le rendu nécessitera un temps aller-retour complet vers les serveurs.
Ce que vous remarquerez, c'est souvent que beaucoup de ces pages ont beaucoup en commun.
Peut-être, par exemple, l'en-tête
et le pied de page et d'autres informations sont tous communs dans toutes ces pages.
Mais quand même, chaque nouvelle demande de page vous demandera de
- pour aller chercher la page entière du serveur.
Maintenant, avec l'utilisation de la mise en cache sur le site du navigateur, vous pouvez atténuer certains de ces problèmes
en réutilisant les ressources déjà récupérées de votre cache ; cependant,
chaque nouvelle page vers laquelle vous naviguez nécessitera une page entière
pour être rechargée à partir du site du serveur.
Les applications d'une seule page abordent ce problème d'une manière différente.
Dans une application d'une seule page, nous avons généralement développé une application Web
de sorte que lorsque le navigateur navigue sur le site Web,
alors cela demandera que l'application Web soit téléchargée à partir du site du serveur.
Donc, cela sera, par exemple, contenu dans une page maître comme index.html,
qui déclenchera tout un ensemble d'actifs
qui sont nécessaires pour rendre votre application web à télécharger sur votre site client.
Maintenant, la façon dont ces actifs sont empaquetés dépend de la façon dont vous concevez votre application Web
et du framework que vous utilisez pour concevoir votre application Web.
Mais néanmoins, vous avez un seul grand téléchargement au début de votre application web.
Changements ultérieurs sur le site client, par exemple, initiés par un clic sur un lien,
lancera une nouvelle demande sur le site serveur ; mais dans ce cas,
très souvent, vous ne téléchargez que quelques données, peut-être sous la forme de données JSON,
à partir du site serveur.
Donc, dans ce cas, chacun d'entre eux peut nécessiter seulement l'accès au serveur
juste pour télécharger les données JSON, par exemple,
qui peut alors vous permettre de rendre complètement la nouvelle vue
dans votre application Single Page.
Donc, le téléchargement initial de la page, le téléchargement initial de l'application, bien sûr,
est toujours là, mais la plupart des interactions ultérieures avec le serveur
seront simplement pour télécharger des données, généralement sous la forme de JSON ou XML,
selon la façon dont vous concevez votre format de données.
Et une fois les données téléchargées,
ces données peuvent ensuite être utilisées pour rendre la nouvelle vue dans votre application.
Donc, dans ces circonstances,
vous économiserez beaucoup de temps aller-retour sur le serveur pour télécharger beaucoup d'actifs.
Bien sûr, le chargement initial de la page nécessite une certaine quantité de travail à faire,
mais les demandes suivantes peuvent porter sur de très petites quantités de données.
Et c'est, en effet, la caractéristique importante des applications d'une seule page.
Maintenant, avec le pré-rendu de certaines de leurs vues sur le site du serveur lui-même,
vous pouvez même atténuer une partie du temps de téléchargement initial de votre application Web.
Ainsi même Angular, par exemple,
vous permet de pré-rendre une partie de votre première vue sur le site du serveur
pour permettre l'affichage des informations au client rapidement,
pendant que le reste de l'application web est téléchargé par votre navigateur.
Donc, nous pouvons résumer que les Applications Single Page
comme une application web sur un site Web qui s'insère dans une seule page - encore une fois,
donner ou prendre - vous - vous savez, ne l'interprétez pas trop littéralement.
Donc, vous n'avez pas besoin de recharger une page entière à nouveau.
C'est donc la caractéristique importante d'une application d'une seule page.
De plus, les applications d'une seule page vous permettent d'offrir une expérience utilisateur
plus proche du travail qu'elles voient avec les applications de bureau.
Une fois l'application web initiale téléchargée ; par la suite,
la plupart des autres interactions semblent avoir l'impression que vous interagissez avec une application de bureau.
Donc, pour résumer ce que nous venons d'apprendre, qu'est-ce qu'une application d'une seule page ?
Une application d'une seule page est une application Web ou un site Web qui s'insère dans une seule page.
Vous n'avez pas besoin de recharger la page entière chaque fois qu'un utilisateur interagit
avec l'application.
L'UX est plus comme un bureau ou une application native.
La plupart des ressources requises pour votre application
sont téléchargées à la première instance elle-même, avec le chargement de la première page.
Par la suite, seules des parties de la page sont redessinées,
en fonction de la façon dont l'interaction de l'utilisateur se produit sans nécessiter un aller-retour complet du serveur,
pour récupérer toutes les ressources dont vous avez besoin.
Bien sûr, cela ne vient pas sans son propre ensemble de questions qui doivent être abordées.
Donc, lorsque vous concevez des applications à page unique, l'une des premières choses
que les gens interrogent souvent sur les applications à page unique
est qu'elles ne sont pas optimisées pour les moteurs de recherche.
Donc, l'optimisation des moteurs de recherche est une partie importante qui doit être abordée.
Donc, si vous avez des moteurs de recherche
qui explorent votre site Web pour extraire des données et indexer des informations,
alors les applications de page unique peuvent ne pas être nécessairement coopératives dans ce cas.
Mais même l'optimisation des moteurs de recherche avec les frameworks de données actuels,
comme Angular, sont venus loin de la route que même avec l'application Single Page,
moteurs de recherche peuvent essentiellement indexer beaucoup d'informations
que votre application web sert.
Le deuxième problème à résoudre est la quantité de construction Web qui doit être déchargée
sur le site client par opposition au site serveur.
Donc, le serveur agit à peu près comme une source de données dans les applications à page unique
et une grande partie du travail est déchargée sur le site client.
D'un point de vue,
cela vous donne une façon beaucoup plus évolutive de livrer votre application web
à votre site client, car une grande partie du travail de rendu est effectuée sur le site client.
Maintenant, vous pouvez optimiser cela dans une certaine mesure pour compenser le téléchargement initial
de l'application web à partir du site serveur
en faisant une partie du rendu sur le site serveur.
Comme je l'ai mentionné, Angular vous fournit une opportunité
pour le faire avec un rendu partiel du site serveur
de votre vue initiale de votre application.
Le troisième aspect est comment maintenir l'historique alors quand vous cliquez sur un bouton de retour
ou un bouton de transfert, où emmeneriez-vous l'utilisateur ?
Enregistrez-vous suffisamment d'informations
pour pouvoir naviguer parmi les différentes vues de votre application et ainsi de suite ?
C'est donc une chose que vous devez garder à l'esprit.
Bien sûr, parce que le routeur angulaire tire parti de l'API d'historique html de cinq pages,
donc il est capable de résoudre ce problème dans une large mesure.
La dernière question que nous avons est l'analyse.
Comment prendre en charge les analyses sur votre page Web ?
Comment collectez-vous les données analytiques et ainsi de suite ?
Et aussi, comme je l'ai mentionné plus tôt, accélérer le chargement initial de la page
est quelque chose qui est préoccupant lorsque vous concevez votre application web.
Maintenant, avec Angular, comme je l'ai dit,
faisant un rendu partiel du côté serveur accélérera le chargement initial de la page
sur votre site client pendant que le reste de l'application web
est téléchargé sur le site client.
Ainsi, vous pouvez masquer un peu le temps de téléchargement initial de l'application web
en effectuant un rendu partiel à partir du site du serveur lui-même.
Avec ces idées de base à l'esprit,
allons maintenant explorer comment Angular prend en charge les applications d'une seule page.
Nous avons déjà intégré le routeur Angular
dans notre application Angular dans l'exercice précédent.
Dans les exercices suivants de cette leçon
et de cette affectation, nous allons terminer le développement de l'Application Single Page
sur laquelle nous avons travaillé jusqu'à présent dans ce cours.