Ce înseamnă stocarea locală? Utilizarea localStorage pentru nevoile JavaScript. Limitări în browserele actuale

Acesta este un șablon HTML complet standard pe care îl putem completa cu conținut generat dinamic folosind JavaScript.

JavaScript

Având în vedere structura aplicației simple notepad din exemplul nostru, primul lucru pe care trebuie să-l facem este să furnizăm urmărirea evenimentului de clic pe butonul „Adăugați o intrare”și verificați dacă în câmpul de text pentru intrare este introdusă vreo informație, adică în momentul în care butonul este apăsat, acesta nu trebuie să fie gol. Ceva de genul asta:

$("#add").click(function() (
//dacă câmpul de text este gol
$("#alertă").html(" Atenţie! Introduceți intrarea în text
domeniu.");
returnează fals;
}

Aceasta este ceea ce facem cu această bucată de cod. Când butonul este apăsat „Adăugați o intrare” verificăm dacă utilizatorul a introdus ceva în câmp pentru noua intrare. Dacă nu a făcut acest lucru, atunci apare div-ul pe care l-am furnizat pentru afișarea mesajelor, informând utilizatorul că câmpul de intrare pentru intrare nu este completat și apoi, după 1000ms (1 secundă), elementul div și, în consecință, mesajul, dispare. Funcția returnează apoi false , după care browserul nu mai execută restul scriptului și aplicația este din nou gata să introducă o nouă intrare.

Următorul nostru pas va fi să adăugăm valoarea introdusă în câmpul de intrare la începutul listei prin generarea unui nou element de listă. Astfel, atunci când utilizatorul adaugă o altă intrare, aceasta va fi întotdeauna plasată la începutul listei de sarcini planificate și evenimente așteptate. După aceasta, tot ce trebuie să facem este să salvăm lista folosind mecanismul localStorage:

// Adăugați o intrare la lista existentă
$("#todos").prepend("

După cum probabil ați observat, nu este nimic neobișnuit aici, este folosită versiunea standard a codului jQuery. Acolo unde accesăm obiectul localStorage, trebuie să specificăm datele pe care le stocăm sub formă de cheie/valoare. Puteți folosi un nume arbitrar pentru cheie, iar eu am numit-o "todos", apoi trebuie să indicăm ce trebuie să stocăm de fapt în memorie. În acest caz, este un fragment complet de markup HTML inclus într-o listă neordonată (situată între etichete), cu ajutorul căruia sunt afișate toate intrările introduse anterior de utilizator. Din cod este clar că pur și simplu extragem fragmentul din care avem nevoie folosind jQuery metoda .html() iar la final, după ce au finalizat toate acțiunile necesare, setăm valoarea de returnare a funcției la false, ceea ce împiedică trimiterea datelor din formular și, prin urmare, reîncărcarea paginii noastre.

Acum, să presupunem că utilizatorul nostru a făcut deja mai multe intrări și pentru mai departe funcționare normală aplicație, trebuie să verificăm dacă localStorage conține informații salvate anterior pe computer și, dacă da, să le afișăm utilizatorului. Deoarece numele nostru cheie este „todos”, ar trebui să verificăm existența acestuia astfel:

// dacă există deja date în stocarea locală, atunci afișați-le

}

Pentru a verifica prezența datelor, am folosit o declarație if obișnuită și, dacă a fost îndeplinită condiția pe care am specificat-o, am preluat pur și simplu toate datele din stocarea locală, plasându-le ca marcaj HTML într-o listă neordonată, care afișează intrările introduse anterior. de către utilizator.

Dacă verificați funcționarea aplicației dvs. simple, veți constata că după reîncărcarea paginii totul rămâne în loc. Și acum, ultimul lucru pe care trebuie să-l facem este să creăm o funcție cu care utilizatorul, dacă este necesar, să-și poată șterge toate intrările. Acest lucru este implementat prin ștergerea localStorage și reîncărcarea paginii pentru a activa modificările efectuate. Apoi, ca și în cazul precedent, setăm false ca valoare de returnare a funcției, ceea ce împiedică apariția hash-ului în URL. ( *și nu derulează în sus în pagină.):

// Curățarea completă a localStorage
window.localStorage.clear();
locație.reîncărcare();
returnează fals;
});

Drept urmare, avem o aplicație complet funcțională. Și punând toate fragmentele de mai sus împreună, obținem cod complet aplicatii:

