Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation #88

Closed
lewiswalsh opened this issue Oct 24, 2017 · 12 comments · Fixed by #96
Closed

Validation #88

lewiswalsh opened this issue Oct 24, 2017 · 12 comments · Fixed by #96

Comments

@lewiswalsh
Copy link

lewiswalsh commented Oct 24, 2017

Is there any way to validate a cuid? For example to distinguish it from a random string?

@MarkHerhold
Copy link
Contributor

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

All of this is in README.md

@ericelliott
Copy link
Collaborator

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.

@niftylettuce
Copy link
Contributor

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
Copy link

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?

@supermacro
Copy link

Screen Shot 2021-03-24 at 7 50 53 PM

@iki
Copy link

iki commented Oct 18, 2022

// 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
Copy link
Collaborator

I do not recommend using a regex to validate cuids.

@Shair17
Copy link

Shair17 commented Nov 18, 2022

I do not recommend using a regex to validate cuids.

Why not?

@ericelliott
Copy link
Collaborator

ericelliott commented Nov 18, 2022

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants