typeid
typeid copied to clipboard
jetify-com
RFC: Consider allowing `_` as an additional separator within the typeid prefix
The spec, as defined today, only allows for lowercase alphabetic characters in the type prefix. Some users though, might need a way to have a "compound noun" in the prefix. Imagine you want the type to be "user accounts"; today you would have to encode that as a single word useraccounts but it might be preferable to allow a separator to encode it as user_accounts instead.
I think a relevant discussion would be: what is the intended purpose of the prefix? Is it merely a tag to differentiate id's for different types? Is it meant to be a human readable descriptor of the type? Or does the spec take no stance on the matter and encourage users to [ab]use the prefix as they see fit?
I personally would tend to use them as tags. IMO 99% of the time having a user_account prefix, as opposed to say ua, is just unnecessary bloat. Wasted space in the database, unnecessary data to send over the wire, hold in app memory, etc. For tags, I think only alpha characters is a fine limitation. If there's a desire to encourage verbosity/readability or flexible usage, then there's a strong argument for allowing arbitrary separators.
I agree with @loreto . However if the underscore is already use as separator between type and id parts, maybe the hyphen would be better choice.
maybe the hyphen would be better choice.
A hyphen would break the easy "double-click-to-copy" property of type-ids
Given this specification is inspired by Stripe, why do we differ here when stripe have plenty of examples with more than one underscore?
Stripe prefix list for reference https://gist.github.com/fnky/76f533366f75cf75802c8052b577e2a5
While I agree with some of the above suggestions on how that very specific example could be shortened, I don't think that is great as a universal rule.
What are the implications of supporting this? Why wouldn't we support this?
@reecefenwick I'm totally open to supporting an additional _ in the prefix. I started without that support because I think it's easiest to start with the most restrictive spec, and then add features to it, than start with a bunch of features, and if you need to take one back well, now you can't because it'd be backwards incompatible.
Are there any objections to _ as an additional character in a prefix? If not, I could update the spec with the proposal, and we can set a target date/version by which _ would be allowed.
Hi all,
Would it be possible to drive this discussion to a conclusion? From what I can tell, there is no technical reason why underscore couldn't be allowed. Therefore, offering this flexibility to users, teams, and companies seems worthwhile.
We're gonna move forward w/ this proposal. I haven't had time to update the spec and test suite yet. Hoping I can do it this week.
Hi everyone, PR with the spec change is here: https://github.com/jetify-com/opensource/pull/306
Please give comments if you're interested in this change before we solidify the spec. Plan is to merge by end of the week. Once merged/accepted, implementations can start upgrading to the v0.3.0 spec that allows for underscores in the type prefix.
Spec change is now merged.
@TenCoKaciStromy @cbuctok @firenero @mistermoe @sloanelybutsurely @MMZK1526 @fxlae @softprops @titouancreach @faustbrian @akhundMurad @broothie @conradludgate @johnnynotsolucky @ant8e @guizmaii @Frizlab @nletullier @ongteckwu @tensorush – you have the option to upgrade your implementations of TypeID to match the latest spec. If you do update them, we can change the README to show you're compliant w/ v0.3.0 (as of now, we're listing everyone as compliant w/ v0.2.0).
A few test cases were updated for v0.3.0
added support here: https://github.com/conradludgate/type-safe-id/pull/1 will release this version shortly
Updated Haskell support https://github.com/MMZK1526/mmzk-typeid/actions/runs/8739099730
@conradludgate @MMZK1526 would you be able to send me PRs against our opensource repo: https://github.com/jetify-com/opensource/tree/main/typeid/typeid, updating the README table?
Similar to: https://github.com/jetify-com/opensource/pull/314
Much appreciated!