feat(header-bar): add expandable notification dot indicator [LIBS-868] - #74
Open
arina-gutuboe wants to merge 1 commit into
Open
feat(header-bar): add expandable notification dot indicator [LIBS-868]#74arina-gutuboe wants to merge 1 commit into
arina-gutuboe wants to merge 1 commit into
Conversation
arina-gutuboe
requested review from
KaiVandivier and
kabaros
and removed request for
kabaros
August 5, 2026 11:46
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Implements LIBS-868
This is a follow-up PR that ports the equivalent badge behavior from the ui PR.
Description
Replaces the persistent notification counter badge with a compact indicator dot when unread notifications exist. The full counter badge is shown temporarily after login (3 seconds) and on hover or keyboard focus, then collapses back to the dot.
Known issue
A bug has been identified in the header bar:
bgColoralways has a default value, which means it is always truthy. As a result, the element background is not darkened when the default color is used, and the hover opacity is always applied.Note for the reviewer (out of scope)
In this PR, the
hoverStylevariable innotification-iconwas split into two separate variables to avoid applying opacity to the badge itself. The underlying hover logic, however, was intentionally left unchanged.My initial thought is that, since this behavior has been in place for a while, it may not be worth reintroducing separate hover styles for the default and custom background colors.
I'm wondering if it would make more sense to either keep the current opacity-based approach for consistency and clean up the old hover logic, or consider a different approach that makes the hover state more noticeable.
A possible alternative would be to adopt an approach similar to
useOnlineStatusStyles, where the hover background is adjusted based on contrast:Screenshots


A dot indicator is displayed by default, and a badge appears on hover: