DEV Community

Simple Javascript Modules - Local Storage Module

Sooraj (PS) on June 26, 2021

Working as a web developer I work on the client side dealing with lots of continuous data from the server. All though it is a good practice to not ...

Read full post

Mihail Malo • Jun 29 '21 • Edited

I'm sorry, but this code makes no sense and is frankly confusing and dangerous.
It doesn't really add any convenience over just using window.localStorage directly, besides the JSON conversion.
This can be achieved with just

export class JSONStorage {
  constructor(storage) {
    if (!storage || typeof storage !== "object")
      throw new Error(`Expected a Storage object, got ${storage}`)
    this.storage = storage
  }
  set(k, v) {
    const str = JSON.stringify(v)
    if (typeof str === "undefined")
      return this.storage.removeItem(k)
    this.storage.setItem(k, v)
  }
  get(k) {
    const str = this.storage.getItem(k)
    // we return `undefined` instead of `null`, so that we can differentiate between the cases when the key doesn't exist vs when the value is a JSON-serialized `"null"`
    if (str === null) return
    return JSON.parse(str)
  }
  remove(k) {
    this.storage.removeItem(k)
  }
}

you can try it as follows

const a = new JSONStorage(window.localStorage)
const b = new JSONStorage(window.sessionStorage)
a.set("1", 1)
b.set("1", 2)
// notice that keys are coerced to string automatically, and we get back deserialized numbers, not strings
a.get(1) // 1
b.get(1) // 2

Instead, the provided code:

checks if localStorage is supported on every action, instead of just once.
calls .getItem(key) twice, which might be the most expensive operation here, short of setItem
similarly, calls getItem before removeItem
since !"" is true, empty values (if created outside this interface) will never be removed!
uses a mutable field data on the singleton object instead of a local variable. This data never needs to survive beyond a function call, and is being reused by all accesses to Storage.
constructs a {key, data} object with the function's arguments, which will never be used and doesn't offer any ergonomic benefit.
declares a function to just set null to this.data.
on most error conditions (such as passing a number as key, because numbers don't have .length), randomly returns the contents of this.data, which will always be null because every method, even remove that doesn't use it first calls clearData. This is confusing, since the standard getItem returns null for missing key, and "null" is a valid JSON string.
makes an object instance named Storage to then just export it as default, instead of exporting the individual functions, avoiding a layer of indentation.

PS: ~~Keep in mind, my code still doesn't prevent you from calling, say, b.set() which would create a undefined => undefined entry, which would cause a JSON SyntaxError when calling b.get(),~~ nor does it exhaustively check for the storage object passed to the constructor having the necessary methods.

Edit: The former is quite serious, so I fixed it now. This now removes the key, so setting a value of undefined and then getting it will, in fact, return undefined

Sooraj (PS) • Jun 29 '21

Thank you for the informative points :)

Comment hidden by post author - thread only accessible via permalink

John Smith • Jun 27 '21

No one is holding you at gunpoint forcing you to read articles. If you don't like the content, leave the article and move on. I don't see how it's a bad thing for developers to be improving their skills (both communication and coding) by writing articles anywhere they want to. Frequently English is not someone's first language, and writing articles about what you're learning is a great way to get feedback and practice, and the urge to teach other people skills you've learned should be applauded.

I've always thought it's quite interesting to watch people gain new skills and learn new things, considering all of us do that on a regular basis.

Perhaps it would be more productive to offer constructive feedback about particular things authors could improve upon rather than criticizing an article as a whole. In my experience, that helps developers learn to improve, as opposed to sarcastic and generalized criticism, which just discourages authors from making attempts and continuing to improve in the future. Practice makes perfect, and writing an article is a great way to work on communication skills.

Sooraj (PS) • Jun 27 '21

Thank you John :)

Comment hidden by post author - thread only accessible via permalink

Sooraj (PS) • Jun 27 '21 • Edited

The reason for mentioning "Local Storage" is for beginner developers and developers working on other languages to understand what the word means first. No new developer will right away know what "localStorage" or why the word/function is spelt like that or what it does when they jump into javascript. If I come from other language I would question why localstorage is written as localStorage.

And also I have mentioned "Local Storage" only in a context to understand it is and not in code. So please read the article completely before coming to a conclusion.

Preethi Vuchuru27916 • Jun 26 '21

As a newbie to the concept of Local storage in JavaScript, your comments on the code and explanation made it simple for me to understand. Will be using this to create something in Javascript.