Provide non-numeric unique item ids (UUID, cuid2, Ulid, NanoId) out of the box

[MurzNN]

Now out of the box Payload seems provides only numeric autoincrement id values for items, which is good and classic, but not for all modern cases.

In many cases, we need unpredictable IDs to make things better. Yes, we can override the ID field behavior, as described in the documentation, but it requires writing custom hooks, which is not good for performance, and managing this manually.

So, would be great to provide custom id generation functions directly in the PayloadAPI, maybe something like this?

import { createId } from '@paralleldrive/cuid2';

export const MyCollection: CollectionConfig = {
  slug: 'my-collection',
  idGenerationFunction: createId,
  fields: [
    {
      name: 'id',
      type: 'text',
    },
    {
      name: 'myField',
      type: 'text',
    },
  ],
}

And maybe something like configuring the default id function for all collections, to not list it in each collection explicitly.

This should allow simple usage as ID any technique as the developer wants: UUID, cuid, cuid2, Ulid, NanoId, ULID, KSUID, etc.

[MurzNN]

Here is an example of how to make this manually in the current version, using the "cuid2" id generator:

import { init as cuid2Init } from '@paralleldrive/cuid2';
import { FieldHook } from '_temp/payload/packages/payload/src';
import { CollectionConfig } from 'payload';

export const MyCollection: CollectionConfig = {
  slug: 'my-collection',
  fields: [
    {
      name: 'id',
      type: 'text',
      hooks: {
        beforeChange: [
          ({ operation, value }): FieldHook => {
            if (operation === 'create') {
              return cuid2Init({ length: 12 })();
            }
            return value;
          },
        ],
      },
    },
    {
      name: 'myField',
      type: 'text',
    },
  ],
}

[MurzNN]

And here https://medium.com/@dinesharney/understanding-uuid-v4-uuid-v7-snowflake-id-and-nano-id-in-simple-terms-c50acf185b00 is a good article explaining why we have many text ID generators.

[soranoo]

So far, you can use UUID by setting the db adapter with the following setting

// payload.config.ts

export default buildConfig({
	// ...
	db: postgresAdapter({
			idType: "uuid",
			//...
		}),
	
	// or
	
	db: sqliteAdapter({
		  idType: "uuid",
		//...
		}),
	// ...
})

btw, I am also looking for more ID options / able to customise ID

[MurzNN]

Sadly, the idType: "uuid" is not available for the mongooseAdapter :( Maybe I can pass a direct option to the Mongoose instance to set the "uuid" type for all collections at once?

[MurzNN]

Created a draft PR #15522 trying to implement this missing feature.

[MurzNN]

After trying different ID types, I've decided that the most optimal way is to use UUIDs as IDs for documents everywhere across all database types.

The UUID is well-known to everyone, unique, and can be used in any database, and there will be no changes required if we change, for example, PostgreSQL to MongoDB.

But in the default text representation, it is too long (32 characters) to store as a string in the database, and use in the URLs.

Therefore, we can easily convert it to a more compact, but still URL-friendly format, using base62 encoding - just 22 characters (which is even shorter than MongoDB's ObjectId's 24 chars!).

And, if needed, we can easily convert it back to the full 32-character UUID form or to the binary value.

So, I vote to make the IDs in the Payload consistent by default, not dependent on the database type, and use the UUID by default for all collections. Of course, keeping the ability to set back the ObjectId and autoincrement numeric ids, if needed.

And to use it in the URLs (route parameters), represent it as a base62 string, having 22-character identifiers for each document there.