SessionStorage and LocalStorage are synchronous, so not good for storing huge information, and unnecessary converting back and forth from JSON is also pain.
IndexedDb should be preferred to store large information, ideally Session/LocalStorage should only be used to store simple numeric values, current avatar etc.
I covered, at several points in the article, that session/local storage are not for storing huge chunks of information. And you're absolutely right that converting back-and-forth from JSON is a pain. That's why I created the wrapper class. It's not a pain if it requires nothing more than
I agree that I didn't touch on IndexedDB. But with use of the wrapper class, there's absolutely no reason why anyone should feel confined to "simple numeric values, current avatar, etc." You can easily store, say, an array with 20 elements, or an object with 50 properties. In fact, if you had, say, 50 unique objects you wanted to store, each holding 3-30 properties, then using IndexedDB for that would be a lotta overkill.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
SessionStorage and LocalStorage are synchronous, so not good for storing huge information, and unnecessary converting back and forth from JSON is also pain.
IndexedDb should be preferred to store large information, ideally Session/LocalStorage should only be used to store simple numeric values, current avatar etc.
I covered, at several points in the article, that session/local storage are not for storing huge chunks of information. And you're absolutely right that converting back-and-forth from JSON is a pain. That's why I created the wrapper class. It's not a pain if it requires nothing more than
I agree that I didn't touch on IndexedDB. But with use of the wrapper class, there's absolutely no reason why anyone should feel confined to "simple numeric values, current avatar, etc." You can easily store, say, an array with 20 elements, or an object with 50 properties. In fact, if you had, say, 50 unique objects you wanted to store, each holding 3-30 properties, then using IndexedDB for that would be a lotta overkill.