Потребителите харесват уебсайтове. Потребителите обичат да виждат личните си данни на уебсайтове. Потребителите също харесват бисквитки, така че първото нещо, което разработчиците направиха, беше да им дадат бисквитки с техните данни.

Като много от вас, си спомням, че използвах бисквитки, когато за първи път започнах. Току-що направих document.cookie = "rememberme=true" и седнах назад и се възхищавах на лудите си умения.

Простите уебсайтове нямат много нужда от съхранение. В тези случаи бисквитките и сесиите, които ви предлагат възможността да съхранявате постоянни данни при зареждане на страници, работят добре.

Бисквитките съхраняват вашите данни директно в браузъра, който се нарича „клиент“. Сесиите са подобни на бисквитките, но те съхраняват само референтен ключ, който сочи към данни, които се съхраняват на сървъра на уебсайта. Ако съхранявате нещо, което искате да бъде скрито от потребителя, опитайте сесии. Всеки може да разглежда бисквитките, съхранени на компютрите си, да ги променя или изтрива.

Имайте предвид, че една сесия е активна само докато браузърът работи. След като потребителят затвори браузъра, сесията на потребителя приключва. Бисквитките продължават да се съхраняват в клиента в зависимост от датата, която вие (разработчикът) сте задали, когато сте ги създали.

Сега, дълго време, бисквитките и сесиите бяха достатъчни. Но днес ние не създаваме просто уеб сайтове, а уебприложения. Решенията за съхранение са в крак с непрекъснато развиващите се браузъри. Нашите нужди за съхранение на данни нараснаха. Така че нека проучим нов стек, който се появи през последните няколко години, за да запълни тази празнина.

Но нека поговорим за тази празнина за секунда. Защо бисквитките не са добър начин за съхраняване на данни за уеб приложения? Бисквитките ви позволяват да съхранявате само малко количество данни — само 4k. Можете да съхранявате само низове, което означава, че ще трябва да напишете слой от код за парсиране и де-парсинг, който преобразува вашите данни в низове и след това анализира низовете обратно в данни. Това прави вашето приложение по-трудно за разсъждение и податливо на грешки. Освен това, тъй като бисквитките се добавят към всяка HTTP заявка, колкото по-голяма е вашата бисквитка, толкова по-раздути стават вашите заявки. Това са недостатъците на бисквитките.

Някои от тези недостатъци бяха отстранени с появата на нова технология, наречена localStorage. С localStorage получавате прост API, който ви позволява да четете и пишете в Document. Край на странното анализиране на низове, за да получите достъп до вашите данни, защото с localStorage можете просто да

localStorage.setItem('operator', 'G Adventures')
localStorage.getItem('operator')

localStorage идва със собствен набор от недостатъци. Първо, localStorage е синхронен API и работи в една нишка. Така че ще трябва да изчакате, докато постави нещата в базата данни. Трудно е да се използва API на localStorage с услуги или уеб работници поради факта, че той е синхронен. Освен това, приложният програмен интерфейс (API) на localStorage не е нищо повече от хранилище на ключ-стойност, което означава, че все още сте заседнали с тъпи малки низове. Съхраняването на всякакви „истински“ данни (като обект) се превръща в скучна работа, която включва много извиквания на методи катоJSON.stringify(). И накрая, поради много причини, localStorage е бавен.

За да се справят с недостатъците както на localStorage, така и на бисквитките, се появи нова технология: IndexedDB API. Някои от вас може би вече са чували за него. Ще се опитам да обясня как да го използвам и се надявам да подчертая предимствата му.

IndexedDB е хранилище на обекти. Това означава, че можете да съхранявате Javascript обекти в IndexedDB. Не е нужно да стрингифицирате или сериализирате данните си, преди да ги запазите, което е като да поставите балсам върху болезнената рана, която е разработката на JS.

Освен това предимство, IndexedDB е по-лесен за работа, защото е транзакционен и асинхронен (вижте примерите по-долу за илюстрация). Вие четете и пишете в контекста на транзакция; предавате транзакция на браузъра и след това браузърът ви се обажда обратно, когато приключи обработката на вашите данни. Играе добре и в рамките на работниците.

Друга полза от използването на IndexedDB е простият API, който излага. Ако някога сте работили с бази данни преди, като MySQL, може да си спомните отварянето на връзка с база данни. Ето как можете да направите това с IndexedDB.

const request = indexedDB.open('myDB', 1)

1 е версията на вашата база данни. Тъй като вашата база данни може да се промени с течение на времето, версията казва на клиента как да създаде тази конкретна итерация на базата данни.

Следващото нещо, което трябва да научите, е как да настроите първоначалния магазин. Правим това с помощта на събитие, наречено onupgradeneeded.

request.onupgradeneeded = function(event) {
     // code to set up the object store
}

Това, което търсим тук, е event.target.result. Цялата важна информация, която получаваме от събитията на IndexedDB, се намира в тази променлива, така че отбележете я!

Вече можете да създадете магазин за обекти, като го опишете. В примера по-долу обектното хранилище се нарича „съобщения“.

request.onupgradeneeded = function(event) {
    const upgradeDb = event.target.result
    upgradeDb.createObjectStore('messages', {
        keyPath: 'id',
        autoincrement: true
    })
}

Ще забележите, че сме предали createObjecStore обект, който съдържа някои опции. Един от тях е keyPath, който сочи към уникален ключ, който ще бъде на всеки обект.

Имаме друго събитие, което можем да слушаме, наречено onError събитие. Можем да използваме това, за да проверим дали нашата база данни е настроена успешно или нещата са се провалили.

request.onerror = function(event) {
    console.error(event)
}

За да получим достъп до вашата база данни, ще използваме друго събитие, наречено onsuccess.

let db
request.onsuccess = function(event) {
    db = event.target.result
    // our database is successfully set up!
}

Така че след като сте настроили вашата база данни, представете си, че искате да поставите някои данни в нея.

Правим това чрез създаване на транзакция.

const transaction = db.transaction('messages', 'readwrite')
const objectStore = transaction.objectStore('messages')
const message = {
    text: 'Sahi hai!',
    id: 1
}
const request = objectStore.put(message)
request.onsuccess = function(event) {
    console.log(event)
    console.log('worked')
}

Сега да прочетете съобщенията от db. Курсорът ще премине през всяко от съобщенията в магазина и ще върне стойността на всяко съобщение. След това можем да добавим съобщението към списък, както в този пример.

const transaction = db.transaction('messages', 'readonly')
const objectStore = transaction.objectStore('messages')
const request = objectStore.openCursor()
let messageList
request.onsuccess = function(event) {
    const cursor = event.target.results
    if (cursor) {
        messageList.addMessage(cursor.value)
        cursor.continue()
    } else {
        console.log(messageList)
    }
}

Ако искате да научите повече за някое от нещата, за които сте чели тук, моля, вижте тази отлична беседа на Фил Неш: „„Празна база данни в джоба на всеки““. Той навлиза в повече подробности за неща като cursor и изследва IndexedDB по-подробно.

Ще се радваме да видим примери за това как използвате IndexedDB в собствените си проекти в коментарите по-долу!

Продължавайте да ни следвате в Medium и Twitter за още откъси от света на технологиите според G!

Искате ли да помогнете на G Adventures да промени живота на хората и да пътувате по света? Разгледайте всички наши работни места и кандидатствайте днес.