Le besoin : attendre les ressources avant de lancer l’application

Dans une page simple, une image peut apparaître quelques instants après le reste du contenu sans provoquer de problème particulier. Dans une application interactive, la situation est différente. Une scène peut avoir besoin de ses décors, une galerie de ses visuels et une interface de son fichier de configuration avant de devenir utilisable. Si le programme démarre trop tôt, il travaille avec des ressources encore absentes, affiche des zones vides ou déclenche des erreurs difficiles à reproduire.

Le navigateur sait charger chaque fichier, mais il ne connaît pas les besoins de l’application. Il ne sait pas qu’un fichier JSON doit être disponible avant de construire un menu, ni que quatre images sont nécessaires avant d’afficher une galerie. Il faut donc ajouter une étape capable de coordonner les chargements, de suivre leur avancement et de signaler le moment où tout est prêt. C’est précisément le rôle d’un AssetLoader.

Le principe : déclarer les fichiers puis suivre leur chargement commun

Au lieu de charger chaque ressource à un endroit différent du code, l’application commence par fournir une liste décrivant ce dont elle a besoin. Chaque entrée possède un nom, un type et un chemin. Le chargeur parcourt cette liste, utilise la méthode adaptée à chaque format puis conserve le résultat sous un identifiant connu. L’application ne cherche plus elle-même les fichiers : elle demande ensuite au chargeur de lui rendre la ressource déjà disponible.

Cette organisation apporte un point d’entrée unique. Une image est chargée avec un objet Image, tandis qu’un fichier JSON passe par fetch(), mais cette différence reste cachée derrière la même méthode. Le reste du programme manipule un mécanisme commun au lieu de connaître les détails propres à chaque format. Ajouter un nouveau fichier consiste alors à compléter la liste, sans modifier le déroulement général du chargement.

La progression : compter les fichiers terminés pour informer le lecteur

Une barre de progression n’a pas besoin de connaître la taille exacte de chaque fichier pour être utile. Dans cette ressource, elle repose sur le nombre de ressources terminées par rapport au nombre total. Après chaque chargement, le compteur augmente et le pourcentage est recalculé. L’interface peut ainsi afficher le nom du fichier en cours, le nombre d’éléments traités et une estimation claire de l’avancement.

La démonstration ralentit volontairement l’enchaînement afin que cette progression reste visible. Ce délai n’appartient pas au fonctionnement normal du chargeur : il sert uniquement à observer les différentes étapes. Dans un projet réel, les fichiers seraient traités aussi rapidement que le réseau et le navigateur le permettent. Le principe reste identique : chaque résultat déclenche une mise à jour de l’état jusqu’à atteindre cent pour cent.

Les formats : charger des images et des données JSON avec la même interface

Les images et les fichiers JSON ne se chargent pas de la même manière. Une image doit être décodée par le navigateur avant d’être réellement exploitable, tandis qu’un fichier JSON doit être téléchargé puis transformé en objet JavaScript. L’AssetLoader possède donc une méthode dédiée à chaque type. Cette spécialisation reste interne au composant et permet de conserver un appel identique depuis l’application.

Une fois chargées, les images sont conservées directement sous forme d’objets Image. Elles peuvent être ajoutées dans la page, dessinées dans un canvas ou utilisées comme textures sans nouveau téléchargement. Les données JSON sont stockées sous forme d’objets classiques et peuvent immédiatement alimenter une interface ou une configuration. Le chargeur devient ainsi une réserve de ressources prêtes à l’emploi.

Le stockage : retrouver chaque ressource grâce à un identifiant stable

Utiliser directement le chemin d’un fichier dans toute l’application rend le code fragile. Un déplacement de dossier oblige alors à corriger plusieurs endroits et les chemins deviennent peu lisibles dans la logique métier. L’AssetLoader associe donc chaque ressource à un identifiant simple comme ux, security ou catalogue. Le programme demande une ressource par son nom logique, indépendamment de son emplacement réel.

Les résultats sont conservés dans une collection interne. La méthode get() permet ensuite de récupérer un élément, tandis que getAll() donne accès à l’ensemble des ressources chargées. Cette séparation évite de mélanger les fichiers avec les variables de l’application. Le chargeur devient le point central de consultation et garantit que chaque identifiant renvoie toujours le même objet.

Les erreurs : interrompre proprement plutôt que démarrer avec un fichier manquant

Un chemin incorrect, un fichier supprimé ou une réponse réseau invalide peuvent empêcher un chargement. Ignorer cette situation conduirait l’application à poursuivre avec une ressource manquante et à provoquer une erreur plus loin dans son fonctionnement. Le chargeur intercepte donc l’échec au moment où il se produit et fournit un message indiquant clairement le fichier impossible à charger.

Dans cette version simple, une erreur interrompt le chargement global. Ce choix convient aux ressources indispensables : si l’une d’elles manque, l’application n’est pas considérée comme prête. D’autres projets pourraient choisir de continuer pour les éléments facultatifs, mais cette décision doit rester explicite. L’important est de posséder une règle d’échec cohérente plutôt que de laisser chaque partie du programme réagir différemment.

Le démarrage : passer de l’application en attente à l’application prête

L’AssetLoader ne sert pas uniquement à afficher une jolie barre de progression. Son rôle principal est de contrôler le moment où l’application peut commencer son travail. Avant le chargement, l’interface indique qu’elle est en attente. Pendant l’opération, elle présente l’état des fichiers. Lorsque la promesse du chargeur est résolue, le programme sait que toutes les dépendances sont disponibles.

La démonstration utilise alors les résultats pour construire une galerie d’images et afficher les données JSON reçues. Rien n’est créé avant la fin du chargement. Cette séquence rend le démarrage prévisible : déclaration des besoins, chargement, progression, puis initialisation. Le reste de l’application peut se concentrer sur son fonctionnement en partant d’un état complet et connu.

Le résultat : un composant simple à réutiliser dans de nombreux projets

Ce chargeur reste volontairement limité à deux formats afin de conserver un code rapide à comprendre. Sa structure peut néanmoins accueillir d’autres ressources comme des fichiers texte, des sons ou des polices. Il suffit d’ajouter une méthode de chargement et de l’associer au type correspondant. Le principe général ne change pas : une liste décrit les besoins et le composant fournit des résultats centralisés.

Cette organisation convient aux jeux, mais aussi aux galeries, configurateurs, cartes interactives, tableaux de bord ou applications utilisant des données externes. Elle évite de disperser les appels réseau et offre un moment précis pour lancer l’interface. L’application ne suppose plus que ses fichiers finiront par arriver : elle attend leur disponibilité, puis démarre seulement lorsqu’elle possède tout ce dont elle a besoin.