npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

absurduid

v1.1.0

Published

Javascript function that generates a unique string based on the UNIX timestamp and the runtime.

Downloads

5

Readme

absurdUID.js

Javascript function that generates a unique string based on the UNIX timestamp and the runtime.

Why?

Today I ran into an issue. The guy sitting next to me in the university was trying out PouchDB and was confused by the identifiers. It was illogical for him why he had to determine the ID for each document himself. In my last project I just generated a random number and asked if it already existed. Actually quite bad, but it worked.

Then I asked my friend Google and came across a solution on Stackoverflow.

At that moment I was shocked how simple this approach was and how I never came up with this idea.

Just create an ID using the current UNIX Timestamp with new Date().getTime()

But after a short thought I asked myself a question. Does this approach still work when my code generates many records in a row?

For the demonstration I use PouchDB.

With PouchDB you can create a batch of documents with db.bulkDocs()

db.bulkDocs([
{
    title : 'Record 1', 
    _id: +new Date()
},
{
    title : 'Record 2', 
    _id: +new Date()
}
]).then(function (result) {
    console.log(result);
}).catch(function (err) {
    console.log(err);
});

As you might expect, only the first entry will be created and the second one will return an error because it is done in the same timestamp and end up with the same _id.

I needed something more accurate than milliseconds. I was helped by performance.now().

Unlike other timing data available to JavaScript (for example Date.now), the timestamps returned by performance.now() are not limited to one-millisecond resolution. Instead, they represent times as floating-point numbers with up to microsecond precision.

Also unlike Date.now(), the values returned by performance.now() always increase at a constant rate, independent of the system clock (which might be adjusted manually or skewed by software like NTP).

So if I combine these two methods, I should end up with a very accurate Unique Identifier.

Lets create this simple function:

function uniqueID() {
    return new Date().getTime().toString().concat(performance.now());
}

And output some data:

console.log(new Date().getTime());
// Output: 1568115683706

console.log(performance.now());
// Output: 218.28000000095926

console.log(uniqueID());
// Output: 1568115683706218.28000000095926

Even if this seems completely absurd in my eyes, I can hardly think of a possibility that he runs on an error because of an already existing ID.

Because in every millisecond of the current UNIX timestamp the value of five thousandths of a millisecond (5 microseconds) of the runtime is added.

Let's use above uniqueID() function like this:

db.bulkDocs([
{
    title : 'Record 1', 
    _id: uniqueID() // 1568116510818456.76499999899534
},
{
    title : 'Record 2', 
    _id: uniqueID() // 1568116510819456.94000000003143
}
]).then(function (result) {
    console.log(result);
}).catch(function (err) {
    console.log(err);
});

As you can see, between the two entries, the difference from the results is large enough.

Of course, this approach can lead to a problem if millions of users work with the same database. But on a small scale it shouldn't run into a problem.

I am always open for ideas or suggestions. What do you think about this approach?