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	Jul 15, 2025 3:12pm

[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.

[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.

[soundproofboot]

@ShaneK I replaced the MutationObserver with a slotchange handler that should effectively be doing the same thing but still might feel heavy handed. For this issue the parent needs to potentially render again when the nested content changes and I can't find anything built into Stencil like that - since the parent component itself isn't updating, none of the lifecycle hooks are firing. I think attaching three handlers per component may be slightly more performant than a mutation observer. My understanding is that the slots themselves are preserved between renders so they are not being recreated.

[ShaneK]

I think this solution looks a lot more clean than the previous one, thanks for trying again!

[brandyscarney]

Thanks for adding the test! Great work! 🚀