.has() api method

[kirillgroshkov]

Am I missing something or there is no .has() api method? (similar to Map)

What I need is to distinguish between situation when there's no key in cache (has would return false) or there is a key in cache, but it's value is undefined. If I use .get(key) for this - both will return undefined.

[lukechilds]

You're not missing anything, there is no .has() method implemented yet :)

I'm busy on a paid project at the moment so won't be able to implement this right now but would happily accept a PR to Keyv + official storage adapters implementing this.

[ghost]

If the key expired should it return true or false? In other words, is .has() testing whether the key was set and hasn't been removed yet or whether it was set and is still fresh? Because if it's the second then you don't even need to implement it into the underlying storage adapters, in keyv's .has() you just .get() the key and return false if it's undefined.

[lukechilds]

@MySidesTheyAreGone I'm afraid that wouldn't work, if the key is fresh or stale if the value was set as undefined it'll always return undefined.

@kirillgroshkov What is your use case for this btw? This is something that's possible to implement but it seems like maybe it could be suboptimal Keyv usage in your app, e.g checking for null or undefined, true or false etc.

I Definitely agree a .has() method would be useful but just interested why you need to differentiate between explicitly setting undefined and checking it doesn't exist.

undefined as a value support was only really added for Map() compatibility, it's not something I was expecting people to store as a useful value.

[lukechilds]

Note to self, we could make undefined an illegal value to set().

Then .has() could be implemented as:

has: val => (this.get(val) !== undefined);

Deviats from the Map spec slightly as we can't set undefined, but maybe that is ok.

[dusansimic]

In my opinion we shouldn't mess with default behavior of .has() method. If it returns true event if value of that key is undefined it should stay that way, otherwise we are adding more features that are not giving raw data from key+value store as it was a plan in #36.

@lukechilds @roccomuso any thoughts on this since I'd like to do a PR for this.

[lukechilds]

@dusansimic Yes, correctly differentiating between an undefined value and an unset/expired value is the ideal behaviour.

If you can submit a PR for that, that would be great!

[ririko5834]

Agree with this

[jaredwray]

@ririko5834 @dusansimic @kirillgroshkov @alphmth - we are getting really close to supporting this and it is looking like this will be out and live next week.