randomId()

Generate a UUID-v4-shaped random identifier — a string like "3f5d2c1b-9a4e-4b87-bf1a-7c2d8e3f9a01". The canonical default for keyed-each row keys, todo id fields, and any other “I just need a stable unique string” use case.

Shipped from the sub-path @whisq/core/ids, not the main entry. Since alpha.8.

Signature

import { randomId } from "@whisq/core/ids";

function randomId(): string;

Example

import { signal } from "@whisq/core";
import { randomId } from "@whisq/core/ids";

interface Todo { id: string; text: string; done: boolean }

const todos = signal<Todo[]>([]);

const addTodo = (text: string) => {
  todos.value = [...todos.value, { id: randomId(), text, done: false }];
};

How it works

• Prefers crypto.randomUUID() when the platform provides it — all modern browsers, Node 19+, Deno, Bun.
• Falls back to a Math.random synthesis for older targets (pre-19 Node, old Safari). Same v4 shape (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where y ∈ {8, 9, a, b}), but with weaker entropy.
• Same output shape on both paths, so callers don’t have to branch on platform.

Not a security primitive

Caution

Suitable for UI row ids and keyed-each keys. Not suitable for security tokens, password reset codes, session ids, or anything where unpredictability matters — the fallback path is not cryptographically strong, and even native crypto.randomUUID() isn’t intended for cryptographic secrets.

For tokens, use the platform’s crypto.getRandomValues() (or a server-side secret generator) and don’t reach for randomId().

Why a sub-path?

@whisq/core/ids lives on its own sub-path so apps that don’t generate ids client-side (e.g. an SSR app where the server hands out ids) pay no bundle cost. Same convention as /persistence, /forms, and /collections.

See also: /api/imports/#ids, Todo App example.