![require(esm) Backported to Node.js 20, Paving the Way for ESM-Only Packages](https://cdn.sanity.io/images/cgdhsj6q/production/be8ab80c8efa5907bc341c6fefe9aa20d239d890-1600x1097.png?w=400&fit=max&auto=format)
Security News
require(esm) Backported to Node.js 20, Paving the Way for ESM-Only Packages
require(esm) backported to Node.js 20, easing the transition to ESM-only packages and reducing complexity for developers as Node 18 nears end-of-life.
Javascript function that generates a unique string based on the UNIX timestamp and the runtime.
Javascript function that generates a unique string based on the UNIX timestamp and the runtime.
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?
FAQs
Javascript function that generates a unique string based on the UNIX timestamp and the runtime.
The npm package absurduid receives a total of 3 weekly downloads. As such, absurduid popularity was classified as not popular.
We found that absurduid demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
require(esm) backported to Node.js 20, easing the transition to ESM-only packages and reducing complexity for developers as Node 18 nears end-of-life.
Security News
PyPI now supports iOS and Android wheels, making it easier for Python developers to distribute mobile packages.
Security News
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.