Community post tags (part 2: API methods)

[phiresky]

This is the second part of post tags, implementing the API methods.

Database PR (merged): #4997
Original RFC: LemmyNet/rfcs#4

[phiresky]

Ready for review. the API tests pass locally for me, but require merging LemmyNet/lemmy-js-client#483

[dessalines]

What's the slug thing about? The tag already has a name and an ap_id.

[dessalines]

Do the re-request review when you want me to have another look. I thought about going through it but I'm guessing its still WIP.

[phiresky]

I've updated the PR

• comments fixed
• removed separate API methods, post create and update now do replacement of all tags (if tags given)
• added tagupdateform

I'll merge main after reviews are green

[phiresky]

i've temporarily set the lemmy-js-client lib to point to this pr LemmyNet/lemmy-js-client#483 so that the tests pass. please re-review

[Nutomic]

@phiresky The discussion at the top about table names is not resolved yet. If you have better ideas how to name them thats fine, but right now the names dont make it clear what these tables and structs are for.

#5389 (comment)

[phiresky]

@Nutomic the discussion you linked is about the API path, which is resolved. Tables are not even part of this PR.

[Nutomic]

Yes the tables were in #4997 which is part of the same feature. In that PR it wasnt clear yet how it all works, only now is it possible to review properly. So Im repeating my request again:

Yes it all needs to be made more consistent. For the main tags table community_tags makes sense, while the relation tag-post can be represented by a table community_tags_for_post.

[dessalines]

Here's that discussion, and I believe that we agreed on leaving a generic tag table, and validating that its an allowed tag in the back-end. (And possibly adding a tag_type enum in the future). Any specific items then get a _tag table, like here for post_tag.

So I don't believe any tag table changes (or new tables) are necessary, outside of possibly adding a display_name column.

[Nutomic]

Alright then leave the table names like this, but do add comments on the db structs to make it clear what they are for.

[phiresky]

There already is a extensive comment on the tags table that was added in the previous PR that describes the purpose, considerations and future expansion:

I added one to the association table as well.

I fixed all the comments. Please re-review. I'll update to master once approved.

[Nutomic]

Tags can only be created by mods (or admins).

[phiresky]

Thanks. I've clarified this

[Nutomic]

Sorry I missed those comments, its not easy to review these split PRs.

[dessalines]

This still isn't right, check either the person table (or community table)

• name varchar(255) not null
• display_name varchar(255) nullable

Whether its varchar or text doesn't matter to me, but having a required name, and an optional display_name, is what I was referring to. The name will be the no-spaces, url-safe version, and the display name is optional, and can be whatever.

[phiresky]

that's what id_slug was but you said I should remove it 😂 and why would we need a second name? it's already included in the URL so it would be redundant. no point complicating things

[dessalines]

iirc id_slug wasn't actually on the table. The display name is to allow spaces and other non-url characters (if they want), and should be optional (with UIs defaulting to showing the tag name if display name is null). I think its a good idea to have, I could see tag display names getting complicated and people would want to use more complicated ones.

[phiresky]

yes you're right, I only had that in the creation UI because that was an additional feature, having it in the DB would have been redundant.

The display name is to allow spaces and other non-url characters

yes but that's what display name already is. the question is why would you need another copy of a name that is simpler? how would that look in the UI? when would it be displayed? for what purpose would it be used? would it be modifiable? what if the two names mean completely different things?

this seems like a whole new feature that i don't understand

it's also not part of the rfc fwiw.

[dessalines]

It'd be just like person names and person display names. The tag name (that doesn't allow spaces and such), could be useful for URLs, searching, tagging, etc. Sometimes people like to flair up their display names with weird characters and spaces, but their person name is a simple searchable text.

Lets say in the future we create a way to filter a community posts by tags: IE /c/asklemmy?tag=? That's going to be a lot easier if its a url-safe name. But when we show the post tags somewhere, we'd always use the display name.

[phiresky]

i'd expect the tag=x in an url to be the id (numeric). otherwise you have three (!) ids you need to be able to query by (id, ap_url, name) which seems excessive to me for a tiny benefit

person name seems like a pretty different thing to me because "username" is a very well known concept and connected to identity, but tags are a pretty different thing

[dullbananas]

The tag slug could be used to include a reference to the tag that automatically links to a view of posts that have that tag, just like a person mention. If a search bar is added to post views in the future, then a realistic use case of tag slugs would be including a link to the "question" tag in text that tells users to check existing questions before posting a new one.

As a separate change, removing slugs from everything would be good if:

• The name is shown where the slug is currently shown (including in URLs, as an optional part after the numeric id) (not guaranteed on other instances that the object federates to, which might be a problem)
• The name doesn't become the thing that has to stay the same in order to not break links
• The UX for inserting a mention stays just as good (this may or may not be possible)