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

[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)

[phiresky]

I would declare this out of scope and I'm not going to add this here. This would be a whole new feature that is not described in the RFC. So I would encourage those interested in adding this feature to make a PR with an actual full motivation and description to the RFC, because I'm not interested in moving the goal posts for this further, esp. based on conflicting opinions of the various people. - This, to me, is the implementation phase, not the design phase.

Being able to create a pretty URL for a specific post-tag-filter is neat maybe, but not a necessary component for what 99% of people care about when they think about post tags, which is probably also why it was not a discussion point in the RFC.

Meanwhile we can merge this and get the main post tags feature going.

[dessalines]

Alright, agree this has been open for too long, lets get this merged after it passes and handle other things later.

[phiresky]

I've merged in the latest main branch, which had some major conflicts. Please re-review so we can merge.

[dessalines]

I'm fixing merge conflicts for this now.

[phiresky]

Seems like there's a failure because diesel_cli now requires Rut 1.82. I assume this affects other PRs as well?

error: failed to compile `diesel_cli v2.2.9`, intermediate artifacts can be found at `/tmp/cargo-installUUCyME`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Caused by:
  rustc 1.81.0 is not supported by the following packages:
    pq-sys@0.7.1 requires rustc 1.82.0
    pq-sys@0.7.1 requires rustc 1.82.0
    pq-sys@0.7.1 requires rustc 1.82.0

[phiresky]

I've pushed a workaround to this branch to lock diesel_cli to version 2.2.8, which compiles on Rust 1.81. Not pretty but I don't think there's a better solution until we update to a higher Rust version.

[dessalines]

Thx, yeah that's good for now. I tried using rust-nightly last week and it was still painfully slow, like 10+ minutes just for clippy.