Est-il Possible de Créer un Site Web Interactif pour Plusieurs Utilisateurs en HTML5?
HTML lui-même ne peut pas le faire. Le principal problème est que même si vous déplacez des choses dans le navigateur (ce que vous pourrez peut-être faire avec seulement du HTML et du CSS, mais si vous parvenez à le faire, ce serait une utilisation assez exotique du CSS), il n’y a aucun moyen de contourner le fait que votre site Web a besoin d’obtenir ces informations d’un client à l’autre – c’est-à-dire que si je déplace une boîte sur mon ordinateur, votre ordinateur doit savoir. Et le HTML lui-même ne peut pas le faire tout seul.
En bref, vous avez besoin d’une sorte de serveur; et vous avez également besoin d’une certaine quantité de scripts côté client, canoniquement effectués en JavaScript, pour instrumenter l’échange d’informations du côté client.
Il existe de nombreuses façons de concevoir cela, et les détails varieront considérablement, mais en un mot, ce que vous devez faire est ceci:
Sur le client:
-
Utilisez JavaScript pour verrouiller les événements de déplacement de ces boîtes.
-
Lorsqu’une boîte a été déplacée, envoyez un message approprié au serveur.
-
En même temps, écoutez les messages provenant du serveur et déplacez les boîtes en conséquence.
La technologie canonique à utiliser pour parler au serveur serait les websockets, mais si vous insistez, vous pouvez également le faire avec des requêtes AJAX simples, c’est juste moins efficace et plus maladroit, car vous ne pouvez pas « écouter » les messages en utilisant uniquement HTTP, vous devez continuer à interroger le serveur. (C’est-à-dire : « avez-vous un message pour moi? et maintenant ? et maintenant ? et maintenant ? … »vs. » dis-moi quand tu auras un message pour moi, j’attendrai « ).
Le format du message devrait probablement être basé sur JSON – il est intégré au JavaScript du navigateur, il est connu pour ne causer aucun problème sur le fil, et c’est le format le plus couramment utilisé, donc il y aura un bon support quelles que soient les technologies que vous choisissez pour le reste de votre pile. Ce n’est pas le format de sérialisation le plus efficace, mais nous ne parlons pas ici de quantités massives de données.
Pour la partie « déplacement des boîtes », vous pouvez utiliser un framework frontend comme React, Vue, etc., mais pour ce genre de chose, je pense qu’il est plus facile d’utiliser une manipulation DOM directe via l’API DOM du navigateur intégrée.
Sur le serveur:
-
Maintenez une structure de données partagée qui décrit l’emplacement de chaque bloc.
-
Écoutez les connexions websocket.
-
Lorsqu’un nouveau client se connecte, envoyez les positions de tous les blocs, gardez la connexion ouverte.
-
Lorsqu’un client envoie une mise à jour de position de bloc, mettez à jour votre structure de données partagée et transférez la mise à jour à tous les clients connectés.
Peu importe la langue et la pile que vous utilisez pour le serveur, tant qu’il existe un bon support websocket.
En fait, il s’agit essentiellement d’un chat Web, sauf que vos « messages de chat » sont des positions de boîte au lieu de texte, et avec la torsion que vous maintenez « l’historique de chat » sous forme compressée (la structure de données « situation actuelle ») indéfiniment.
Bien sûr, le diable est dans les détails. Vous avez affaire à une structure de données partagée à laquelle vous accédez simultanément, vous devez donc la protéger contre les conditions de concurrence (par ex., lorsqu’un nouveau client se connecte et qu’un autre client envoie une mise à jour pendant que vous envoyez l’état actuel au nouveau client, mais avant de commencer à diffuser des mises à jour vers ce nouveau client, le nouveau client ne recevra pas cette mise à jour, et leur situation sera incompatible avec le reste du réseau), vous devez prendre en charge les déconnexions (et vous reconnecter automatiquement), vous avez besoin de délais d’attente sur vos connexions afin de ne pas faire fuir les connexions actives (c’est-à-dire., vous devez supprimer les clients déconnectés et expirés de la liste des clients sur le serveur), vous avez besoin d’authentification, vous avez besoin de HTTPS (y compris les websockets sur HTTPS), vous devez déployer le tout quelque part, etc. etc.