Mikito Takada: Kalandozások webes kliens alkalmazásokkal
Mikito Takada szoftverfejlesztő, JavaScript és node.js könyvek szerzője. A következő előadást a HTML5 Fejlesztői Konferencián, 2012. októberben tartotta.
Itt az előadás kivonatát olvashatod.
Miért írunk webes kliens alkalmazásokat?
- kliens-oldali események csak JavaScriptből érhetőek el
- gyors, alacsony késleltetéssel működő felület
De a következő problémákat meg kellene oldanunk:
- külön kódot írunk a szerverhez és a klienshez
- tesztelni nehezebb, pl. DOM és böngészők miatt
- a kezdeti betöltési idő (az első interaktivitásig) nagyobb, mivel többet kell letöltenünk
- az oldalakat nem tudják a keresőprogramok bejárni (külön szerver kód nélkül)
Milyen a megfelelő kód?
A fizikai világban nagy dolgokat építünk fel, de a különböző rendszerek nem annyira fonódnak össze, mint a szoftvernél. Például: a WC-lehúzó hibája miatt a hadihajó nem fogja kilőni a rakétákat. Egy kód bonyolultságának forrása a távoli adatbevitel vagy a távoli hatás.
A megfelelő kódhoz:
- A dolgokat egymástól függetlenül kell tudnunk betölteni.
- A dolgokat egymástól függetlenül kell tudnunk tesztelni.
- A dolgok elromlásának egymástól függetlennek kell maradniuk.
Mi a baj az MVC alkalmazásokkal?
A Controller osztályok megfelelőek voltak a szerver-oldali világban: egy kérés, egy válasz, közben egy eldobható állapottal dolgoztunk. A kliens oldalon azonban meg kell őrizni az állapotot, és ha már így alakult, kidolgozhatunk egy általános megoldást az egyedi kódolások helyett.
Olyan mechanizmusra van szükségünk, ami segíti összekapcsolni a komponenseket. Ehhez az kell, hogy minden dolognak legyen egy nyilvános API-ja és az eseményeire könnyen fel tudjunk iratkozni.
A "Controller" egy barátságos kifejezés arra, hogy a kód ad-hoc összeragasztgatása már szinte tervezési mintának tűnjön. El kell tüntetnünk az MMMMMMVVVC fogalmát az egyetlen oldalon futó alkalmazásokból.
Hogyan néz ki az ideális modul?
A modul egy független kód darab, ami egy interfész mögé rejti az implementáció részleteit. A csomag a modulok egy csoportja - egy újabb nyilvános interfész mögött. A böngésző szemszögéből nézve a csomag egyetlen HTTP GET kérés.
A betöltés közben a modul és a csomag nem szabad hogy a globális állapotot módosítsa. Az inicializációs kódnak el kell különülnie, mivel a környezet-specifikus megoldás megakadályozza az újrafelhasználást.
Hogyan javíthatunk a renderelésen / sablon kezelésen?
Az oldal tipikusan string-feldolgozó műveletek sorozata szokott lenni, de ezzel nehéz az elkészített struktúrákhoz DOM eseményeket rendelni, különösen ha több szintű a beágyazás. String-kezelés helyett deklaratív nézetekre kellene koncentrálni.
Mikito Takada bemutatja az aktuális projektje (view.json) fő ötletét: Ha absztrakt módon kezeljük a DOM-ot, akkor a renderelés a szerveren és a kliensen is ugyanúgy történik, lehetővé téve akár egy gyors állapot-transzfert is a kettő között.
A View.json a sablont egy objekt prototípus deklarációra fordítja, amiből közvetlenül objektumokat példányosíthatunk. A View objektum és nem string, lekezelheti az eseményeket, illetve meghívhatja a DOM-ot (vagy az ál-DOM-ot) hogy frissítse a megjelenítést.
Mi szükséges az azonnal interakcióhoz?
- "Mi a legkevesebb adat, amit még muszáj betölteni?"
- "Mi a legkevesebb feldolgozás, amit még muszáj lefuttatni?"
Mindig csak egy csomagot töltsünk be ('alaprendszer'+1). Ha lehetséges, akkor a futtatást a szerveren kezdjük, majd az adott állapotot (ál-DOM) küldjük át a böngészőbe. Az első HTML darabokat a szerveren előre renderelhetjük, és miközben megmutatjuk a felhasználónak, a teljes betöltés a háttérben folytatódhat.
Írj nekünk!