Marking Component As Non-Interactive If Hover/Unhover Hooks Are Not Exists#654
Marking Component As Non-Interactive If Hover/Unhover Hooks Are Not Exists#654suresh-gangumalla wants to merge 7 commits intolightning-js:devfrom
Conversation
Component's hoverable configuration property will alter holder node `interactive` flag Signed-off-by: Suresh Kumar Gangumalla <sureshkumar.gangumalla@invecas.com>
Test Results: ✅ PASSEDRun at: 2026-04-07T08:58:52.179Z Summary: |
|
hey @suresh-gangumalla, this looks good! But it does mean that we're introducing a somewhat arbitrary component config prop. I had another idea, and I'm not sure how feasible it is, but it would make this whole thing pretty "automagic": what if we keep the generator the same (i.e. setting holder prop to true for all components) and then in the can you look into that approach? |
if component does not registered hover/unhover hooks in component configuation then that component subjected to non interactive by setting `interactive` on holder node to false. Signed-off-by: Suresh Kumar Gangumalla <sureshkumar.gangumalla@invecas.com>
Test Results: ✅ PASSEDRun at: 2026-04-15T12:42:24.919Z Summary: |
suresh-gangumalla
changed the title
hoverable config property
| const identifier = | ||
| this.element && this.element.component | ||
| ? this.element.component[symbols.identifier] | ||
| : undefined |
There was a problem hiding this comment.
what are the use cases where this.element and this.element.component are undefined?
| } else { | ||
| this.props['interactive'] = v | ||
| } |
There was a problem hiding this comment.
should we not skip this else block?
| } | ||
|
|
||
| export const hasHook = (hook, identifier) => { | ||
| return !!(cbs[identifier] && cbs[identifier][hook]) |
There was a problem hiding this comment.
maybe rewrite to cbs[identifier] !== undefined && hook in cbs[identifier] ?
Signed-off-by: Suresh Kumar Gangumalla <sureshkumar.gangumalla@invecas.com>
Test Results: ✅ PASSEDRun at: 2026-04-16T06:01:30.060Z Summary: |
Detecting $isHovered from template and checking whether component holder node should be interactive or not based on $isHovered or hover/unhover hooks. Signed-off-by: Suresh Kumar Gangumalla <sureshkumar.gangumalla@invecas.com>
Test Results: ✅ PASSEDRun at: 2026-04-23T11:45:28.965Z Summary: |
from template and from JS layer detecting whether any component
holding reference to $isHovered then marking that component's
holder node as interactive otherwise non-interactive
For router page components, holder node will be created by router not
code-generator like regular children component's inside a page
component.
Router page components are two types, lazy import and normal direct
import. We can't alter (even we have alter also renderer doesn't
remove/add it from hierarchy pattern) any node interactivity once it
created so for normal import we can invoke needsInteractity function
in component's factory which will return whether component's holder node
need to be marked interactive or not based on folliwng conditions
1. Existance of hover/unhover hook in component config
2. Existance of $isHovered in template which will be inspected at
pre-compile or run time compilation
3. Existance of this.$isHovered in JS layer of component
This step is challening, in users opted for pre-compilation, it
will be like finding existance of this.$isHovered in a source code
If not, we will loop through all JS layer functions and stringy
then look for this.$isHovered.
So, finally dynamic imported router page component's holder node always
interactive.
Signed-off-by: Suresh Kumar Gangumalla <sureshkumar.gangumalla@invecas.com>
Test Results: ✅ PASSEDRun at: 2026-04-24T12:14:04.256Z Summary: |
fix: improve precompiler hover state detection
Test Results: ✅ PASSEDRun at: 2026-04-28T11:28:03.415Z Summary: |
3 participants
Component's hoverable configuration property will alter holder node
interactiveflag