Added colour field to community tags

[iByteABit256]

• Added colour field to community tags. using the base 16 CSS values.

- Also fixed bug after deleting a tag and then inserting one with the same ap_id. Since the tag gets soft deleted and ap_id has a unique constraint, the insertion would fail, so I added a query to check if a deleted tag with the same ap_id exists, and in that case updates with deleted = false instead of inserting.

• Added delete parameter to DeleteCommunityTag to allow the client to restore a deleted tag. Duplicate tags will still throw an error upon insertion even if the tag is soft-deleted.

Fixes #5880

[dullbananas]

Use the american spelling "color". It's more conventional in programming, including in the Lemmy repository

[dessalines]

See my comment here:

This I'm against. No apps or APIs should not be hardcoding colors nowadays, as its not going to work with different themes, dark/light modes, and platforms.

Android material, bootstrap, and other frameworks have the right idea, where you only define colors as Primary, Secondary, and Tertiary as enums, and let the theme itself pick from its own list of colors. If you want to keep this, I'd suggest just making it a simple int, that we could potentially turn into an enum later. Then at least apps could use that simple number to pick their own theme color.

Hard-coding colors is the wrong solution, I have no idea who came up with it and why they thought it should be applied to tags and nothing else.

The correct solution, if ppl do want to "theme" certain elements, is define a set of ordered enums like Primary, Secondary, Tertiary, or Color1, Color2, etc that different platforms and UI frameworks can apply their own color sets to.

[Nutomic]

The colors are not hardcoded here, applications can choose their own eg showing red as #8a1d1d, #e53c3c or something else that fits their theme. Using primary, secondary, tertiary doesnt make much sense, because it means that each user will see completely different colors for the same tag. Very confusing if you switch themes and cant find the tag anymore.

[dessalines]

applications can choose their own eg showing red as #8a1d1d, #e53c3c or something else that fits their theme.

Good UI frameworks don't do this any more, because they realize there's too many color conflicts and its impossible to get colors to universally work on different themes. What they do is have a limited set of accent colors, things like primary, secondary, and possibly tertiary colors, and these have their own variants within the theme.

https://m3.material.io/styles/color/roles . Bootstrap works the same

We should never be defining "red" as a theme option. It should be Color1, or primary, and let the UI pick the color.

[dessalines]

To put it another way, colors should only ever be specifically defined in theme definition files. This is how its done in every good UI framework, and even things like text editors color schemes.

[iByteABit256]

applications can choose their own eg showing red as #8a1d1d, #e53c3c or something else that fits their theme.

Good UI frameworks don't do this any more, because they realize there's too many color conflicts and its impossible to get colors to universally work on different themes. What they do is have a limited set of accent colors, things like primary, secondary, and possibly tertiary colors, and these have their own variants within the theme.

https://m3.material.io/styles/color/roles . Bootstrap works the same

We should never be defining "red" as a theme option. It should be Color1, or primary, and let the UI pick the color.

Names like Primary and Secondary don't make much sense to me for this case because they're too specific and you still have to create numbered Colors after creating 2 tags. Maybe they could all be Color and numbered from 1 to 10 for example in order to keep it generic.

The initial logic would be to work like Bootstrap colors where the client still gets to define the actual color values.

[dessalines]

I'd be totally fine with Color1, Color2, etc. This is how most text editor themes do it too.

We shouldn't use the bootstrap all colors, but rather the theme colors, IE primary, secondary, tertiary, success, info, etc. These specific colors are picked by the theme-makers, and go well with the themes.

In both android jetpack compose and bootstrap, I'd create a map or function that converts these numbered color enums to the theme colors, IE Color1 -> Primary, Color2 -> Secondary, etc.

[iByteABit256]

Then mods need a way to list deleted tags

Should a new endpoint be added to be able to retrieve the deleted tags?
Like GET .../community/tag with a deleted query param to make it flexible so it can also retrieve the non deleted tags as well instead of retrieving them from the /community endpoint.

A parameter could be added to the /community GET endpoint instead to include the deleted tags, but it seems like worse API design to me.

[dessalines]

I'm doing the front end for community tags also, and running into some of these issues.

IMO we should just return all (even the deleted tags) in the community view. This way admins will be able to view and restore them if they want. Currently there is no way to view and restore deleted tags.

All the selects and dropdowns can just filter by !tag.deleted

Don't worry about that for this issue, I made #6297

[Nutomic]

IMO we should just return all (even the deleted tags) in the community view. This way admins will be able to view and restore them if they want. Currently there is no way to view and restore deleted tags.

Ideally deleted tags are only returned for admins and mods, normal users wont see them anyway.

[dessalines]

All looks good except the 20 tags -> down to 10.

[iByteABit256]

The relevant changes in LemmyNet/lemmy-js-client#837 need to be merged for the pipeline to pass

[Nutomic]

I tagged version 1.0.0-community-tag-colors.0 of lemmy-js-client, use that in package.json to make the api tests pass.

[dessalines]

Great feature, I'll be using this in both jerboa and lemmy-ui. Thx!