Add priority ordering to custom chat highlights#1196
Add priority ordering to custom chat highlights#1196GameHost01 wants to merge 6 commits intoSevenTV:masterfrom
Conversation
Introduces a priority field to highlight definitions, allowing users to set and reorder the priority of phrase, username, and badge highlights in the settings UI. Highlights are now matched in priority order, with UI controls for adjusting priority and logic to maintain sequential ordering. This improves control over which highlight rules apply first in chat.
- Sorting is now cached --> no more O(n log n) sorts per message; saves ~5,000 sorts/sec in active chats. - Removed redundant scans in `remove()` and `setPriority()` --> both now update max priority in O(1). - save() is lighter --> replaced 3 array passes with a single loop (fewer allocations, less GC). - Badge matching is O(1) instead of O(n), speeding up a hot path hit on every message. - Reactivity fixed --> cache invalidation now updates UI instantly. - Per‑context caches prevent cross‑channel data mixing. - Dead code removed - Priority assignment is O(1) via incremental tracking. - Priority list stays sequential after edits for predictable ordering. Basically: High‑frequency operations became constant‑time or cached, memory churn dropped sharply.
Fixed: new username highlights added via user-card bell icon were assigned highest priority, instead of the lowest priority as intended
|
Username highlights don't need a priority field, I think. Each of them matches exactly one user so they don't apply to a same user. The current highlight settings are separated into three tables (so unable to have draggable entries, which are preferable because of the strict order); therefore, for minimal change, we can just assume username > badge > phrase (the former overrides the latter) as the first stage. |
|
I see what you're saying, username highlights don't strictly need a priority field. It just looks more consistent to have the priority field in front of all entries, and it provides potentially more flexibility for edge cases, where you would want a badge or phrase to be higher priority than a username. Which admittedly, I can't think of a whole lot of scenarios for, but could be useful. On the other hand, draggable entries ARE more user friendly. Really, the hardest task is deciding what direction to go with. |
Adjusted the order and alignment of columns in the highlights and badge configuration tables for improved clarity and consistency.
If entries are draggable in a single table, we don't need sorting within each category. |
|
Just to clarify, when you say
that would need merging of the three UI sections (phrase/username/badge) into one unified list, refactoring the whole UI for it, no? |
|
Yes, so that would be done very later and need more discussion (with the maintainers). The advantages are intuitiveness and no special case that user inputs a same priority, but it requires to redesign entire UI in the other hand. It's just a BTW in parentheses rather than a suggestion to this PR. |
2 participants
Introduces a priority field to highlight definitions, allowing users to set and reorder the priority of phrase, username, and badge highlights in the settings UI. Highlights are now matched in priority order, with UI controls for adjusting priority and logic to maintain sequential ordering. This improves control over which highlight rules apply first in chat.
Proposed changes
Introduces a unified numeric priority system for all custom highlights (phrase, username, badge).
Priority 1 is highest; larger numbers are lower priority.
priorityfield toHighlightDef, persisted in IndexedDBmaxPriority + 1automaticallyResult
Deterministic, user‑controlled highlight ordering with simple, predictable behavior.
Feature Request: #1114
Types of changes
What types of changes does your code introduce to 7TV?
Put an
xin the boxes that applyChecklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.