Share
En av de mer intressanta utvecklingen i webbstandarder på senare tid är Indexed Database (IndexedDB for short) -specifikation. För en rolig tid kan du läsa specen själv. I denna handledning ska jag förklara denna funktion och förhoppningsvis ge dig inspiration att använda den här kraftfulla funktionen själv.
Som en specifikation är IndexedDB för närvarande en kandidatrekommendation.
I ett nötskal kan IndexedDB ge dig möjlighet att lagra stora mängder data i användarens webbläsare. Alla applikationer som behöver skicka mycket data över ledningen kan i stor utsträckning dra nytta av att kunna lagra den data på klienten i stället. Naturligtvis är lagring endast en del av ekvationen. IndexedDB ger också ett kraftfullt indexerat baserat sök API för att hämta de data du behöver.
Du kanske undrar hur IndexedDB skiljer sig från andra lagringsmekanismer?
Cookies är extremt välskötta, men har juridiska konsekvenser och begränsat lagringsutrymme. Också - de skickas fram och tillbaka till servern med varje förfrågan, vilket helt och hållet upphäver fördelarna med klientsidans lagring.
Lokal lagring är också mycket bra, men begränsad när det gäller den totala lagringsutrymmet du kan använda. Lokal lagring ger inte ett riktigt "sök" API eftersom data bara hämtas via nyckelvärden. Lokal lagring är utmärkt för "specifika" saker som du kanske vill lagra, till exempel inställningar, medan IndexedDB passar bättre för Ad hoc-data (ungefär som en databas).
Innan vi går vidare, låt oss ha ett ärligt tal om tillståndet IndexedDB när det gäller webbläsarstöd. Som en specifikation är IndexedDB för närvarande en kandidatrekommendation. Vid den här tiden är folk bakom specifikationen nöjda med det, men letar nu efter återkoppling från utvecklingssamhället. Specifikationen kan ändras mellan nu och sista steget, W3C-rekommendation. I allmänhet gör de webbläsare som stöder IndexedDB nu på ett ganska konsekvent sätt, men utvecklare bör vara beredda att hantera prefix och notera uppdateringar i framtiden.
När det gäller de webbläsare som stöder IndexedDB har du lite av ett dilemma. Support är ganska bra för skrivbordet, men praktiskt taget obefintlig för mobilen. Låt oss se vad excellent webbplats CanIUse.com säger:
Chrome för Android stöder funktionen, men väldigt få personer använder för närvarande den webbläsaren på Android-enheter. Anger bristen på mobilt stöd att du inte ska använda den? Självklart inte! Förhoppningsvis är alla våra läsare bekanta med begreppet progressiv förbättring. Funktioner som IndexedDB kan läggas till din applikation på ett sätt som inte kommer att bryta i icke-stödda webbläsare. Du kan använda wrapper-bibliotek för att växla till WebSQL på mobilen, eller helt enkelt hoppa över lagring av data lokalt på dina mobila klienter. Personligen tror jag att möjligheten att cache stora block av data på klienten är viktigt att använda nu även utan mobilt stöd.
Vi har täckt specifikationen och supporten, nu ska vi titta på användningen av funktionen. Det allra första vi bör göra är att söka efter IndexedDB-support. Även om det finns verktyg där ute som ger generiska sätt att söka efter webbläsarfunktioner, kan vi göra det mycket enklare eftersom vi bara söker efter en viss sak.
Accentsconagua
document.addEventListener ("DOMContentLoaded", funktion () if ("indexedDB" i fönstret) console.log ("JA !!! Jag kan göra det !!! WOOT !!!"); else console.log ("Jag har en ledsen.");, Falskt); Kodstycket ovan (tillgängligt i test1.html om du laddar ner zip-filen som bifogas denna artikel) använder du DOMContentLoaded händelse att vänta på att sidan ska laddas. (Ok, det är typiskt uppenbart, men jag vet att det här kanske inte är bekant för folk som bara har använt jQuery.) Jag ser helt enkelt om indexedDB finns i fönster objekt och i så fall är det bra att gå. Det är det enklaste exemplet, men vi brukar troligen vilja lagra det så vi vet senare om vi kan använda funktionen. Här är ett lite mer avancerat exempel (test2.html).
var idbSupported = false; document.addEventListener ("DOMContentLoaded", funktion () if ("indexedDB" i fönstret) idbSupported = true;, false); Allt jag har gjort skapas en global variabel, idbSupported, som kan användas som en flagga för att se om den aktuella webbläsaren kan använda IndexedDB.
IndexedDB, som du kan tänka dig, använder databaser. För att vara uppenbart är detta inte en SQL Server-implementering. Den här databasen är lokal i webbläsaren och är endast tillgänglig för användaren. IndexedDB-databaser följer samma regler som cookies och lokal lagring. En databas är unik för domänen den laddades från. Så till exempel kommer en databas som heter "Foo" skapad på foo.com inte att störa en databas med samma namn på goo.com. Det kommer inte bara att vara konflikt, det kommer inte att vara tillgängligt för andra domäner också. Du kan lagra data för din webbplats och veta att en annan webbplats inte kommer att kunna komma åt den.
Att öppna en databas görs via det öppna kommandot. I grundanvändningen anger du ett namn och en version. Versionen är mycket viktigt för att jag täcker mer senare. Här är ett enkelt exempel:
var openRequest = indexedDB.open ("test", 1); Att öppna en databas är en asynkron operation. För att hantera resultatet av den här åtgärden måste du lägga till några händelsehörare. Det finns fyra olika typer av händelser som kan sparkas:
Du kan noga gissa vilken framgång och fel som innebär. Den uppgraderade händelsen används både när användaren först öppnar databasen och när du ändrar versionen. Blockerad är inte något som kommer att hända vanligtvis, men kan avfyra om en tidigare anslutning aldrig stängdes.
Vanligtvis vad som ska hända är att vid den första träffen på din webbplats kommer den uppgraderade händelsen att skjuta. Efter det - bara framgångshanteraren. Låt oss titta på ett enkelt exempel (test3.html).
var idbSupported = false; var db; document.addEventListener ("DOMContentLoaded", funktion () if ("indexedDB" i fönstret) idbSupported = true; om (idbSupported) var openRequest = indexedDB.open ("test", 1); openRequest.onupgradeneeded = function (e) console.log ("Uppgradering ..."); openRequest.onsuccess = funktion (e) console.log ("Succes!"); db = e.target.result; openRequest.onerror = function ) console.log ("Error"); console.dir (e);, felaktigt); Återigen kontrollerar vi om IndexedDB faktiskt stöds, och om det är öppnar vi en databas. Vi har täckt tre händelser här - uppgraderingen behövde händelsen, framgångshändelsen och felhändelsen. För nu fokusera på framgångshändelsen. Händelsen skickas via en handlare via target.result. Vi har kopierat det till en global variabel som heter db. Detta kommer vi att använda senare för att faktiskt lägga till data. Om du kör detta i din webbläsare (i en som stöder IndexedDB förstås!), Ska du se uppgraderings- och framgångsmeddelandet i din konsol första gången du kör skriptet. Den andra, och så vidare, gånger du kör skriptet bör du bara se framgångsbudskapet.
Hittills har vi kontrollerat IndexedDB-support, bekräftat det och öppnat en anslutning till en databas. Nu behöver vi en plats för att lagra data. IndexedDB har ett koncept av "Objektbutiker". Du kan tänka på detta som en typisk databas tabell. (Det är mycket mer lös än en typisk databastabell, men oroa dig inte om det nu.) Objektbutiker har data (självklart) men också en knappsats och en valfri uppsättning index. Keypaths är i grunden unika identifierare för dina data och kommer i några olika format. Indexerna kommer att täckas senare när vi börjar prata om att hämta data.
Nu för något viktigt. Kom ihåg den uppgraderade händelsen som nämnts tidigare? Du kan bara skapa objektaffärer under en uppgraderad händelse. Nu - som standard - detta körs automatiskt första gången en användare träffar din webbplats. Du kan använda detta för att skapa dina objektaffärer. Det viktiga att komma ihåg är att om du någonsin behöver ändra Ditt objekt lagrar, du måste uppgradera versionen (tillbaka i den öppna händelsen) och skriva kod för att hantera dina ändringar. Låt oss titta på ett enkelt exempel på detta i åtgärd.
var idbSupported = false; var db; document.addEventListener ("DOMContentLoaded", funktion () if ("indexedDB" i fönstret) idbSupported = true; om (idbSupported) var openRequest = indexedDB.open ("test_v2", 1); openRequest.onupgradeneeded = function (e) console.log ("running upupgradeneeded"); var thisDB = e.target.result; om (! thisDB.objectStoreNames.contains ("firstOS")) thisDB.createObjectStore ("firstOS"); openRequest .onsuccess = funktion (e) console.log ("Succes!"); db = e.target.result; openRequest.onerror = funktion (e) console.log ("Error"); console.dir );, felaktigt); Detta exempel (test4.html) bygger på tidigare poster så jag bara fokuserar på det som är nytt. Inom den uppgraderade händelsen har jag utnyttjat databasvariablerna som skickats till den (thisDB). En av egenskaperna för denna variabel är en lista över befintliga objektbutiker som heter objectStoreNames. För folk som är nyfiken är detta inte en enkel array men en "DOMStringList". Fråga mig inte - men där går du. Vi kan använda innehåller metod för att se om vårt objekt butik finns och om inte, skapa det. Detta är en av de få synkrona funktionerna i IndexedDB, så vi behöver inte lyssna på resultatet.
För att sammanfatta då - det här är vad som skulle hända när en användare besöker din webbplats. Första gången de är här, brinner den uppgraderade händelsen. Koden kontrollerar om en objektaffär, "firstOS" existerar. Det kommer inte. Därför - det skapas. Då körs framgångshanteraren. Andra gången de besöker webbplatsen kommer versionsnumret att vara detsamma så att den uppgraderade händelsen är inte sparken.
Tänk nu att du ville lägga till en andra objektaffär. Allt du behöver göra är att öka versionsnumret och i princip duplicera innehållet / createObjectStore-kodblocket som du ser ovan. Det snygga är att din uppgraderade kod kommer att stödja både personer som är helt nya på webbplatsen och de som redan hade den första objektaffären. Här är ett exempel på detta (test5.html):
var openRequest = indexedDB.open ("test_v2", 2); openRequest.onupgradeneeded = function (e) console.log ("running upupgradeneeded"); var thisDB = e.target.result; om (! thisDB.objectStoreNames.contains ("firstOS")) thisDB.createObjectStore ("firstOS"); om (! thisDB.objectStoreNames.contains ("secondOS")) thisDB.createObjectStore ("secondOS"); När du har fått dina objektaffärer redo kan du börja lägga till data. Detta är - kanske - en av de coolaste aspekterna av IndexedDB. Till skillnad från traditionella tabellbaserade databaser låter IndexedDB dig lagra ett objekt som det är. Vad det betyder är att du kan ta ett generiskt JavaScript-objekt och bara lagra det. Gjort. Självklart finns det några tillvägagångssätt här, men för det mesta är det det.
Att arbeta med data kräver att du använder en transaktion. Transaktioner tar två argument. Den första är en uppsättning bord som du ska arbeta med. För det mesta blir det ett bord. Det andra argumentet är typen av transaktion. Det finns två typer av transaktioner: readonly och readwrite. Lägga till data kommer att vara en skrivskrivningsoperation. Låt oss börja med att skapa transaktionen:
// Antag att db är en databasvariabel som öppnades tidigare var transaction = db.transaction (["people"], "readwrite");
Observera objektaffären, "folk", är bara en som vi har gjort i exemplet ovan. Vår nästa fullständiga demo kommer att utnyttja den. Efter att ha tagit transaktionen frågar du det för objektaffären du sa att du skulle arbeta med:
var butik = transaction.objectStore ("people"); Nu när du har butiken kan du lägga till data. Detta görs via - vänta på det - Lägg till metod.
// Definiera en person var person = namn: namn, email: email, created: new Date () // Utför add var request = store.add (person, 1);
Kom ihåg tidigare vi sa att du kan lagra vilken data du vill ha (för det mesta). Så mitt personobjekt ovan är helt godtyckligt. Jag kunde ha använt förnamn och efternamn istället för att bara namnge. Jag kunde ha använt en könsegenskap. Du får idén. Det andra argumentet är nyckeln som används för att unikt identifiera data. I det här fallet har vi svårt kodat det till 1 vilket kommer att orsaka ett problem ganska snabbt. Det är okej - vi lär oss hur du åtgärdar det.
Tilläggsoperationen är ascynkron, så det går att lägga till två händelsehanterare för resultatet.
request.onerror = function (e) console.log ("Error", e.target.error.name); // någon typ av felhanterare request.onsuccess = function (e) console.log ("Woot! Did it"); Vi har en onerror hanterare för fel och onsuccess för goda förändringar. Lätt uppenbart, men låt oss se ett komplett exempel. Du hittar det här i filen test6.html.
Exemplet ovan innehåller en liten blankett med en knapp för att avaktivera en händelse för att lagra data i IndexedDB. Kör detta i din webbläsare, lägg till något i formulärfälten och klicka på Lägg till. Om du har din webbläsares devverktyg öppna ska du se något så här.
Det här är en bra tid att påpeka att Chrome har en utmärkt tittare för IndexedDB-data. Om du klickar på fliken Resurser, expandera IndexedDB-sektionen, kan du se databasen som skapats av den här demoen såväl som objektet som just har skrivits in.
För käften av det, gå och slå den Lägg till Data-knappen igen. Du bör se ett fel i konsolen:
Felmeddelandet ska vara en ledtråd. ConstraintError betyder att vi bara försökte lägga till data med samma nyckel som en som redan existerade. Om du kommer ihåg, kodade vi den nyckeln och vi visste det skulle bli ett problem. Det är dags att prata nycklar.
Nycklarna är IndexedDB: s version av primära nycklar. Traditionella databaser kan ha tabeller utan nycklar, men varje objektaffär behöver ha en nyckel. IndexedDB möjliggör ett par olika typer av nycklar.
Det första alternativet är att bara ange det själv, som vi gjorde ovan. Vi kunde använda logik för att skapa unika nycklar.
Ditt andra alternativ är ett tangentbord, där nyckeln är baserad på en egenskap av dataen själv. Tänk på vårt folk exempel - vi kan använda en e-postadress som en nyckel.
Ditt tredje alternativ, och enligt min mening det enklaste, är att använda en nyckelgenerator. Det fungerar som en autonummer primär nyckel och är den enklaste metoden att specificera nycklar.
Nycklar definieras när objektaffärer skapas. Här är två exempel - en som använder en nyckelväg och en en generator.
thisDb.createObjectStore ("test", keyPath: "email"); thisDb.createObjectStore ("test2", autoIncrement: true); Vi kan ändra vår tidigare demo genom att skapa en objektaffär med en autoIncrement-nyckel:
thisDB.createObjectStore ("people", autoIncrement: true); Slutligen kan vi ta det tillägg som vi använde tidigare och ta bort den hårdkodade nyckeln:
var request = store.add (person);
Det är allt! Nu kan du lägga till data hela dagen. Du kan hitta den här versionen i test7.html.
Låt oss nu byta till att läsa enskilda bitar av data (vi kommer att täcka läsning av större datasatser senare). Återigen görs detta i en transaktion och blir asynkron. Här är ett enkelt exempel:
var transaction = db.transaction (["test"], "readonly"); var objectStore = transaction.objectStore ("test"); // x är något värde var ob = objectStore.get (x); ob.onsuccess = funktion (e) Observera att transaktionen endast är läsad. API-samtalet är bara ett enkelt få samtal med nyckeln som skickats in. Som en snabb sida, om du tycker att använda IndexedDB är lite verbose, notera att du kan kedja många av dessa samtal också. Här är exakt samma kod som skrivs mycket hårdare:
db.transaction (["test"], "readonly"). objektStore ("test"). få (X) .onsuccess = funktion (e) Personligen hittar jag fortfarande IndexedDB lite komplicerat så jag föredrar "brutit ut" -metoden för att hjälpa mig att hålla reda på vad som händer.
Resultatet av get's onsuccess handler är föremålet du lagrade tidigare. När du har det objektet kan du göra vad du vill. I vår nästa demonstration (test8.html) Vi har lagt till ett enkelt formulärfält för att låta dig skriva in en nyckel och skriva ut resultatet. Här är ett exempel:
Hanteraren för Get Data-knappen är nedan:
funktion getPerson (e) var nyckel = document.querySelector ("# key"). värde; om (nyckel === "" || ärNaN (nyckel)) returnera; var transaction = db.transaction (["people"], "readonly"); var butik = transaction.objectStore ("people"); var request = store.get (Nummer (nyckel)); request.onsuccess = funktion (e) var result = e.target.result; console.dir (resultat); om (resultat) var s = "Nyckel "+ nyckel +"
"; för (var-fält i resultat) s + = fält +" = "+ resultat [fält] +"
"; document.querySelector (" # status "). innerHTML = s; else document.querySelector (" # status "). innerHTML ="
Ingen match
"; För det mesta bör detta vara självförklarande. Hämta värdet från fältet och kör ett fåtal på objektaffären som erhållits från en transaktion. Observera att displaykoden helt enkelt blir Allt fälten och dumper dem ut. I en riktig applikation skulle du (förhoppningsvis) veta vad dina uppgifter innehåller och arbeta med specifika områden.
Så det är så du skulle få en bit data. Vad sägs om a massa av data? IndexedDB har stöd för vad som kallas en markör. En markör låter dig iterera över data. Du kan skapa markörer med ett valfritt sortiment (ett grundfilter) och en riktning.
Som ett exempel öppnar följande kodblock en markör för att hämta all data från en objektaffär. Precis som allt annat vi har gjort med data är detta asynkront och i en transaktion.
var transaction = db.transaction (["test"], "readonly"); var objectStore = transaction.objectStore ("test"); var markör = objectStore.openCursor (); markör.onsuccess = funktion (e) var res = e.target.result; om (res) console.log ("Key", res.key); console.dir ("Data", res.value); res.continue (); Succeshanteraren passerar ett resultatobjekt (variabeln ovanför). Den innehåller nyckeln, objektet för data (i värdetasten ovan) och en fortsättningsmetod som används för att iterera till nästa data.
I följande funktion har vi använt en markör för att iterera över alla objektmarknadsdata. Eftersom vi arbetar med "person" data har vi kallat detta getPeople:
funktion getPeople (e) var s = ""; db.transaction (["people"], "readonly"). objektStore ("people"). openCursor (). onsuccess = funktion (e) var markör = e.target.result; om (markör) s + = "Key "+ cursor.key +"
"; för (var-fält i markör.value) s + = fält +" = "+ markör.värde [fält] +"
"; s + ="
"; cursor.continue (); document.querySelector (" # status2 "). innerHTML = s; Du kan se en fullständig demo av detta i din nedladdning som fil test9.html. Den har en Add Person logik som i tidigare exempel, så enkelt skapa några personer och tryck sedan på knappen för att visa all data.
Så nu vet du hur man får en bit data samt hur man får all data. Låt oss nu slå vårt sista ämne - arbeta med index.
Vi har pratat om IndexedDB för hela artikeln, men har ännu inte gjort några bra index. Indexer är en viktig del av IndexedDB-objektaffärer. De ger ett sätt att hämta data baserat på deras värde samt att ange om ett värde ska vara unikt i en butik. Senare visar vi hur du använder index för att få en rad data.
Först - hur skapar du ett index? Precis som allt annat strukturellt måste de ske i en uppgraderingshändelse, i grund och botten samtidigt skapar du objektobjektet. Här är ett exempel:
var objectStore = thisDb.createObjectStore ("people", autoIncrement: true); // första arg är namnet på index, andra är sökvägen (col); objectStore.createIndex ("namn", "namn", unikt: false); objectStore.createIndex ("email", "email", unique: true); I första raden skapar vi affären. Vi tar det resultatet (ett objektStore-objekt) och kör createIndex metod. Det första argumentet är namnet på indexet och det andra är egenskapen som ska indexeras. I de flesta fall tror jag att du kommer att använda samma namn för båda. Det sista argumentet är en uppsättning alternativ. För närvarande använder vi bara en, unik. Det första indexet för namn är inte unikt. Den andra för e-post är. När vi lagrar data kontrollerar IndexedDB dessa index och ser till att e-postegenskapen är unik. Det kommer också att göra viss datahantering på baksidan för att säkerställa att vi kan hämta data av dessa index.
Hur fungerar det? När du hämtat en objektaffär via en transaktion kan du sedan begära ett index från den butiken. Med hjälp av koden ovan är här ett exempel på det:
var transaction = db.transaction (["people"], "readonly"); var butik = transaction.objectStore ("people"); var index = store.index ("name"); // namn är något värde var request = index.get (namn); Först får vi transaktionen, följt av affären och sedan index. Som vi tidigare sagt kan du kedja de första tre linjerna för att göra det lite kompaktare om du vill.
När du har ett index kan du sedan utföra en skaffa sig Ring på det för att hämta data med namn. Vi kan också göra något liknande för e-post. Resultatet av det här samtalet är ännu ett asynkront objekt som du kan binda en onsuccess handler till. Här är ett exempel på den hanteraren som finns i filen test10.html:
request.onsuccess = funktion (e) var result = e.target.result; om (resultat) var s = "Namn "+ namn +"
"; för (var-fält i resultat) s + = fält +" = "+ resultat [fält] +"
"; document.querySelector (" # status "). innerHTML = s; else document.querySelector (" # status "). innerHTML ="Ingen match
";
Observera att ett index skaffa sig samtal kan returnera flera objekt. Eftersom vårt namn inte är unikt bör vi antagligen ändra koden för att hantera det, men det är inte nödvändigt.
Låt oss nu sparka upp det. Du har sett med hjälp av get API på indexet för att få ett värde baserat på den egenskapen. Vad händer om du vill få en bredare uppsättning data? Den sista terminen vi ska lära oss idag är Ranges. Rangordna är ett sätt att välja en delmängd av ett index. Till exempel, med ett index på en namnegenskap, kan vi använda ett intervall för att hitta namn som börjar med A upp till namn som börjar med C. Ranges kommer i några olika sorter. De kan vara "allt under någon markör", "allt ovanför någon markör" och "något mellan en lägre markör och en högre markör." Slutligen, bara för att göra saker intressanta, kan intervall vara inkluderande eller exklusiva. I grund och botten betyder det för ett intervall från A-C, kan vi ange om vi vill inkludera A och C i intervallet eller bara värdena mellan dem. Slutligen kan du också begära både stigande och nedåtgående intervall.
Rangord skapas med ett toplevel-objekt som heter IDBKeyRange. Det har tre metoder av intresse: nedre_gräns, övre gräns, och bunden. nedre_gräns används för att skapa ett intervall som börjar till ett lägre värde och returnerar all data "ovanför" den. övre gräns är motsatsen. Och slutligen - bunden används för att stödja en uppsättning data med både en nedre och övre gräns. Låt oss titta på några exempel:
// Värden över 39 var oldRange = IDBKeyRange.lowerBound (39); // Värden 40a dn över var oldRange2 = IDBKeyRange.lowerBound (40, true); // 39 och mindre ... var youngRange = IDBKeyRange.upperBound (40); // 39 och mindre ... var youngRange2 = IDBKeyRange.upperBound (39, true); // inte ung eller gammal ... du kan också ange inkluderande / exklusiv var okRange = IDBKeyRange.bound (20,40)
När du har en räckvidd kan du skicka den till ett indexs openCursor-metod. Detta ger dig en iterator att slingra över de värden som matchar det här intervallet. Som ett praktiskt sätt är det inte egentligen en sökning i sig. Du kan använda detta för att söka efter innehåll baserat på början av en sträng, men inte mitten eller slutet. Låt oss titta på ett komplett exempel. Först ska vi skapa en enkel form för att söka folk:
Börjar med:
Slutar med:
Vi ska tillåta sökningar som består av någon av de tre typerna av intervall (igen, ett värde och högre, ett högsta värde eller värdena inom två ingångar). Låt oss nu titta på händelsehanteraren för det här formuläret.
funktion getPeople (e) var name = document.querySelector ("# nameSearch"). värde; Var endname = document.querySelector ("# nameSearchEnd"). värde; om (name == "" && endname == "") returnera; var transaction = db.transaction (["people"], "readonly"); var butik = transaction.objectStore ("people"); var index = store.index ("name"); // Gör intervallet beroende på vilken typ vi gör var intervall; om (name! = "" && endname! = "") range = IDBKeyRange.bound (namn, efternamn); annars om (namn == "") range = IDBKeyRange.upperBound (efternamn); annat range = IDBKeyRange.lowerBound (namn); var s = ""; index.openCursor (range) .onsuccess = funktion (e) var markör = e.target.result; om (markör) s + = "Key "+ cursor.key +"
"; för (var-fält i markör.value) s + = fält +" = "+ markör.värde [fält] +"
"; s + ="
"; cursor.continue (); document.querySelector (" # status "). innerHTML = s; Från topp till botten börjar vi med att ta tag i de två formulärfälten. Därefter skapar vi en transaktion och därmed får affären och indexet. Nu för den halvkomplexa delen. Eftersom vi har tre olika typer av intervall måste vi stödja att vi måste göra lite villkorlig logik för att ta reda på vilka vi behöver. Vilket intervall vi skapar bygger på vilka fält du fyller i. Vad som är bra är att när vi har sortimentet, skickar vi det enkelt till indexet och öppnar markören. Det är allt! Du kan hitta detta fullständiga exempel i test11.html. Var noga med att ange några värden först så att du har data att söka.
Tro det eller inte - vi har bara börjat vår diskussion om IndexedDB. I nästa artikel täcker vi ytterligare ämnen, inklusive uppdateringar och raderingar, arraybaserade värden och några allmänna tips för att arbeta med IndexedDB.
