feat: per-deck and global card tagging system

[TheTacoScott]

Adds a card tagging feature letting users assign custom tags to cards either globally (shared across all decks) or per-deck. Tags are persisted in deck meta and settings state.

• Tag editor in card modal: add/remove deck and global tags per card
• Tag filtering in card list and deck collection views
• Deck tools panel: tag bar chart, expandable tag summary table, and show untagged toggle that appends an untagged bar/row to both views
• Settings Tags tab: rename/delete global tags, bulk-clear global, deck-specific, or all tags
• Visual origin indicators: globe icon for global tags, layers icon for deck-local tags, shown in card list rows, scan view, and card modal
• Custom tags feature flag (customTagsEnabled setting) gates all UI

Still working on cleaning up the commits, will squash sanely.

[TheTacoScott]

Example look and feel screenshots:

In the deck edit card modal:

Settings directive:

Extra Settings tab when enabled:

[TheTacoScott]

I never do javascript/typescript coding, so this is probably not-all-correct and not-all-proper. I think the idea is useful so I'd like to push for it and collaborate on making it happen.

[fspoettel]

Hey @TheTacoScott, thank you for the PR. It's large enough both in scope and size that I would have appreciated a conversation or at least an issue before it was opened and I'm unsure what to do with this atm.

Tagging is indeed useful, and something that was discussed in the project's Discord channels a few times. The general consensus, and why this has not happened yet, is that it needs two things:

1. An account system to sync tags across devices (I'm working on accounts currently).
2. Some form of community-led global tagging approach, e.g. by voting.

Without at least 1 being present, I'm hesitant to commit to it as it only increases the migration burden. Curious to hear your opinion on 2.

[TheTacoScott]

Apologies for lack of conversation, as a software engineer myself I tend to find that presenting something more concrete forces a more productive conversation than whatever my vague product idea ramblings (which is what they would be without code changes) would produce. Showing off code also tends to bring the bigger issues to light in a way that can be discussed with something closer to data-points rather than gut feelings.

I have no expectation that you accept these changes, I submit them because I am running the server locally and I have found them to be incredibly useful. I try to send the changes back to the creator whenever possible, and if they don't fit the vision/timeline/scope/focus/etc of the author: I understand and hold no grudge whatsoever. I understand, I am annoyed by merge requests daily at my job. =)

I just try to be a helpful guy.

On to your questions:

Account Syncing

My general instinct is that syncing deck specific tags across a concept of an account seems very useful.
Per-deck tags could probably be encoded/serialized into the description field in arkhamdb to allow for some level of account syncing. That doesn't help with per-card (aka: global) tags which are also useful.

Being able to store some amount of account metadata or (account, deck) metadata, or (account, card) metadata, etc is an expansion in scope server side, but obviously useful.

Community Tags

Community tags would be amazing. Voting, the ability to see how your deck "scores" with community tags. A lot of product features can come from that. It's, again, quite an increase in scope server side.

Accounts, voting, auditing, rate limiting, curation or moderation, etc. Very useful to be sure.
We could probably offload the community tagging concept over to a different repo where the tags could be curated a bit via some kind of makeshift "voting" system with pull requests and "stars" or something. That might allow for keeping the payload hosted externally and pulled down sporadically. Feels like we could make hosting costs for that simple, and community tags could just be stored in a localStorage or an indexedDB, etc.

My Take (which is basically worthless as you don't know me nor should you really trust me etc etc)

My general instinct is to have features like what I'm proposing here clearly marked as "labs" or "alpha" or "unstable" or something along those lines to let people know that while you're exploring a new product concept: it might not stick around or be stable.

I like to avoid making perfect the enemy of the good, and having locally stored tags is better than good (imho) and having those be out of scope for later account migration (or me coding the tags in such a way that eases later syncing issues) seems sane. If I was a software engineer hearing your pushback to this idea from a product manager I would probably suggest for a way to chunk out the work in smaller increments, but also define you P0s, P1s, etc. What is the minimum viable product to make tags useful. Start there, see if people care about them, then expand or reduce the scope accordingly. Having too many preconditions in the graph of dependencies is just a recipe for a thing never happening, although somethings a thing never happening is the appropriate choice. Most importantly: it is your choice, not mine.

Thanks for looking at it, and I'm happy to assist making it not a painful thing later, changing the structure here, providing something that would provide more confidence in the changes here, doing a video call, whatever. etc. I'm also understand if you to ignore it and move on with your life, I understand how this all works. =)

EDIT: I made like 15 edits to this fixing language, grammar and spelling. Apologies for that.

[wappowers]

This does look useful, even locally stored tagging would be helpful. I will pull it down and test it out.

[TheTacoScott]

Just some info as I explored what an account syncing process would likely look like:
Deck tags are stored as card_tag_{code} keys inside the deck's meta JSON field, best I can tell this is the same pattern used by other deck level customizations. The general way I would expect an account sync mechanism to work (syncing per-deck metadata) would likely carry over these other per deck tags (aka: other metadata) "for free". "For free" isn't entirely accurate of course as you may want to have a more structured account syncing schema rather than just allowing a json blob to be stored "Server side" without any schema verification, but I can always handle the additional schema validation foo specific to per-deck tags.

For the global tags: they are just a Record<string, string[]> blob, I suspect we can be serialized this and store it alongside other user preferences/settings on an the general account.settings{} dict during the sync process. Without knowing more about the account sync process (which I would certainly be happy to assist in making a reality) I don't know exactly the best course of action but adding more a new settings checkbox, some global tags json foo, and some per deck metadata: doesn't seem like a deal breaker to me.

[TheTacoScott]

Also now looking at how you are syncing things over to arkhamdb in their meta field, I think these per-deck card tags are already syncing there. I want to validate that more than just "looks like it syncing". But that handles a core part of this concern, albeit only for per-deck tags. This doesn't cover account level settings or tags.

[TheTacoScott]

This might also solve some account syncing issues: Kamalisk/arkhamdb#755

[fspoettel]

We will not be syncing this stuff to ArkhamDB. Our account system will be implemented in our own backend which we have full control over. The current implementation will mostly be removed, with the ArkhamDB sync moving into the backend as well.

From my POV, that PR is not needed.

Re deck metadata: ArkhamDB has a limit of 1024 bytes for the deck.meta, so we currently have to work around this via our "additional metadata" token (see docs). I don't think we can make tags work without leveraging said system.

[TheTacoScott]

fair enough, let's set the snooze on this idea for awhile and I'll bother folks about it later. =)