$("#add").click(function() (
var Descriere = $("#descriere").val();
if($("#descriere").val() == "") (
$("#alertă").html(" Atenţie! Introduceți intrarea în
câmp text.");
$("#alerta").fadeIn().delay(1000).fadeOut();
returnează fals;
}
$("#todos").prepend("

if(localStorage.getItem(„todos”)) (
$("#todos").html(localStorage.getItem("todos"));
}

$("#clear").click(function() (
window.localStorage.clear();
locație.reîncărcare();
returnează fals;
});

Suport pentru browser.

Specificația HTML5 oferă suport destul de puternic pentru tehnologia de stocare web, datorită căreia este implementată și de majoritatea browserelor populare, chiar și IE8. Singura problemă rămâne IE7, dacă tot ești interesat.

Concluzie.

În astfel de aplicații mici, mecanismul localStorage poate înlocui cu succes utilizarea bazelor de date. Pentru a stoca cantități mici de date, nu este necesar să folosiți alternative mai complexe.

*Nota traducătorului.

Vizualizări post: 475

Din aplicații web precum Google Wave, Gmail etc. Vedem că stocarea în cache a datelor la nivelul clientului este o idee bună pentru majoritatea aplicațiilor web. Gândește-te singur, pentru internet mobil volumul este foarte important. Interogările de același tip în 70% din cazuri (nu am făcut niciun calcul, doar că este mult mai solid să exprim argumentele sub formă de procente) returnează aceleași date. În plus, puteți stoca în cache nu numai datele, ci și aplicația în sine.

Până acum, cea mai populară metodă de stocare locală a fost cookie-urile. Un cookie este o pereche cheie-valoare care este stocată local în fișier text(4 KB sau maxim 20 de perechi cheie-valoare (IE) pentru un domeniu). În plus, cookie-urile sunt trimise către server cu orice cerere HTTP către server, chiar și cu AJAX. Este firesc ca standardul să fi inclus mijloace pentru stocarea mai practică a datelor în browser.

Dintre întreaga specificație HTML5, stocarea locală a datelor la nivelul clientului este probabil unul dintre cele mai discutate subiecte. Există atât opinii pozitive, cât și negative. Dintre minusuri, cea mai semnificativă este o încălcare a conceptului de relevanță a datelor pentru toți utilizatorii, adică. modul în care funcționează acum: utilizatorul merge pe site și vede ultima versiune aplicație web, cea pe care o văd toți ceilalți utilizatori. Cu toate acestea, cu utilizarea corectă a stocării locale și actualizări în timp util date, aceste probleme pot fi evitate.

Deci, stocarea pe partea clientului este împărțită în 3 metodologii fundamentale:

1. Stocarea sesiunii.
2. Stocare locală sau Stocare globală

Să aruncăm o privire mai atentă la fiecare dintre ele:

1. Stocarea sesiunii- stocarea sesiunii

Stocarea sesiunii este mai convenabilă decât cookie-urile. Cu implementari diferite max. limita poate fi de ordinul mai multor Mbiți. Spre deosebire de cookie-uri, datele de sesiune nu sunt trimise la fiecare solicitare.
Avantaje: La cerere, sarcina utilă este minimă.
Iată un exemplu de stocare a sesiunii:

SessionStorage.setItem(„nume utilizator”, „taranfx”); // definește variabila de sesiune alert("Numele tău este: " + sessionStorage.getItem("userName") // accesează alertă de verificare("Hello " + sessionStorage.userName); // o altă metodă de accesare a variabilei de sesiune sessionStorage.removeItem("userName"); // la final ștergem variabila

2. Stocare locală- depozitare locală

Obiectul JavaScript LocalStorage este identic din punct de vedere funcțional cu obiectul sessionStorage. Ele diferă doar prin speranța de viață și vizibilitate. Domeniu de aplicare: datele din localStorage sunt accesibile în toate ferestrele browserului, în timp ce datele sesiunii de stocare sunt limitate la fereastra în care au fost create.
Stocarea globală a memoriei este setată de browser, site-urile web o pot folosi pentru a stoca date persistente care nu trebuie trimise la server. Datele sunt disponibile prin JavaScript și Flash. Acest lucru poate fi foarte convenabil pentru jocurile Flash.

GlobalStorage[""].foo = "bar"; // foo va fi disponibil pe orice site globalStorage["ru"].foo1 = "bar1"; // foo1 va fi disponibil pe site-urile "..foo2 = "bar2"; // foo2 va fi disponibil numai pe site

La stocarea locală a datelor, specificația a fost rescrisă pentru a fi mai sigură. Aceste. Acum datele sunt conectate automat la domeniu.
Durata de valabilitate: Când sunt stocate în Stocare locală, datele sunt păstrate chiar și după închiderea filei/ferestrei/browserului.

Iată cum să o faci:

LocalStorage.setItem(„nume utilizator”, „taranfx”); // definește o variabilă în localStorage alert("Numele tău este: " + localStorage.getItem("userName")); // accesează-l alert("Bună ziua" + localStorage.userName); // accesează-l diferit localStorage.removeItem("userName"); // șterge-l la sfârșit

3. Stocarea bazei de date- stocare într-o bază de date

Până acum am discutat despre magazine limitate la perechi cheie-valoare. Dar atunci când aveți de-a face cu volume mari de date, nimic mai bun decât o bază de date nu a fost încă inventat. Browserele utilizează baze de date SQLite, care funcționează fără procese și servere suplimentare. Doar cu restricții minore, de exemplu absența unei chei străine.

Dar ca recompensă primești o bază de date SQL cu drepturi depline. Și lucrul cu acesta se realizează în SQL.

Traducere: Vlad Merzhevich

Stocarea locală persistentă este un domeniu în care aplicațiile client au avantaje față de aplicațiile server. Pentru aplicații precum sistem de operare, oferă un strat de abstractizare pentru stocarea și preluarea datelor, cum ar fi setările sau starea execuției. Aceste valori pot fi stocate în registru, fișiere INI, fișiere XML sau în altă parte, în funcție de principiile platformei. Dacă aplicația dvs. client are nevoie de stocare locală pentru mai mult decât o pereche cheie/valoare, puteți introduce propria bază de date, puteți crea propriul format de fișier sau orice alte soluții.

Din punct de vedere istoric, aplicațiile web nu au avut niciunul dintre aceste luxuri. Cookie-urile au fost inventate la începutul istoriei internetului și pot fi folosite pentru a stoca permanent cantități mici de date la nivel local. Dar au trei dezavantaje potențiale:

• Cookie-urile sunt incluse în fiecare solicitare HTTP, încetinind astfel aplicația dvs. web prin transmiterea inutilă a acelorași date din nou și din nou;
• cookie-urile sunt incluse în fiecare solicitare HTTP atunci când se transmit date prin Internet în formă necriptată (chiar dacă întreaga aplicație web este transmisă prin SSL);
• Cookie-urile sunt limitate la aproximativ 4KB de date - suficient pentru a vă încetini aplicația (vezi mai sus), dar nu suficient pentru a fi utile.

Iată ce ne dorim cu adevărat:

• mult spațiu de depozitare;
• lucru pe partea clientului;
• ia în considerare reîmprospătările paginii;
• fara trimitere catre server.

Înainte de HTML5, toate încercările de a realiza acest lucru au eșuat în cele din urmă în diferite moduri.

O scurtă istorie a stocării locale înainte de HTML5

La început a fost doar unul Internet Explorer. Cel puțin asta a vrut Microsoft să gândească lumea. În acest scop, în cadrul Primului Marele Război browsere Microsoft a inventat o mulțime de lucruri și le-a inclus în browser-ul său, care a pus capăt războiului, Internet Explorer. Unul dintre aceste lucruri se numea Comportamente DHTML, iar unul dintre comportamente se numea userData.

UserData permite unei pagini web să stocheze până la 64 KB de date per domeniu într-o structură ierarhică asemănătoare XML. Domeniile de încredere, cum ar fi site-urile intranet, pot stoca de zece ori mai mult. Și hei, 640 KB ar trebui să fie suficienți pentru toată lumea. IE nu a oferit nicio modalitate de a modifica aceste convenții, așa că nu există nicio modalitate de a crește cantitatea de memorie disponibilă.

În 2002, Adobe a introdus o funcție în Flash 6 care nu a avut succes și numită în mod înșelător „Flash Cookies”. În mediul Flash, această caracteristică este mai bine cunoscută ca obiecte locale partajate (LSO). Pe scurt, permite obiectelor Flash să stocheze până la 100 KB de date per domeniu. Brad Neuberg, care a dezvoltat un prototip timpuriu al unei punți între Flash și JavaScript, l-a numit AMASS (AJAX Massive Storage System), dar a fost limitat de unele ciudatenii ale designului Flash. Până în 2006, odată cu introducerea ExternalInterface în Flash 8, accesarea LSO-urilor prin JavaScript a devenit un ordin de mărime mai ușoară și mai rapidă. Brad a rescris AMASS și l-a integrat în popularul Dojo Toolkit sub pseudonimul dojox.storage. Flash oferă fiecărui domeniu 100 kb de spațiu de stocare „gratuit”. În plus, oferă utilizatorului, la cerere, să mărească volumul de stocare cu un ordin de mărime (1 MB, 10 MB etc.).

dacă (Modernizr.localstorage) (
// window.localStorage este disponibil!
) altfel (
// nu există suport nativ pentru stocarea HTML5
}

Folosind stocarea HTML5

Stocarea HTML5 se bazează pe numele perechilor cheie/valoare. Stocați informații pe baza numelui cheii și apoi puteți prelua acele date cu aceeași cheie. Numele cheii este un șir. Datele pot fi de orice tip acceptat de JavaScript, inclusiv șiruri de caractere, valori booleene, numere întregi sau numere în virgulă mobilă. Cu toate acestea, în realitate, datele sunt stocate ca șir. Dacă stocați și preluați non-șiruri, va trebui să utilizați funcții precum parseInt() sau parseFloat() pentru a converti datele primite în tipurile JavaScript corecte.

Interfata de stocare (
Obține prin getItem(cheie);
Setați prin setItem(cheie, date);
};

Apelarea setItem() cu un nume de cheie existent va suprascrie în tăcere valoarea anterioară. Apelarea getItem() cu o cheie inexistentă va returna NULL, mai degrabă decât să arunce o excepție.

Ca și alte obiecte JavaScript, puteți accesa obiectul localStorage ca o matrice asociativă. În loc să utilizați metodele getItem() și setItem(), puteți specifica pur și simplu paranteze pătrate. De exemplu, acest fragment de cod

var foo = localStorage.getItem("bar");
// ...
localStorage.setItem("bar", foo);

poate fi rescris folosind sintaxa parantezelor drepte:

var foo = localStorage["bar"];
// ...
localStorage["bar"] = foo;

Există, de asemenea, metode de ștergere a valorilor după numele cheii, precum și de ștergere a întregului magazin (adică ștergerea tuturor cheilor și valorilor simultan).

Interfata de stocare (
Eliminați prin removeItem(cheie);
clar();
}

Apelarea removeItem() cu o cheie inexistentă nu va returna nimic.

În cele din urmă, există o proprietate de a obține numărul total de valori din zona de stocare și de a itera peste toate cheile după index (obține numele fiecărei chei).

Interfata de stocare (
lungime
Obține cheie (întreg nenegativ);
}

Dacă, atunci când key() este apelată, indexul nu este în intervalul de la 0 la (lungimea-1), atunci funcția va returna null .

Monitorizarea zonei de stocare HTML5

Dacă doriți să urmăriți programatic modificările de stocare, trebuie să capturați evenimentul de stocare. Acest eveniment are loc pe obiectul fereastră când setItem() , removeItem() sau clear() sunt apelate și modifică ceva. De exemplu, dacă ați instalat valoarea existentă sau numit clear() când nu există chei, evenimentul nu se va declanșa deoarece zona de stocare nu s-a schimbat efectiv.

Evenimentul de stocare este acceptat oriunde rulează obiectul localStorage, inclusiv Internet Explorer 8. IE 8 nu acceptă standardul W3C addEventListener (deși va fi adăugat în sfârșit în IE 9), așa că pentru a captura evenimentul de stocare trebuie să verificați ce motor de evenimente acceptă browser-ul (dacă ați mai făcut acest lucru cu alte evenimente, puteți sări la sfârșitul acestei secțiuni). Interceptarea evenimentului de stocare funcționează în același mod ca și interceptarea altor evenimente. Dacă preferați să utilizați jQuery sau o altă bibliotecă JavaScript pentru a înregistra handlere de evenimente, puteți face acest lucru și cu stocare.

dacă (window.addEventListener) (
window.addEventListener("storage", handle_storage, false);
) altfel (
window.attachEvent("onstorage", handle_storage);
};

Callback-ul handle_storage va fi apelat cu obiectul StorageEvent, cu excepția Internet Explorer, unde evenimentele sunt stocate în window.event .

funcția handle_storage(e) (
dacă (!e) ( e = fereastră.eveniment; )
}

În acest caz, variabila e va fi un obiect StorageEvent, care are următoarele proprietăți utile.

*Notă: proprietatea URL a fost inițial numită uri și unele browsere au acceptat această proprietate înainte ca specificația să se schimbe. Pentru a asigura compatibilitatea maximă, ar trebui să verificați dacă proprietatea url există, iar dacă nu, verificați în schimb proprietatea uri.

Evenimentul de stocare nu poate fi anulat și nu există nicio modalitate de a opri modificarea în interiorul callback-ului handle_storage. Este doar modul browser-ului de a vă spune: „Hei, asta tocmai sa întâmplat. Nu poți face nimic, am vrut doar să știi.”

Limitări în browserele actuale

Când am vorbit despre istoricul stocării locale folosind pluginuri terțe, am menționat limitările fiecărei tehnici. Mi-am amintit că nu am spus nimic despre limitările stocării standard HTML5 de acum. Îți voi da răspunsurile și apoi le explic. Răspunsurile, în ordinea importanței, sunt „5 megaocteți”, „QUOTA_EXCEEDED_ERR” și „niciunul”.

„5 megaocteți” - cât spațiu de stocare este furnizat implicit. Această valoare este surprinzător de consecventă în toate browserele, deși este menționată ca doar o sugestie în specificația HTML5. Trebuie să înțelegeți că stocați șiruri de caractere, nu date în formatul original. Dacă stocați o mulțime de numere întregi sau cu virgulă mobilă, diferența de reprezentare poate fi mare. Fiecare cifră dintr-un număr în virgulă mobilă este stocată ca un caracter, mai degrabă decât în ​​reprezentarea obișnuită pentru astfel de numere.

„QUOTA_EXCEEDED_ERR” este excepția pe care o veți primi dacă depășiți cota de 5 MB. „Nu” este răspunsul la următoarea întrebare evidentă: „Pot să cer utilizatorului mai mult spațiu de stocare?” La momentul redactării acestui articol, browserele nu implementează niciun mecanism pentru ca dezvoltatorii web să solicite mai mult spațiu de stocare. Unele browsere (cum ar fi Opera) permit utilizatorului să controleze cotele de stocare pe site, dar aceasta este pur și simplu o inițiativă a utilizatorului și nu are legătură cu nimic pe care, în calitate de dezvoltator, puteți construi în aplicația dvs. web.

Stocarea HTML5 în acțiune

Să aruncăm o privire asupra stocării HTML5 în acțiune. Să revenim din nou la cel pe care l-am construit în capitolul despre desen. Există o mică problemă cu acest joc: dacă închideți fereastra browserului în mijlocul jocului, veți pierde rezultatele. Dar cu stocarea HTML5, putem salva procesul de joc local, în browserul propriu-zis. Deschideți demonstrația, faceți câteva mișcări, închideți fila browserului și apoi deschideți-o din nou. Dacă browserul dvs. acceptă stocarea HTML5, pagina demo își va aminti magic poziția exactă în joc, inclusiv câte mișcări ați făcut, poziția fiecărei piese pe tablă și chiar piesa selectată.

Cum funcţionează asta? De fiecare dată când apare o schimbare în joc, vom apela această funcție.

funcția saveGameState() (

localStorage["halma.game.in.progress"] = gGameInProgress;
pentru (var i = 0; i< kNumPieces; i++) {
localStorage["halma.piece." + i + ".row"] = gPieces[i].row;
localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
}
localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
localStorage["halma.movecount"] = gMoveCount;
returnează adevărat;
}

După cum puteți vedea, obiectul localStorage este folosit pentru a salva progresul jocului (gGameInProgress, tip boolean). Apoi, toate piesele (gPieces, o matrice JavaScript) sunt repetate și un rând și o coloană sunt salvate pentru fiecare dintre ele. Unele stări suplimentare de joc sunt apoi salvate, inclusiv piesa selectată (gSelectedPieceIndex, un număr întreg), piesa care se află în mijlocul unei serii lungi de sărituri (gSelectedPieceHasMoved, un boolean) și numărul total de mișcări efectuate (gMoveCount, un întreg).

Când pagina se încarcă, în loc să apelăm automat funcția newGame(), care ar returna toate variabilele la valorile lor originale, numim resumeGame() . Funcția resumeGame() folosește stocarea HTML5 pentru a verifica starea jocului în stocarea locală. Dacă este prezent, restaurează valorile utilizând obiectul localStorage.

funcția resumeGame() (
dacă (!supportsLocalStorage()) ( returnează false; )
gGameInProgress = (localStorage["halma.game.in.progress"] == "adevărat");
dacă (!gGameInProgress) ( returnează fals; )
gPieces = nou Array(kNumPieces);
pentru (var i = 0; i< kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var column = parseInt(localStorage["halma.piece." + i + ".column"]);
gPieces[i] = new Cell(rând, coloană);
}
gNumPieces = kNumPieces;
gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "adevărat";
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawboard();
returnează adevărat;
}

Cea mai importantă parte a acestei caracteristici este o avertizare pe care am menționat-o mai devreme în acest capitol și care se va repeta aici: datele sunt stocate ca șiruri de caractere. Dacă stocați altceva decât șiruri, trebuie să le convertiți când le primiți. De exemplu, indicatorul că un joc este în desfășurare (gGameInProgress) este de tip boolean. În funcția saveGameState() pur și simplu o stocăm și nu ne facem griji pentru tipul de date.

localStorage["halma.game.in.progress"] = gGameInProgress;

Dar în funcția resumeGame(), trebuie să ne uităm la valoarea preluată din stocarea locală ca șir și să ne construim manual propria noastră valoare booleană.

gGameInProgress = (localStorage["halma.game.in.progress"] == "adevărat");

În mod similar, numărul de mișcări este stocat în gMoveCount ca un număr întreg, în funcția saveGameState() îl salvăm pur și simplu.

localStorage["halma.movecount"] = gMoveCount;

Dar în funcția resumeGame(), trebuie să convertim valoarea într-un număr întreg folosind funcția încorporată parseInt() din JavaScript.

gMoveCount = parseInt(localStorage["halma.movecount"]);

Dincolo de perechile cheie/valoare: viziune competitivă

Deși au existat multe trucuri și soluții de-a lungul istoriei, starea actuală a stocării HTML5 este surprinzător de sănătoasă. Noul API a fost standardizat și inclus în toate browserele, platformele și dispozitivele majore. Pentru un dezvoltator web, asta nu este ceva ce vezi în fiecare zi, nu-i așa? Dar există mai mult decât „5 megaocteți de perechi cheie/valoare” și viitorul stocării locale persistente este... cum să spun... ei bine, să spunem că este o viziune competitivă.

One vision este un acronim pe care îl cunoașteți deja - SQL. În 2007, Google a lansat Gears, un plugin open-source pentru mai multe browsere cod sursă, care include o bază de date încorporată bazată pe SQLite. Acest prototip timpuriu a influențat ulterior crearea specificației Web SQL Database. Baza Date web SQL (cunoscut anterior ca „WebDB”) oferă un înveliș subțire în jurul bazei de date date SQL, care vă permite să faceți următoarele lucruri din JavaScript:

openDatabase(„documente”, „1.0”, „Stocare locală a documentelor”, 5*1024*1024, funcție (db) (
db.changeVersion("", "1.0", funcția (t) (
t.executeSql("CREATE TABLE docids (id, name)");
), eroare);
});

După cum puteți vedea, cea mai mare parte a acțiunii este în conformitate cu metoda ExecuteSQL. Această linie poate suporta orice Comenzi SQL, inclusiv SELECT, UPDATE, INSERT și DELETE. Este la fel ca programarea bazelor de date pe server, cu excepția faptului că o faci cu JavaScript! O bucurie!

Specificația bazei de date Web SQL a fost implementată în patru browsere și platforme.

Desigur, dacă ai folosit mai multe baze de date în viața ta, știi că „SQL” este mai mult un termen de marketing decât unul greu și rapid. standard rapid(cineva ar putea spune același lucru despre HTML5, dar asta nu este important). Desigur, există o specificație SQL actuală (numită SQL-92), dar nu există un server de baze de date în lume care să respecte doar această specificație. Mânca Oracle SQL, Microsoft SQL, SQL la MySQL, SQL la PostgreSQL, SQL la SQLite. De fapt, fiecare dintre aceste produse adaugă altele noi în timp. Funcții SQL, așa că nici măcar a spune „SQL în SQLite” nu este suficient. Ar trebui să spuneți „versiune de SQL care vine cu versiunea SQLite X.Y.Z”.

Toate acestea ne duc la următoarea declinare a răspunderii, postată în prezent în partea de sus a specificației Web SQL.

Specificația a ajuns într-o fundătură: toți dezvoltatorii interesați folosesc SQL la nivel de server (SQLite), dar avem nevoie de mai multe implementări independente pentru a trece la standardizare. În timp ce alți dezvoltatori sunt interesați să implementeze această specificație, descrierea dialectului SQL a fost lăsată ca o simplă referință la Sqlite, ceea ce nu este acceptabil pentru standard.

În acest context, vă voi povesti despre o altă viziune competitivă pentru stocarea locală avansată și persistentă pentru aplicații web: Indexed Database API, cunoscut anterior ca „WebSimpleDB”, numit acum afectuos IndexedDB.

Indexed Database API oferă ceea ce se numește stocare de obiecte, cu multe idei împrumutate din bazele de date SQL. Există „baze de date” cu „înregistrări”, fiecare înregistrare are un anumit număr de „câmpuri”. Fiecare câmp are un tip de date specific, care este determinat la crearea bazei de date. Puteți selecta un subset de înregistrări, apoi le puteți lista cu „cursorul”. Modificările aduse depozitului de obiecte sunt procesate cu „tranzacții”.

Dacă ați programat vreodată baze de date SQL, acești termeni vă sunt probabil familiari. Principala diferență este că stocarea obiectelor nu are limbaj structurat cereri. Nu scrieți o condiție precum „SELECT * din UTILIZATORI, unde ACTIV = „Y””. În schimb, folosim metodele furnizate de depozitul de obiecte pentru a deschide baza de date UTILIZATOR, a enumera înregistrările, a ne filtra înregistrările și a folosi metode accesorii pentru a obține valoarea fiecărui câmp al înregistrărilor rămase. O prezentare timpurie a IndexedDB este un tutorial bun despre cum funcționează IndexedDB și cum se compară IndexedDB cu Web SQL.

La momentul scrierii, IndexedDB a fost implementat doar în Firefox 4 beta. În schimb, Mozilla a declarat că nu va implementa niciodată Web SQL. Google a declarat că ia în considerare suportul IndexedDB pentru Chromium și Google Chrome. Și chiar și Microsoft a spus că IndexedDB este „o soluție excelentă pentru web”.

Ce poți face ca dezvoltator web cu IndexedDB? Pe în acest moment practic nimic, cu excepția unor demonstrații de tehnologie. Într-un an? Pot fi.

The API-ul de stocare web oferă mecanisme prin care browserele pot stoca perechi cheie/valoare, într-un mod mult mai intuitiv decât utilizarea cookie-urilor.

Concepte de stocare web și utilizare

Cele două mecanisme din Web Storage sunt următoarele:

• sessionStorage menține o zonă de stocare separată pentru fiecare origine dată, care este disponibilă pe durata sesiunii de pagină (atâta timp cât browserul este deschis, inclusiv reîncărcările și restaurările paginii)
  • Stochează datele numai pentru o sesiune, ceea ce înseamnă că datele sunt stocate până când browserul (sau fila) este închis.
  • Datele nu sunt niciodată transferate pe server.
  • Limita de stocare este mai mare decât un cookie (cel mult 5 MB).
• localStorage face același lucru, dar persistă chiar și atunci când browserul este închis și redeschis.
  • Stochează datele fără o dată de expirare și sunt șters numai prin JavaScript sau ștergerea cache a browserului / Datele stocate local.
  • Limita de stocare este maxima dintre cele trei.

Specificații

Compatibilitate browser

Window.localStorage

https://github.com/mdn/browser-compat-data și trimiteți-ne o cerere de extragere.

Legendă

Window.sessionStorage

Tabelul de compatibilitate de pe această pagină este generat din date structurate. Dacă doriți să contribuiți la date, vă rugăm să consultați https://github.com/mdn/browser-compat-data și să ne trimiteți o cerere de extragere.

Actualizați datele de compatibilitate pe GitHub

Legendă

Navigare privată/Moduri incognito

Majoritatea browserelor moderne acceptă o opțiune de confidențialitate numită „Incognito”, „Navigare privată” sau ceva similar care nu stochează date precum istoricul și cookie-urile. Acest lucru este în mod fundamental incompatibil cu stocarea web, din motive evidente, furnizorii de browsere experimentează diferite scenarii pentru cum să faceți față acestei incompatibilități.

Majoritatea browserelor au optat pentru o strategie în care API-urile de stocare sunt încă disponibile și aparent complet funcționale, cu singura mare diferență că toate datele stocate sunt șterse după ce browserul este închis. Pentru aceste browsere există încă interpretări diferite a ceea ce ar trebui făcut cu datele stocate existente (de la o sesiune obișnuită de navigare). Ar trebui să fie disponibil pentru a fi citit în modul privat? Apoi, există unele browsere, în special Safari, care au optat pentru o soluție în care stocarea este disponibilă, dar este goală și are alocată o cotă de 0 octeți, făcând efectiv imposibilă scrierea datelor în ea.

Dezvoltatorii ar trebui să fie conștienți de aceste implementări diferite și să le ia în considerare atunci când dezvoltă site-uri web în funcție de API-urile de stocare web. Pentru mai multe informații, vă rugăm să aruncați o privire la această postare de blog WHATWG care tratează în mod special acest subiect.

Cookie-urile despre care am discutat în lecția anterioară sunt foarte limitate: un cookie poate avea doar 4096 de caractere, iar numărul de cookie-uri pe domeniu poate fi de aproximativ 30-50, în funcție de browser.

Prin urmare, din păcate, nu va fi posibil să stocați o mulțime de informații acolo. Așa s-a întâmplat istoric.

Pentru a ocoli această limitare, în browsere a apărut o alternativă la cookie-uri - se numește stocare locală.

În stocarea locală putem stoca 5-10 megaocteți de informații sau chiar mai mult timp îndelungat.

Lucrul cu stocarea locală

Obiectul localStorage încorporat în browser este proiectat să funcționeze cu stocarea locală. Are 4 metode ușor de înțeles. Iată-le://Salvarea valorii: localStorage.setItem("Cheie", "Valoare"); //Obținerea valorii: var value = localStorage.getItem("Key"); //Eliminarea unei valori: localStorage.removeItem("Cheie"); //Ștergerea întregii stocări: localStorage.clear();

CU

LocalStorage Are 4 metode ușor de înțeles. Iată-le: de asemenea, puteți lucra ca cu o matrice obișnuită: //Salvarea valorii: localStorage["Key"] = "Valoare"; //Obținerea valorii: var value = localStorage["Key"]; //Stergerea unei valori: delete localStorage["Key"];În afară de obiect

există și un obiect

sesiuneStorage

.

După ceva timp primim acest nume înapoi:

Alert(localStorage.getItem(„nume”));

După cum puteți vedea, nu este nimic complicat aici, totul este mult mai simplu decât aceeași lucru cu cookie-urile.

Salvarea obiectelor

Stocarea locală nu este capabilă să stocheze obiecte și matrice JavaScript, deși acest lucru este adesea convenabil. Dar există o modalitate - trebuie să serializați aceste date în format JSON - veți obține un șir care poate fi deja salvat în localStorage.

Apoi, când trebuie să recuperăm acest obiect, convertim șirul din JSON înapoi într-un obiect - și îl folosim cu calm.

Să ne uităm la acest proces cu un exemplu. Să serializăm obiectul și să-l salvăm în stocarea locală:

//Dat un obiect: var obj = (nume: „Ivan”, arr: ); //Serializează-l la "("nume": "Ivan", "arr": )": var json = JSON.stringify(obj); //Scrieți în localStorage cu cheia obj: localStorage.setItem("obj", json);

După ceva timp, primim obiectul înapoi:

//Reduceți datele din localStorage ca JSON: var json = localStorage.getItem("obj"); //Le convertiți înapoi într-un obiect JavaScript: var obj = JSON.parse(json); console.log(obj);

Caracteristici suplimentare

Determinarea numărului de înregistrări în stocare: alert(localStorage.length).

Determinarea numelui unei chei după numărul ei: alert(localStorage.key(number)). La efectuarea operațiunilor cu stocarea, evenimentul este declanșat la depozitare

.

Dacă legați o funcție la acest eveniment, atunci va fi disponibil un obiect Event cu următoarele proprietăți:

funcția func(event) ( var key = event.key; //cheie de date modificabilă var oldValue = event.oldValue; //valoare veche var newValue = event.newValue; //valoare nouă var storageArea = event.storageArea; //storageArea )

Adăuga. material

Stocarea matricei în stocarea locală: https://youtu.be/sYUILPMnrIo

Ce ar trebui să faci în continuare:

• Începeți să rezolvați probleme folosind următorul link: probleme pentru lecție.
  Când decideți totul, treceți la studiul unui subiect nou.
  Lecția nr.

playlist pe YouTube