Today was a day with some more cleanup. Now we're at a point where we need to refactor, the biggest, baddest controller there is. The layout controller. It's a big beast that has grown uncontrollably over the years. So before we start on that series, which will likely be a angularjs to angular typescript migration series, this will be the last of the linting ones.

There is one pattern that I encountered today, which normally isn't a bad thing, since it's using the static object of localStorage the scenario depicted in the rule could be ignored for these use-cases. However, as a practice of not implementing workarounds or disabling rules without good reason, I instead implemented the suggested solution from eslint.org.

localStorage

If you never have worked with the browser's localStorage, it's a way to store key-value pair data in your browser. You can find this in most of the modern browsers quite readily available in the developer tools. Now this storage is not encrypted but it is domain specific. With emphasis on domain specificity since you can get cross-over data through this mechanism for better or worse. It's also only available on the browser end so it's not available to the server on each request.

common use-cases with localStorage is either using the indexing pattern as it populates a global object called "localStorage" with property-names based off of the key-value pairs stored therein. so if you store a value in a key named "foobar", it will be available through these;

localStorage["foobar"]
localStorage.foobar
localStorage.getItem("foobar")

similarly you can set a value with

localStorage["foobar"] = value;
localStorage.foobar = value;
localStorage.setItem("foobar", value)

Now what happens if you try to get a value that doesnt exist?

localStorage.barfoo -> undefined
localStorage["barfoo"] -> undefined
localStorage.getItem("barfoo") -> null

So you get a slightly different return value depending on how you access it. This in itself is not a bad thing, as long as you know of it.

no-prototype-builtins

Then there's the Javascript Object's own "hasOwnProperty" which localStorage also implements through Object's inheritence. So unless you overwrite localStorage global implementation, there's nothing really going to happen here. The issue described in eslint would mostly be applicable to nodejs and similar engines/tools/servers.

However, I did make an Object.prototype.hasOwnProperty.call(obj, value) function-wrapper to solve this particular eslint error. Then I used that function in the frontend instead, and subsequently I got a bit of code-reuse since this was replicated about 5 times more in the code-base.

hasOwnProperty returns true or false if there is a value. Which allows you to know, instead of having to check the returned value for undefined or null.

Problem solved.

Reference: https://eslint.org/docs/rules/no-prototype-builtins