Skip to content

fix #183: conditional hiding fixed with proper styling - #197

Open
iantrich wants to merge 1 commit into
betafrom
iantrich/fix-183
Open

fix #183: conditional hiding fixed with proper styling#197
iantrich wants to merge 1 commit into
betafrom
iantrich/fix-183

Conversation

@iantrich

@iantrich iantrich commented Jun 9, 2026

Copy link
Copy Markdown
Owner

fixes #183

🔍 The Root Cause

The reason unlocked_icon worked in version 1.2.19 but broke in the beta 2 release is due to the underlying migration to Lit 3.

In older versions of lit-html (used by lit-element in v1.2.19), the classMap directive had a quirk where it would indiscriminately wipe out any classes that were added imperatively (e.g., via classList.add()) if they weren't explicitly keys inside the classMap.

In your _handleRestriction function, you were imperatively setting lock.classList.add('icon-hidden') and overlay.classList.add('unlocked'). In 1.2.19, when this._unlocked = true triggered a render, classMap simply blew those imperative classes away. This accidental behavior "fixed" the unlocked_icon visibility because it prevented the icon and its container from fading out to opacity 0.

Now that you've migrated to Lit 3, classMap correctly preserves imperatively added classes. Consequently, the icon-hidden class stays on the element, hiding the icon even when an unlocked_icon is explicitly provided.

🛠️ The Solution

I have updated src/restriction-card.ts on your beta branch with the following logical fixes:

  1. Conditional Hiding: In _handleRestriction, the icon-hidden and unlocked classes are now only applied if the user did not configure an unlocked_icon. If an icon is provided, the card remains visible, but pointer events are still disabled to allow interaction with the underlying card.
  2. Proper Styling: I restored the icon-unlocked class mapping to classMap and added it to the css block so that the unlocked icon takes on the success color (var(--restriction-success-lock-color)), matching the expected behavior.
  3. Optional Chaining: Fixed a potential TypeScript compilation issue within the timeout closure by using optional chaining (`this._config?.unlocked_icon```).
  • Gemini 3.1 Pro

@iantrich
iantrich requested a review from ildar170975 June 9, 2026 03:26
@iantrich iantrich self-assigned this Jun 9, 2026
@ildar170975

ildar170975 commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Cannot confirm.
The simple example still does not work:

type: custom:restriction-card
locked_icon: mdi:bell-cancel
unlocked_icon: mdi:bell
card:
  type: entities
  entities:
    - entity: input_boolean.test_boolean

The icon is always "mdi:bell-cancel" and is not hidden when unlocked.
image

To create a JS file, I manually copied package.json & yarn.lock from this PR into my VSC, ran "yarn install", then ran a task "npm: build". May be my dev env differs from yours - so my generated JS files is somehow "wrong".

Also, I honestly not getting fully the proposed changes.
And - a change proposed in #192 was working! But now - probably after updating Lit in VSC - that change stopped working...
So, I am a bit confused, sorry((

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants