Validation about cuid

[niftylettuce]

Doesn't isCuid method logic need to also check for 7 characters minimum? It currently does not. <https://github.com/ericelliott/cuid/blob/master/index.js#L69-L73

[supermacro]

Based on this logic, the string created_at is a cuid. Perhaps there are some further rules / heuristics that could be applied in order to see if a string is a cuid?

[MarkHerhold]

• start with c
• cuids have 25 chars
• cuid slugs have 7 - 10 chars

All of this is in README.md

[ericelliott]

For future-proofing:

• is a string
• starts with c
• contains at least 7 chars

I'm open to a PR for isCuid() and isSlug() helper functions.

[supermacro]

[iki]

// export { isCuid } from 'cuid';

// NOTE: Future cuid may change, they are only guaranteed to start with `c` and have at least 7 characters
// See https://github.com/paralleldrive/cuid/issues/88#issuecomment-339848922
// Having generation under control, we extend the check to lowercase+digits charset and 25 characters length 
const cuidRegex = /^c[a-z0-9]{24}$/;
export const isCuid = (value: string) => cuidRegex.test(value);

[ericelliott]

I do not recommend using a regex to validate cuids.

[Shair17]

I do not recommend using a regex to validate cuids.

Why not?

[ericelliott]

I do not recommend using a regex to validate cuids.
Why not?

Because a small change in requirements should lead to only a small change in implementation. When your application code knows too much about what kind of ids you're using, that makes it hard to switch the id specification that you're using at a later date, if, for example you need to start using crypto wallet addresses instead of cuid-generated user ids. If your application code fails when it sees something that's not a cuid, you need to rewrite that code to make the switch.

This applies to a lot of things people try to do using classes as types - which violates the S from SOLID (the substitution principle). Proponents of class-based types will say that substitution only applies to subclasses. Those people are wrong. Liskov meant it as a principle of modularity, and she was actually pointing out a fundamental flaw in the concept of classes-as-types and subclassing things. It's a mirror of the Gang of Four's advice from "Design Patterns": "Program to an interface, not an implementation".

[ericelliott]

In other words, unless you're writing an implementation of CUID, you probably should not be validating the structure of a CUID in any way in your application code.

[Hoxtygen]

I do not recommend using a regex to validate cuids.
Why not?

Because a small change in requirements should lead to only a small change in implementation. When your application code knows too much about what kind of ids you're using, that makes it hard to switch the id specification that you're using at a later date, if, for example you need to start using crypto wallet addresses instead of cuid-generated user ids. If your application code fails when it sees something that's not a cuid, you need to rewrite that code to make the switch.

This applies to a lot of things people try to do using classes as types - which violates the S from SOLID (the substitution principle). Proponents of class-based types will say that substitution only applies to subclasses. Those people are wrong. Liskov meant it as a principle of modularity, and she was actually pointing out a fundamental flaw in the concept of classes-as-types and subclassing things. It's a mirror of the Gang of Four's advice from "Design Patterns": "Program to an interface, not an implementation".

I thought S is Single Responsibility Principle. Perhaps you wanted to write L which is Liskov Substitution Principle which you actually talked about.

[ericelliott]

👍