# Banki Alkalmazás Készítése 3. rész: Adatok Lekérése és Használata Gondolj a Star Trek Enterprise számítógépére - amikor Picard kapitány megkérdezi a hajó állapotát, az információ azonnal megjelenik anélkül, hogy az egész felület újratöltődne vagy újraépülne. Pontosan ezt a zökkenőmentes információáramlást építjük most dinamikus adatlekéréssel. Jelenleg a banki alkalmazásod olyan, mint egy nyomtatott újság - informatív, de statikus. Átalakítjuk valami olyasmivé, mint a NASA irányítóközpontja, ahol az adatok folyamatosan áramlanak és valós időben frissülnek anélkül, hogy megszakítanák a felhasználó munkafolyamatát. Megtanulod, hogyan kommunikálj aszinkron módon a szerverekkel, hogyan kezeld a különböző időpontokban érkező adatokat, és hogyan alakítsd át a nyers információkat a felhasználók számára érthető formába. Ez a különbség egy bemutató és egy éles szoftver között. ## Előadás előtti kvíz [Előadás előtti kvíz](https://ff-quizzes.netlify.app/web/quiz/45) ### Előfeltételek Mielőtt belevágnánk az adatok lekérésébe, győződj meg róla, hogy ezek az elemek készen állnak: - **Előző lecke**: Fejezd be a [Bejelentkezési és regisztrációs űrlapot](../2-forms/README.md) - erre fogunk építeni - **Helyi szerver**: Telepítsd a [Node.js-t](https://nodejs.org) és [indítsd el a szerver API-t](../api/README.md), hogy elérhető legyen a fiókadatokhoz - **API kapcsolat**: Teszteld a szerverkapcsolatot ezzel a paranccsal: ```bash curl http://localhost:5000/api # Expected response: "Bank API v1.0.0" ``` Ez a gyors teszt biztosítja, hogy minden komponens megfelelően kommunikáljon: - Ellenőrzi, hogy a Node.js helyesen fut-e a rendszereden - Megerősíti, hogy az API szerver aktív és válaszol - Validálja, hogy az alkalmazásod eléri-e a szervert (mint egy rádiókapcsolat ellenőrzése egy küldetés előtt) --- ## Az adatok lekérésének megértése a modern webalkalmazásokban Az, ahogyan a webalkalmazások kezelik az adatokat, drámaian fejlődött az elmúlt két évtizedben. Ennek az evolúciónak a megértése segít abban, hogy értékelni tudd, miért olyan erőteljesek a modern technikák, mint az AJAX és a Fetch API, és miért váltak nélkülözhetetlen eszközökké a webfejlesztők számára. Nézzük meg, hogyan működtek a hagyományos weboldalak a dinamikus, reszponzív alkalmazásokhoz képest, amelyeket ma építünk. ### Hagyományos többoldalas alkalmazások (MPA) A web korai napjaiban minden kattintás olyan volt, mintha egy régi televízión csatornát váltanánk - a képernyő elsötétült, majd lassan megjelent az új tartalom. Ez volt a valóság a korai webalkalmazásoknál, ahol minden interakció az egész oldal teljes újraépítését jelentette. ```mermaid sequenceDiagram participant User participant Browser participant Server User->>Browser: Clicks link or submits form Browser->>Server: Requests new HTML page Note over Browser: Page goes blank Server->>Browser: Returns complete HTML page Browser->>User: Displays new page (flash/reload) ``` ![Frissítési folyamat egy többoldalas alkalmazásban](../../../../translated_images/mpa.7f7375a1a2d4aa779d3f928a2aaaf9ad76bcdeb05cfce2dc27ab126024050f51.hu.png) **Miért érezte ezt az ember nehézkesnek:** - Minden kattintás az egész oldal újraépítését jelentette - A felhasználókat megszakították a zavaró oldalvillanások - Az internetkapcsolat túlórázott, hogy újra és újra letöltse ugyanazt a fejlécet és láblécet - Az alkalmazások inkább egy iratszekrény átlapozására hasonlítottak, mint egy szoftver használatára ### Modern egyoldalas alkalmazások (SPA) Az AJAX (Asynchronous JavaScript and XML) teljesen megváltoztatta ezt a paradigmát. Mint az űrállomás moduláris kialakítása, ahol az űrhajósok egyes komponenseket kicserélhetnek anélkül, hogy az egész szerkezetet újra kellene építeni, az AJAX lehetővé teszi, hogy egy weboldal bizonyos részeit frissítsük anélkül, hogy mindent újratöltenénk. Bár a névben szerepel az XML, ma már leginkább JSON-t használunk, de az alapelv ugyanaz: csak azt frissítjük, amire szükség van. ```mermaid sequenceDiagram participant User participant Browser participant JavaScript participant Server User->>Browser: Interacts with page Browser->>JavaScript: Triggers event handler JavaScript->>Server: Fetches only needed data Server->>JavaScript: Returns JSON data JavaScript->>Browser: Updates specific page elements Browser->>User: Shows updated content (no reload) ``` ![Frissítési folyamat egy egyoldalas alkalmazásban](../../../../translated_images/spa.268ec73b41f992c2a21ef9294235c6ae597b3c37e2c03f0494c2d8857325cc57.hu.png) **Miért jobbak az SPA-k:** - Csak azok a részek frissülnek, amelyek valóban megváltoztak (okos, nem?) - Nincsenek zavaró megszakítások - a felhasználók a saját ritmusukban maradnak - Kevesebb adatot kell továbbítani, ami gyorsabb betöltést eredményez - Minden gyors és reszponzív, mint a telefonos alkalmazások ### Az evolúció a modern Fetch API-ig A modern böngészők biztosítják a [`Fetch` API-t](https://developer.mozilla.org/docs/Web/API/Fetch_API), amely felváltja a régebbi [`XMLHttpRequest`](https://developer.mozilla.org/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest) technológiát. Mint a távíró és az e-mail közötti különbség, a Fetch API ígéreteket használ a tisztább aszinkron kódhoz, és természetesen kezeli a JSON-t. | Funkció | XMLHttpRequest | Fetch API | |---------|----------------|-----------| | **Szintaxis** | Bonyolult, visszahívás-alapú | Tiszta, ígéret-alapú | | **JSON kezelés** | Manuális elemzés szükséges | Beépített `.json()` metódus | | **Hibakezelés** | Korlátozott hibainformáció | Átfogó hibainformáció | | **Modern támogatás** | Régi kompatibilitás | ES6+ ígéretek és async/await | > 💡 **Böngésző kompatibilitás**: Jó hír - a Fetch API minden modern böngészőben működik! Ha kíváncsi vagy a konkrét verziókra, a [caniuse.com](https://caniuse.com/fetch) teljes kompatibilitási történetet nyújt. > **A lényeg:** - Kiválóan működik Chrome, Firefox, Safari és Edge böngészőkben (gyakorlatilag mindenhol, ahol a felhasználóid vannak) - Csak az Internet Explorer igényel extra segítséget (és őszintén szólva, ideje elengedni az IE-t) - Tökéletesen előkészíti az utat az elegáns async/await mintákhoz, amelyeket később használunk ### Felhasználói bejelentkezés és adatlekérés megvalósítása Most valósítsuk meg azt a bejelentkezési rendszert, amely a banki alkalmazásodat egy statikus kijelzőből működőképes alkalmazássá alakítja. Mint a biztonságos katonai létesítményekben használt hitelesítési protokollok, ellenőrizzük a felhasználói hitelesítő adatokat, majd hozzáférést biztosítunk a saját adataikhoz. Ezt lépésről lépésre építjük fel, kezdve az alapvető hitelesítéssel, majd hozzáadva az adatlekérési képességeket. #### 1. lépés: A bejelentkezési funkció alapjainak létrehozása Nyisd meg az `app.js` fájlt, és adj hozzá egy új `login` függvényt. Ez fogja kezelni a felhasználói hitelesítési folyamatot: ```javascript async function login() { const loginForm = document.getElementById('loginForm'); const user = loginForm.user.value; } ``` **Részletezzük:** - Az `async` kulcsszó azt jelzi a JavaScript számára, hogy "hé, ennek a függvénynek lehet, hogy várnia kell valamire" - Megkeressük az űrlapot az oldalon (semmi bonyolult, csak az ID alapján) - Ezután kinyerjük, amit a felhasználó beírt felhasználónévként - Egy jó trükk: bármely űrlapmezőt elérheted a `name` attribútumán keresztül - nincs szükség extra getElementById hívásokra! > 💡 **Űrlap elérési minta**: Minden űrlapvezérlő elérhető a `name` attribútumán keresztül (amelyet a HTML-ben állítasz be) az űrlapelem tulajdonságaként. Ez tiszta, olvasható módot biztosít az űrlapadatok elérésére. #### 2. lépés: Hozz létre egy fiókadatok lekérési függvényt Ezután hozz létre egy dedikált függvényt a fiókadatok szerverről történő lekérésére. Ez ugyanazt a mintát követi, mint a regisztrációs függvényed, de az adatok lekérésére összpontosít: ```javascript async function getAccount(user) { try { const response = await fetch('//localhost:5000/api/accounts/' + encodeURIComponent(user)); return await response.json(); } catch (error) { return { error: error.message || 'Unknown error' }; } } ``` **Ez a kód a következőket végzi:** - **Használja** a modern `fetch` API-t az adatok aszinkron lekérésére - **Összeállít** egy GET kérés URL-t a felhasználónév paraméterrel - **Alkalmazza** az `encodeURIComponent()`-et, hogy biztonságosan kezelje az URL-ek speciális karaktereit - **Átalakítja** a választ JSON formátumba az egyszerű adatkezelés érdekében - **Kezeli** a hibákat, hogy ne omoljon össze a program > ⚠️ **Biztonsági megjegyzés**: Az `encodeURIComponent()` függvény kezeli az URL-ek speciális karaktereit. Mint a haditengerészeti kommunikációs kódolási rendszerek, biztosítja, hogy az üzenet pontosan érkezzen meg, és megakadályozza, hogy a karakterek, mint például a "#" vagy "&", félreértelmezésre kerüljenek. > **Miért fontos ez:** - Megakadályozza, hogy a speciális karakterek tönkretegyék az URL-eket - Véd az URL-manipulációs támadások ellen - Biztosítja, hogy a szerver a szándékolt adatokat kapja meg - Biztonságos kódolási gyakorlatokat követ #### HTTP GET kérések megértése Talán meglepő lehet: amikor a `fetch`-et használod extra opciók nélkül, az automatikusan egy [`GET`](https://developer.mozilla.org/docs/Web/HTTP/Methods/GET) kérést hoz létre. Ez tökéletes arra, amit most csinálunk - megkérdezzük a szervert: "Hé, megnézhetem ennek a felhasználónak a fiókadatait?" Folytatás... Bonyolultabb tartalom esetén kombináld a [`document.createElement()`](https://developer.mozilla.org/docs/Web/API/Document/createElement) metódust az [`append()`](https://developer.mozilla.org/docs/Web/API/ParentNode/append) metódussal: ```javascript // Safe way to create new elements const transactionItem = document.createElement('div'); transactionItem.className = 'transaction-item'; transactionItem.textContent = `${transaction.date}: ${transaction.description}`; container.append(transactionItem); ``` **Ennek a megközelítésnek a megértése:** - **Programozottan létrehoz** új DOM elemeket - **Teljes kontrollt biztosít** az elemek attribútumai és tartalma felett - **Lehetővé teszi** összetett, egymásba ágyazott elemek struktúráját - **Biztonságot nyújt**, mivel elválasztja a struktúrát a tartalomtól > ⚠️ **Biztonsági megfontolás**: Bár az [`innerHTML`](https://developer.mozilla.org/docs/Web/API/Element/innerHTML) sok oktatóanyagban szerepel, képes beágyazott szkripteket futtatni. Akárcsak a CERN biztonsági protokolljai, amelyek megakadályozzák az illetéktelen kódvégrehajtást, a `textContent` és a `createElement` használata biztonságosabb alternatívát kínál. > **Az innerHTML kockázatai:** - Végrehajtja a felhasználói adatokban található `