lehet-e interaktív weboldalt létrehozni több felhasználó számára HTML5-ben?
maga a HTML nem képes erre. A fő probléma az, hogy még akkor is, ha a böngészőben mozgatja a dolgokat (amit csak HTML – vel és CSS-vel lehet megtenni, bár ha sikerül ezt megtenni, akkor a CSS meglehetősen egzotikus használata lenne), nincs mód arra, hogy megkerülje azt a tényt, hogy a webhelyének valahogy meg kell szereznie ezt az információt az egyik klienstől a másikig-vagyis ha áthelyezek egy dobozt a számítógépemen, akkor a számítógépnek tudnia kell. A HTML önmagában nem képes erre.
röviden, szükség van valamilyen szerverre; és szükség van bizonyos mennyiségű kliens oldali szkriptre is, kanonikusan JavaScript-ben, hogy az információcserét a dolgok kliens oldalán eszközölje.
sokféleképpen lehet ezt megtervezni, és a részletek drasztikusan változnak, de dióhéjban a következőket kell tennie:
az ügyfélen:
-
használja a Javascriptet, hogy rögzítse a dobozok áthelyezési eseményeit.
-
amikor egy doboz költözött, küldjön megfelelő üzenetet a kiszolgálónak.
-
ugyanakkor hallgassa meg a szerverről érkező üzeneteket, és ennek megfelelően mozgassa a dobozokat.
a szerverrel való beszélgetéshez használt kanonikus technológia a websockets lenne, de ha ragaszkodsz hozzá, egyszerű AJAX kérésekkel is megteheted, csak kevésbé hatékony és ügyetlenebb, mert nem lehet “hallgatni” az üzeneteket csak HTTP használatával, meg kell tartani a szerver lekérdezését. (Azaz: “van üzenete számomra? és most? és most? és most? …”vs.” mondja meg, ha van üzenete számomra, várok”).
az üzenet formátumának valószínűleg a JSON – on kell alapulnia-a böngésző JavaScript-be van építve, ismert, hogy nem okoz problémát a vezetéken, és ez a leggyakrabban használt formátum, így jó támogatás lesz, függetlenül attól, hogy melyik technológiát választja a verem többi részéhez. Ez nem a leghatékonyabb sorosítási formátum, de itt nem hatalmas mennyiségű adatról beszélünk.
a tényleges “mozgó dobozok körül” részhez használhat valamilyen frontend keretet, például a React, a Vue stb., de ehhez úgy gondolom, hogy könnyebb csak a közvetlen Dom manipulációt használni a beépített böngésző Dom API-n keresztül.
a szerveren:
-
megosztott adatstruktúra fenntartása, amely leírja az egyes blokkok helyét.
-
Hallgassa meg a websocket kapcsolatokat.
-
amikor egy új ügyfél csatlakozik, küldje el az összes blokk helyzetét, tartsa nyitva a kapcsolatot.
-
amikor egy ügyfél blokkpozíció-frissítést küld, frissítse a megosztott adatstruktúrát, és továbbítsa a frissítést az összes csatlakoztatott ügyfélnek.
nem számít, hogy milyen nyelvet és veremet használ a szerverhez, mindaddig, amíg jó a websocket támogatás.
valójában ez lényegében egy webes csevegés, azzal a különbséggel, hogy a “csevegési üzenetek” szöveg helyett dobozpozíciók, és azzal a csavarral, hogy a “csevegési előzményeket” tömörített formában (a “jelenlegi helyzet” adatstruktúra) határozatlan ideig fenntartja.
természetesen az ördög a részletekben rejlik. Olyan megosztott adatstruktúrával van dolga, amelyhez egyidejűleg fér hozzá, ezért ezt meg kell védenie a versenyfeltételekkel szemben (pl., amikor egy új ügyfél csatlakozik, és egy másik ügyfél frissítést küld, miközben Ön az aktuális állapotot küldi az új ügyfélnek, de mielőtt elkezdené sugározni a frissítéseket az új ügyfélnek, az új ügyfél nem kapja meg ezt a frissítést, és helyzetük nem lesz összhangban a hálózat többi részével), gondoskodnia kell a kapcsolat megszakításáról (és automatikusan újracsatlakozik), időtúllépésre van szüksége a kapcsolatokon, hogy ne szivárogjon ki aktív kapcsolatok (pl., el kell távolítania a leválasztott és időzített klienseket a kiszolgálón lévő kliensek listájáról), hitelesítésre van szüksége, HTTPS-re van szüksége (beleértve a HTTPS-en keresztüli websocketeket is), telepítenie kell az egészet valahova, stb. stb.