YummYume
commented
1 year ago I am personally leaning towards having unique slugs per user. But now the real question is, do we allow using the same name (thus, slug) multiple times? If yes then...
- Either add a
-1after the slug if it already exists (requires additional DB calls), - Or add a random number at the end of the slug to almost nullify collision risks (would result in less friendly URLs).
So with method one, a URL could look like this :
https://rankylist.com/user/yam/tier-list/my-awesome-tier-list (with my-awesome-tier-list-1 if there is already a tier list with this slug for this user).
Method two :
https://rankylist.com/user/yam/tier-list/my-awesome-tier-list-197625469.
I prefer the first method, but since it requires additional DB calls it could mean reduced performance. It would require some ingenious verifications and logic to reduce the DB calls as necessary.
We can also think about not letting the user use the same name multiple times to avoid similar slugs, but then another problem would kick in :
- My awesome tier list
- My awesome tier list--
Would both result in the same slug : my-awesome-tier-list. So we would also need to make heavy restrictions on the name.
Question
How do we go about turning the tier list's title into a slug? More specifically, how do we want to limit user input on the title of the tier list, and what should the slug look like?
We can think about it like that:
uniqueattribute on theslugfield in the DB, and instead implementing custom validations./yam/tier-lists/my-tier-list).We could also imagine that instead, a slug is unique in the DB but by doing so, we are forced to have a random and unique value at the end of the slug (eg:
my-tier-list-197625469) which would greatly reduce the collision rate.Additional information
There is no "good" or "wrong" answer here. All ways of doing this require a different implementation, but we should look at what is really the best for us and what users would enjoy the most.
Code of Conduct