fix(item): allow nested content to be conditionally interactive

[soundproofboot]

Issue number: resolves #29763

---

What is the current behavior?

If the nested content of an ion-item is conditionally rendered and goes from containing zero interactive elements to one or more, a render is not triggered in Angular and the item does not behave correctly for one or more nested inputs.

What is the new behavior?

• A mutation observer is created in connectedCallback() to watch for changes in item's child list. When the childList changes, two pieces of state that track whether the item needs to be interactive and whether there are multiple interactive elements are updated.
• Add disconnectedCallback() and logic to disconnect Mutation Observer.
• Create new function totalNestedInputs() with logic from existing setMultipleInputs function to be used for both setMultipleInputs and new function setIsInteractive.

Does this introduce a breaking change?

• Yes
• No

Other information

I opted for the MutationObserver over a slotchange listener because the slotchange fires synchronously on any slot within the shadowRoot, and the MutationObserver fires once on the item element itself. I attempted to add the minimum amount of logic to achieve this but there may be a more elegant solution that combines what multipleInputs and isInteractive are doing but requires more changes to existing code.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ionic-framework	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 30, 2025 4:48pm

[ShaneK]

Overall this looks alright and I requested some minor changes for clarity. However, I am worried about this approach because now we're creating an observable for every item in a list, which is probably fine for small lists but may impact performance in larger lists - especially those with content that changes.

I think you should try to see if you can do the same thing with existing Stencil lifecycle hooks, such as componentDidRender, which should, from my understanding, already hook into the changes you're looking for. Possibly even componentDidUpdate - but be warned that only fires after the first render. If you went this path you'd need to do a check after first render, too. I'd encourage exploring those paths before continuing down this one.

[ShaneK]

Suggested change

	this.isInteractive = !!(covers.length + inputs.length + clickables.length);
	this.isInteractive = covers.length || inputs.length || clickables.length;

This change request is very minor, but it's more obvious what you're doing at a glance and it allows short circuiting from the engine as soon as any of the checks pass. I don't know if the compiler is smart enough to see what you're doing here and break it out the same way when you're adding lengths like that, but even if it is I still think the readability would be improved. You can even omit the explicit boolean casting (!!) since that happens from the || operator.

[ShaneK]

I think we should rename this so it's more obvious what its function is from just looking at it. In these components, a lot tends to happen, so clarity in variable naming - especially at this scope - is important. Probably something more like interactivityObserver or contentObserver if we think someday we'll do something else when the child content changes.

[soundproofboot]

Overall this looks alright and I requested some minor changes for clarity. However, I am worried about this approach because now we're creating an observable for every item in a list, which is probably fine for small lists but may impact performance in larger lists - especially those with content that changes.

I think you should try to see if you can do the same thing with existing Stencil lifecycle hooks, such as componentDidRender, which should, from my understanding, already hook into the changes you're looking for. Possibly even componentDidUpdate - but be warned that only fires after the first render. If you went this path you'd need to do a check after first render, too. I'd encourage exploring those paths before continuing down this one.

Awesome, thank you for the feedback. I'll look back at the lifecycle hooks again and see if I can come up with a more performant solution.