localstorage vs sessionstorage

Author: rohan-paul

Javascript/map-drawbacks-of-old-objects.md renamed to Javascript/New-datatypes-Map-and-drawbacks-of-old-objects.md

@@ -1,6 +1,6 @@
-A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.
+A closure is the combination of a function bundled together (enclosed) with **references to its surrounding state (the lexical environment)**. In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.
 
-A closure is a function that retains access to variables of the context it was created in even after said function call has returned.
+**A closure is a function** that retains access to variables of the context it was created in even after said function call has returned.
 
 ```js
 var awFunc = function (first) {
@@ -21,15 +21,16 @@ console.log(someMoreFunc('some'))  // returns awesome
 
 Among other things, closures are commonly used to give objects data privacy. Data privacy is an essential property that helps us program to an interface, not an implementation. This is an important concept that helps us build more robust software because implementation details are more likely to change in breaking ways than interface contracts.
 
-In JavaScript, closures are the primary mechanism used to enable data privacy. When you use closures for data privacy, the enclosed variables are only in scope within the containing (outer) function. You can’t get at the data from an outside scope except through the object’s privileged methods. In JavaScript, any exposed method defined within the closure scope is privileged. For example:
+To use a closure, simply define a function inside another function and expose it. To expose a function, return it or pass it to another function.
+
+#### In JavaScript, closures are the primary mechanism used to enable data privacy. When you use closures for data privacy, the enclosed variables are only in scope within the containing (outer) function. You can’t get at the data from an outside scope except through the object’s privileged methods. In JavaScript, any exposed method defined within the closure scope is privileged. For example:
 
 ```js
 const getSecret = (secret) => {
     return {
         getPrivileged: () => secret
     }
 }
-
 ```
 
 In the example above, the `.getPrivileged()` method is defined inside the scope of `getSecret()`, which gives it access to any variables from `getSecret()`, and makes it a privileged method. In this case, the parameter, `secret`.

Javascript/closure.md

@@ -1,4 +1,4 @@
-### Transform the following code with
+### Transform the following code with sequential execution.  I want to fire second request based on one value returned by the first request.
 
 ```js
 fetch("https://api.com/values/1")
