KeywordView Records

[Hanmac]

add KeywordView Records with only String parameters
so KeywordInstances can be turned into Views and Stored in CardStateView

this might help other stuff like #9806

[Hanmac]

@MostCromulent would such records in the CardStateView help with your Card Info Tooltip?

[MostCromulent]

@Hanmac - AI analysis is it's an architectural improvement but not functionally essential:

The tooltip in # 9806 follows this flow:

1. Gets CardStateView.getKeywordKey() -> a comma-separated string like "Flying,Haste,Protection from Blue"
2. Re-parses each token back into a KeywordInterface via Keyword.getInstance(token) in KeywordInfoUtil
3. Extracts getTitle(), getReminderText(), type params from those instances
4. Creates KeywordData objects (a simple value class with name, reminderText, typeParam)
5. Does additional processing: count annotation (Devotion, Affinity, Domain), keyword action extraction from oracle text, deduplication, sorting

Would KeywordView Records help # 9806?

Short answer: marginally, and it's not a prerequisite.

Benefits:

• Eliminates the round-trip of "keyword ->string -> re-parse to keyword ->extract display data." With records in CardStateView, structured data would be directly available
• For network play, the client currently can't extract reminder text without the full keyword parsing infrastructure. Records would provide that data pre-computed
• PR # 9806 already has KeywordData which is functionally identical to what a KeywordView record would be - this validates the concept

Limitations:

• The current Keyword.getInstance() re-parsing works reliably; the records would be a cleanliness improvement, not a bug fix
• Most of # 9806's complexity is in post-processing that happens after keyword extraction: count annotation (devotion/affinity/domain counts), keyword action scanning from oracle text, deduplication/merging, conjugation matching etc. None of that goes away with records.
• Adding records to CardStateView as trackable properties means touching the delta sync serialization layer (TrackableTypes) where keyword serialization is currently a TODO stub - that's non-trivial plumbing

Priority assessment

Factor	Rating	Notes
Benefit to # 9806	Low	Already works fine with string parsing
Benefit to netplay	Medium	Would enable proper keyword delta sync (currently stubbed)
Architectural cleanliness	Medium-High	Eliminates string -> instance round-trip, proper view separation
Implementation effort	Medium	Needs TrackableType implementation, serialization, migration
Risk	Low	Records are simple; main risk is in the serialization plumbing

Recommendation

This is a good independent improvement but not something # 9806 depends on.

[Hanmac]

getKeywordKey for example is only really used for some "Level up" stuff, and looking for Flash (not Flashback)

but having a better Collection KeywordView, I'm thinking about a Multimap<Keyword, KeywordView>, could clean up all the other Keyword properties
or the other like getHexproofKey and getProtectionKey

[MostCromulent]

@Hanmac have come to conclusion this would be helpful to address some of the harder edge cases Dracontes has found testing the keyword tooltips recently, where oracle parsing gets increasingly complex vs just identifying from keyword API.

The AI has a potential implementation of KeywordView Records. Do you want me apply that to the keyword tooltips PR and then we can review/cherrypick back to master from there? Or do you want that as a separate PR first / different approach?

Edit: here is the implementation plan the AI designed, for review.

[github-actions]

This issue has not been updated in a while and has now been marked as stale. Stale messages will be auto closed.