Open yutao-huang opened 5 years ago
Adding the related issue: #126
@Zlatkovsky thanks for the approval!
I've verified the behavior of localStorage.getItem
on Chrome/Edge/FireFox/Safari/IE and all returns null
for non-existent keys. Wondering what could be the situation that would make it return undefined
. (I did not check for older versions, though. I assume the behaviors of the browsers should not have changed...)
@yutao-huang , it comes down to implementation details. For example, depending on whether the underlying implementation uses localStorage[xyz]
syntax or localStorage.getItem(xyz)
syntax, you get two different results!
I expect that's how the bug found its way here in the first place -- that Bhargav had originally had one implementation, then changed it out for another, and suddenly an older assumption about undefined was no longer true.
While null and undefined are semantically different, I would argue that they are mostly the same for purposes of this class. So I think it's better to check for both rather than have it only do one, and then risk an internal-implementation change breaking the outer contract.
As for my approval -- note that you still will need someone else like @sumurthy to actually merge in the changes. I don't have any admin rights on this repo, so I don't know if my "approval" means much per se.
@Zlatkovsky , gotcha, that makes sense. I added the check for safety. I'll ping @sumurthy to get some help. Thanks!
According to the W3C standard (https://www.w3.org/TR/webstorage/#dom-storage-getitem):
In the existing code,
this.get(key) !== undefined
would always betrue
even when the key doesn't exist. In this case,this.get(key)
actually returnsnull
.This incorrect behavior is also impacting things like
authenticator.endpoints.has(...)
, which always mistakenly returnstrue
for an actually not registered endpoint.