Support dates

[sindresorhus]

Would be nice if you could store.set('foo', new Date()) and get back a Date object when you do store.get('foo'). Could probably make use of the second argument to JSON.parse(). We need to save some kind of information to indicate that it's a native Date format. Maybe a separate __meta__ key or something. Suggestions welcome.

---

IssueHunt Summary

Backers (Total: $80.00)

• issuehunt ($80.00)

Submitted pull Requests

• #89 Store and get Date objects
• #154 Support non-primitive values

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[sholladay]

You could serialize dates to ISO 8601 format in .set(). Then you could parse ISO 8601 dates into Date objects in .get() but override their .toString() to return the string as it was stored (rather than the default (new Date()).toString() funkiness).

That would:

• Avoid adding extra fields
• Be convenient, regardless of how the date was set (either as a string literal or a Date object)
• Be safe, in case the date was set as a string literal

[sindresorhus]

Then you could parse ISO 8601 dates into Date objects in .get() but override their .toString() to return the string as it was stored (rather than the default (new Date()).toString() funkiness).

That sounds hackish. What if the user tries to do typeof store.get('date-string') and expected it to be string, not Date. I would rather store some extra metadata than having unexpected behavior.

[acheronfail]

Just another suggestion:

Rather than a separate __meta__ key, what are your thoughts on prepending the date type to the value? Meaning:

const d = new Date();
const s = d.toString();

// Current:
conf.set('date', d);    // { "date": "Sat Jan 27 2018 18:42:32 GMT+1100 (AEDT)" }
conf.set('dateStr', s); // { "date": "Sat Jan 27 2018 18:42:32 GMT+1100 (AEDT)" }

// Suggested:
conf.set('date', d);    // { "date": "__date__,Sat Jan 27 2018 18:42:32 GMT+1100 (AEDT)" }
conf.set('dateStr', s); // { "date": "Sat Jan 27 2018 18:42:32 GMT+1100 (AEDT)" }

If the value passed to .set() is an instance of Date we could prepend a special string to the serialised string, and just check for that when parsing it back from JSON.

[sindresorhus]

@acheronfail Can't do that. What if the user actually sets __date__,Sat Jan 27 2018 18:42:32 GMT+1100 (AEDT) themselves and expects a string back.

[sindresorhus]

conf (which is where this should be first implemented) now has a __internal__ that we could use to store this kind of metadata.

[issuehunt-oss[bot]]

@issuehunt has funded $80.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[rafaelramalho19]

How about adding the possibility to store a function in the store and execute it automatically?

e.g. conf.set('foo', () => new Date());

And whenever the user fetches the value, we just evaluate if it's a function or not and run it.

[sindresorhus]

@rafaelramalho19 I don't think that's a good idea. That would be a security nightmare. Anything on the computer could add code to the plaintext config file and have the app execute it in a trusted context.

[rafaelramalho19]

I guess thats true. Just wanted it to allow for broader use-cases.

[dnlup]

👋 I stumbled upon this library:

https://github.com/wynntee/joss

Would it help in this case?

[Richienb]

v8.serialize?

[dnlup]

v8.serialize?

Interesting, you mean serializing just the Date or the whole db?

[Richienb]

By serializing the whole db, there is no longer a problem with creating non-conflicting values.

[KaKi87]

How about just using timestamps ?

[Richienb]

How about just using timestamps ?

The challenge would then become telling apart a timestamp from a regular number