Toggling a useState within a Popover to control a set of Collection items fails to update properly

[uncvrd]

Provide a general summary of the issue here

Hi again - I'm running in to an issue when trying to use SelectStateContext to determine if there is a value in order to show a "remove selection" option in the Select ListBox. But I cannot get my list to render an additional item based on a conditional from a component inside a popover, even if I add it as a dependency at every level of the collection. I've tried different cache busting approaches i promise. Maybe I'm missing something though

🤔 Expected Behavior?

I expect to be able to use const state = useContext(SelectStateContext); specifically the value prop from state to add a list item so that the user can "deselect" from the list

😯 Current Behavior

Currently even though the value of Boolean(state?.value) shows as true or false in the logs and the list of items re-render, the collection itself doesn't show the newly added item

💁 Possible Solution

I swear ive double and triple checked traditional caching issues ive run in to before (duplicate ids, not using dependency array) and i still cannot get it to work. I did some investigation and the TLDR i've come up with so far is:

State that lives inside a component rendered within Select's Popover seemingly can't control which items exist in the collection. Maybe it's because Select renders a hidden copy of its children to build the collection, so any useState inside that subtree is a separate instance from the one I interact with in the visible UI? As a result, toggling local state in the real tree doesn't affect the hidden tree's copy, so the collection never updates. The fix I've found is to lift any state that controls collection structure above the Select.

I also confirmed that if you remove the Virtualizer, it still is a problem.

Is this something that is necessary or worthy of tracking as a bug?

🔦 Context

I'm just trying to implement a select component that shows a deselect option if a value in the select is defined.

It's probably worth watching all 3 in a row first to understand what I'm finally trying to accomplish.

1. Trying to use useContext (cannot get Clear selection to show after I select an item and reopen the Select) ❌

Screen.Recording.2026-06-13.at.2.09.37.AM.mov

2. Trying to use local useState (cannot get Clear selection to show after I select an item and reopen the Select) ❌

Screen.Recording.2026-06-13.at.2.10.16.AM.mov

3. Trying to use parent useState (allows the Clear selection to show) ✅

Screen.Recording.2026-06-13.at.2.14.35.AM.mov

🖥️ Steps to Reproduce

Stackblitz: https://stackblitz.com/edit/vrrrd46r?file=src%2FExample.tsx

useContext case (fails)

1. Click the Select component, and note that no item is selected yet
2. Select an Option, the popover closes
3. Now if you open it again, you won't see the "Clear selection" option (but i want it to)

useState case (fails)

I tried forcing this by adding a toggleable useState boolean to see if it was a problem with the useContext (spoiler: it's not)

1. Go to line 47-48 of Example.tsx and comment out const isClearable = isClearableFromSelectContext; and uncomment const isClearable = fakeClearable;
2. Repeat steps 1-3 of useContext case above

What DOES work is if you hoist the useState into the parent of DebugListBox and pass fakeClearable as a prop of DebugListBox.

Version

1.18.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

MacOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[nwidynski]

I think this is expected behavior, due to how collection internals work, although I would have to dig to confirm. TLDR; is that you are essentially trying to update the "hidden" subtree with a state update that only happens in the "real" subtree. In this case, the branch point for "hidden" and "real "subtree is the Select component - hence why hoisting the state above that line fixes things.

@snowystinger I've seen some variant of this misunderstanding in issues a couple of times by now. Maybe it's worth thinking about adding a section in the docs to clarify the behavior and visualize the boundaries.

[uncvrd]

Thanks for the quick response, i was pulling my hair out trying to understand why a state variable toggle wasnt changing visibility. Never seen something like this before! Haha... I'd almost recommend some sort of dev console warning if possible

[nwidynski]

Haha, I can imagine! Implementing custom collection components is definitely an advanced use case at the moment.

Unfortunately there aint much we can do to provide automatic console warnings for this type of thing, since the subtree is unbeknownst to a collection-building component (e.g. Select), and even if that were not the case we would have trouble differentiating a "normal" rerender from one that is intended to mutate the collection document.

The best I think we can aim for, is to do a better job explaining the internal phases of collection building and to clarify that, whenever you want to mutate the collection through JSX, then those changes must be triggered by state that lives above the builder.

This is because builders need to parse your JSX tree (not the return of your JSX but rather the JSX itself) in order for them to declaratively build a collection. To do that, builders render a "hidden" version of their subtree up to each item boundary. Only once that is finished, does the "real" state get created and content is rendered, which is what you interact with.

It should then be obvious why a JSX change needs state to be placed above the builder - because you need to kick off both JSX and content phase rebuild, and not just the later.

I hope that makes it easier to understand.

[NssGourav]

Since this seems to be a documentation issue, I'd love to help out!

I can put together a PR that adds a section explaining the collection building phases and where state needs to live to mutate JSX collections. Let me know where this documentation would fit best (example the Collections architecture page or the Select component page).

[snowystinger]

Probably best in the Collections page, this applies to all collections, not just Select