-
Notifications
You must be signed in to change notification settings - Fork 264
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
Remove the usage of slug fields #2662
Comments
Models still needing
|
Need to account for the removal of slugs in the Git repository data import case ( |
So in the instance where I have the following playbook creating tags:
That creates a tag with the name
What does the |
The filter will use the name, yes. |
Actually Tag (specifically) will still have a |
We are keeping
|
Address #3890 as a part of this story |
@jvanderaa for visibility: Tag.slug is being removed after all as part of this issue, so yes, tag filters will need to specify the tag |
implemented by #3914. |
Discussed in #2312
Remove
slug
FromOriginally posted by lampwins August 25, 2022
I propose ditching the usage of slug fields altogether. I realize this might be a contentious idea, so here are my thoughts.
Slugs in their present form create bad UX when managing data
Today we have slugs all over the place as fields that users can edit. Many folks have no idea what the actual function of the slug is and why it exists. I can't count the number of times I have answered the question "what is the slug for" or "what is the purpose of this field since it duplicates the name?"
We could certainly address some of these concerns, but I truly don't see the point in favor of just ditching them.
Slugs cause surprises when permalinking
If a slug is updated for whatever reason, that record's UI link changes which is surprising to the user if they don't understand the purpose of the slug. This becomes very obvious when you have objects with simple names (e.g., one word) in which the name field and the slug contain the exact same value. The user is presented with two fields with the same value, and when their intention is to change the name, it is natural for them to also change the slug, even though it is not automatically updated for an existing record.
Also, consider automation like SSoT use cases which may change the value of the slug (either inadvertently or via a valid use case).
Slugs are great if you actually care about fancy URLs
IMO slugs in Django are great if you are running a blog where there is absolutely no reason to change the title of a post, and you want a nice-looking URL, which, more importantly, is SEO friendly. Nautobot is a data-intensive, internal IT application; our data changes, and we don't care about SEO.
Also, it's 2022, and modern browsers are removing focus from the structure and content of URLs. Safari does not even show the URL. Chrome puts focus on only the domain.
Link sharing between humans has become much more advanced. Many modern chat applications will attempt to include additional link context, like the page's title while hiding the actual text of the URL.
Our usage of slugs vs. PKs is entirely inconsistent
Sometimes we use slugs, sometimes we use the UUID PK. Our REST API uses the UUID exclusively. I know we have discussed moving towards natural keys, which alone is great, but we know in many (potentially most) cases, these will be composite keys which presents many challenges in creating workable URLs that play nice within the Django ecosystem of 3rd party apps that we rely on.
Bottom line, let's move to all UUIDs
Sure they don't look sexy, but who seriously cares enough that we are going to forgo these other points? Exposing UUIDs for record identification is a sane and standard practice that reduces overall complexity. It would allow us to be consistent across the application interfaces, and most of all, it would reduce UX toil.
I humbly submit to you nuking slugs from orbit. Please do it for the children.
The text was updated successfully, but these errors were encountered: