5.4 Storing Data on the Client side Flashcards
CLIENT-SIDE STORAGE?
term used to refer to several separate APIs. It lets you store data on the client-side (your user browser) instead of a database on a sever
Client-side storage USED FOR ?
- make an app work offiline
- improve an app’s performance by limiting the number of requests to the server
Several options to store data on the client-side?
- cookies, web storage, IndexedDB and caching
APPLICATION CACHING?!
- stores your app’s interface and other data (images, sound files, icons, CSS files, JS files) directly in the browser. Every browser has a built-in cache so that asset files don’t need to be requested every time a user loads a new page on a website.
OFFLINE STORAGE? (client-side storage)
- saves user-related data.
COOKIES?
HTTP cookies allow you to save a small amount of data. The server then sends the data to the client via HTTP, and vice versa. Every time the client makes a request to the server, cookies get sent along automatically, and you can extract from them data on both the client- and the server-side. This data is typically checked to see if requests are coming from the same client or user.
- they’re sent along with every HTTP request so create as few cookies as possible for ur apps to reduce request size
PERSISTENT cookies, SESSION cookies, ZOMBIE cookies
- persistent - can store data until the cookie expires
- SESSION - doesn’t have an expiration date set and will be deleted when the browser is closed (more secure)
- ZOMBIE - automatically recreated right after deletion - done by storing the original cookie’s content outside of the web browser dedicated cookie storage (used for activities such as tracking the number of unique users a product has)
USING COOKIES in JS
Cookies are saved as key-value pairs. You can read, write, and edit cookies in JavaScript using the document.cookie 🎉interface, and you can also define when to delete them. It makes sense to set an expiration date for a cookie for security reasons; for example, you may want users to log out automatically if they haven’t been online for two months. If the user comes back after this time, the cookie will have expired, and the user will have to log in again manually.
HTML5 Web Storage
- new version of cookies, except that your data isn’t transmitted to the server along with every HTTP or HTTPS call.
- allows you to save data in the browser by storing key-value pairs. The data stored must be in string format, which means that if you wanted to store a JavaScript object, you’d need to convert it to a string.
- provides two mechanisms for storing data in the browser: localStorage and sessionStorage
HTML5 localStorage
- data placed in localStorage is “per origin” - means it can be accessed and stored by pages from the same origin. Npr data stored in localStorage on https://careerfoundry.com can only be accessed by other scripts that run on https://careerfoundry.com
- this is what’s known as same-origin policy
- localStorage is useful if you want to pre-populate your app with data when the user starts or opens your application. If, for example, you were building your chat application for the browser (as well as mobile), you could save users’ messages in localStorage. This way, when a user opens the app, they’d be able to see the last messages they sent or received without having to wait for the app to request data from the server.
same-origin policy?
a security concept that allows a web page to access data in a second page only if it has the same origin. With this policy, it’s impossible for a script to read specific data when it doesn’t share the same origin. As such, https://myportfoliopage.com can’t access data stored in localStorage on https://careerfoundry.com, but it could read and use images, CSS, and JavaScript files not protected by the same-origin policy.
HTML5 sessionStorage
- second mechanism provided by the Web Storage API for storing data locally
- per-origin-per-tab, which means that the same-origin-policy applies and data is only available in one browser tab
To decide between localStorage or sessionStorage
- think about what your data is for and how saving data benefits your user.
- let’s say you have several forms on your website, each requiring a name and email address, and you’re expecting users to fill out and submit more than one form during their session. In this instance, once the user has entered their data into one form, you can save it in sessionStorage, then use it to pre-populate the other forms. As soon as the user finishes and closes their browser tab, sessionStorage will be cleared and their data will no longer be accessible to you (or any other person trying to read your app’s storage data illegally!).
Choosing a storage option can also be a matter of security: if you have to store personal data like email addresses or physical addresses, save them in sessionStorage so they aren’t persistent.
When not to use Web Storage
f you want to save a big JavaScript object in localStorage you’d have to convert it into a string first. Then, when retrieving the data from storage, you’d have to convert it back into an object in your JavaScript code. Because of this, you can’t save structured data in web storage, and you can’t get a specific value from stored items because you can’t query them. Instead, you have to fetch the whole string, convert it into an object, then get the desired value from the object.
Now, imagine you have 1,000 objects, and of those objects, you only need those that have a color property set to ‘green’. To find the data you require, you’d have to iterate over every object individually = SRANJE
IndexedDB?!
IndexedDB, has no storage limits. It’s a NoSQL database that saves your data as objects with key-value pairs, allowing you to create queries to fetch your desired data.
Like localStorage, your saved data won’t expire, and the same-origin policy is applied, so you can only fetch data from the same origin. What’s more, you can use IndexedDB in every modern browser.