@@ -18,4 +18,11 @@ const request = async () => {
 request();
 ```
 
-In the first line, we make a GET request to https://api.com/values/1. Instead of continuing to the next line, we wait for the request to finish, hence await. When it finishes, it passes the resolved value to the response variable.
+In the first line, we make a GET request to https://api.com/values/1. Instead of continuing to the next line, we wait for the request to finish, hence await. When it finishes, it passes the resolved value to the *response* variable.
+
+In the second line, we get the JSON version of the response. Again, we use await so we can wait for it to complete (or fail) and then pass the result to the json variable.
+
+
+#### Further Reading
+
+https://dev.to/johnpaulada/synchronous-fetch-with-asyncawait

Javascript/sequential-execution-of-codes-React-Node-Context/Async-Event-Handler-both-async-await-and-with-Promise-1.md renamed to Javascript/sequential-execution-of-codes-React-Node-Context-Master-Notes/Async-Event-Handler-both-async-await-and-with-Promise-1.md

@@ -1,3 +1,9 @@
+**localStorage** and **sessionStorage** both extend Storage. There is no difference between them except for the intended "non-persistence" of sessionStorage.
+
+**That is, the data stored in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.**
+
+For sessionStorage, changes are only available per tab. Changes made are saved and available for the current page in the that tab until it is closed. Once it is closed, the stored data is deleted.
+
 [From Official Dox](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API)
 
 The two mechanisms within Web Storage are as follows:
@@ -6,29 +12,37 @@ The two mechanisms within Web Storage are as follows:
 
 **localStorage** does the same thing, but persists even when the browser is closed and reopened.
 
-These mechanisms are available via the Window.sessionStorage and Window.localStorage properties (to be more precise, in supporting browsers the Window object implements the WindowLocalStorage and WindowSessionStorage objects, which the localStorage and sessionStorage properties hang off) — invoking one of these will create an instance of the Storage object, through which data items can be set, retrieved and removed. A different Storage object is used for the sessionStorage and localStorage for each origin — they function and are controlled separately.
+These mechanisms are available via the **Window.sessionStorage** and **Window.localStorage** properties (to be more precise, in supporting browsers the Window object implements the WindowLocalStorage and WindowSessionStorage objects, which the localStorage and sessionStorage properties hang off) — invoking one of these will create an instance of the Storage object, through which data items can be set, retrieved and removed. A different Storage object is used for the sessionStorage and localStorage for each origin — they function and are controlled separately.
 
 localStorage and sessionStorage are perfect for persisting non-sensitive data needed within client scripts between pages (for example: preferences, scores in games). The data stored in localStorage and sessionStorage can easily be read or changed from within the client/browser so should not be relied upon for storage of sensitive or security-related data within applications.
 
-#### So sessionStorage (as the name suggests) is only available for the duration of the browser session (and is deleted when the tab or window is closed) - it does, however, survive page reloads (source DOM Storage guide - Mozilla Developer Network). Clearly, if the data you are storing needs to be available on an ongoing basis then localStorage is preferable to sessionStorage. The data stored in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
+#### sessionStorage (as the name suggests) is only available for the duration of the browser session (and is deleted when the tab or window is closed) - it does, however, survive page reloads (source DOM Storage guide - Mozilla Developer Network). Clearly, if the data you are storing needs to be available on an ongoing basis then localStorage is preferable to sessionStorage. The data stored in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.
 
 ### LocalStorage - Some more details
 
 ##### Advantage of localStorage -
+1> Storage limit is the maximum amongst the three
+
+2> One of the most important differences is that unlike with cookies, data does not have to be sent back and forth with every HTTP request. This reduces the overall traffic between the client and the server and the amount of wasted bandwidth. This is because data is stored on the user’s local disk and is not destroyed or cleared by the loss of an internet connection.
 
 ##### Disadvantage of localStorage -
 
-1> It works on same-origin policy. So, data stored will only be available on the same origin.
+1> LocalStorage becomes slower as more data is stored4. For most browsers the time it takes for localStorage.getItem to return increases from a few milliseconds with a near empty storage to over a second with a full storage.
+
+2> It works on same-origin policy. So, data stored will only be available on the same origin.
+
+3> Any JavaScript code on your page can access local storage: it has no data protection whatsoever. This is the big one for security reasons 
 
 ### SessionStorage - Some more details
+1> 
 
 ##### Advantage of sessionStorage -
 
 ##### Disadvantage of sessionStorage -
 
 1> The data is available only inside the window/tab in which it was set.
 
-2> Like localStorage, tt works on same-origin policy. So, data stored will only be available on the same origin.
+2> Like localStorage, it works on same-origin policy. So, data stored will only be available on the same origin.
 
 ### More General Info
 
@@ -41,7 +55,7 @@ The maximum storage available is different per browser, but most browsers have i
 +----------------+--------+---------+-----------+--------+
 | SessionStorage | 10MB | 10MB | Unlimited | 10MB |
 +----------------+--------+---------+-----------+--------+
-Always catch LocalStorage security and quota exceeded errors
+**Always catch LocalStorage security and quota exceeded errors**
 
 QuotaExceededError: When storage limits exceeds on this function window.sessionStorage.setItem(key, value);, it throws a "QuotaExceededError" DOMException exception if the new value couldn't be set. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)
 
@@ -59,5 +73,5 @@ Compared to others, there's no advantages of Cookies
 Stores data that has to be sent back to the server with subsequent requests. Its expiration varies based on the type and the expiration duration can be set from either server-side or client-side (normally from server-side).
 
 Cookies are primarily for server-side reading (can also be read on client-side), localStorage and sessionStorage can only be read on client-side.
-Size must be less than 4KB.
+Cookies Size must be less than 4KB.
 Cookies can be made secure by setting the httpOnly flag as true for that cookie. This prevents client-side access to that cookie