[combobox] Value gets cleared when items change

[sarthakmalik0810]

Bug report

Current behavior

I believe #3607 has caused a regression for a component I have built, but this should affect other people as well.

I have a Combobox where items are fed by an API. When you choose a value, and then search for something else, the value gets cleared (onValueChange is called with null) and onInputValueChange is called if the items do not contain selected value.

This will also fail, if you were coming back to editing a form after saving and refreshing and your data is fed by a paginated API, where your selected item might be on the last page. The value will be cleared because the selected item will not be present in items.

Screen.Recording.2026-01-22.at.1.21.14.AM.mov

This issue is not reproducible in v1.0.0.

I believe this is a valid use case and should be supported.

Expected behavior

The value should not be cleared.

Reproducible example

I have rebuilt this example from #2760

https://codesandbox.io/p/sandbox/gallant-meadow-x2r7d2

Base UI version

v1.1.0

[atomiks]

It's intended that the value gets cleared if the selected item gets removed from items. The PR fixed a bug where the state wasn't reflected in controlled mode to users externally, which would cause this

Have you tried using filteredItems to display the filtered items from the API, while ensuring items always retains all the items/the selected item? Async search single mentions this but it's a different pattern

[sarthakmalik0810]

Have you tried using filteredItems to display the filtered items from the API, while ensuring items always retains all the items/the selected item?

I don't think guaranteeing that the items will always have the selected value is possible in an async Combobox. I will be using this Combobox for employees at a company and there could be 100,000 of them. When you search for their names, it's not guaranteed that the selected user will be returned from the API. I am not sure whether always passing in selected value in the items manually by always appending to the list is reasonable here.

This would also fail in the case where you were editing a previously saved form, and you don't have the full info coming back from the api which would feed the items prop.

[ndozhh]

Hi @sarthakmalik0810 I don't know if this fixes your issue but, I was getting a similar behavior using the combobox with react-hook-form. When going from value A to B, there was a flash of an empty value before setting the new value on the form state. I added this and the flash disappeared:

isItemEqualToValue={(itemValue, selectedValue) =>
        itemValue?.value === selectedValue?.value
      }

[eckmLJE]

When my team created our async select using react-select and react query, we needed to support the select initializing with a value where the resource was paginated, and we ran into a similar issue where the value was usually not available in the first page. When mounting the select e.g. in some saved form, we would have the ids of the selected values but not their labels.

We solved this by using two queries per select. One for the selected value(s) where we'd get by ids, and one for paginated results for the options menu. We'd fetch the item metadata in the select, and we'd need both the first page of options to display in the menu and the metadata for the selected values.

const { data: selectedItems = [] } = useItems({ id: selectedItemIds });
const { data: optionItems = []} = useItems({ query: searchQuery });

const options = [...selectedItems, ...optionItems];

<Select options={options} ... />

When selecting new items, as an optimization to prevent a loading state, we would use setQueryData in the Select's onChange with the next selected items (with the next query key from those ids) so the items would be available immediately. Something like this (from memory so I'm probably missing something)

const onChange = nextValue => {
  const nextValueIds = nextValue.map(({ id }) => id);
  const nextQueryKey = makeItemsQueryKey(nextValueIds);
  queryClient.setQueryData(nextQueryKey, nextValue);
  setSelectedItemIds(nextValueIds);
}

When you render again from the selected item ids state update, the query value is already populated for those ids and you skip the loading state.

Alternatively you could load the initial value in a parent and initialize a state variable in the select with that initial value, and just set state into that.

[sarthakmalik0810]

I think when we say Combobox is controlled, it should actually allow value initialisation and selection from outside, and also allow orphan values regardless of items list. Change in items, should not cause unselection.

We can't use filteredItemsbecause you would still have to pass in selected values in items, and when you are calling an API, those selected values might come back in the 10th page as you scroll, and you would have to add an extra filter to filter out selected values from items so that they are not duplicated. I don't think this is feasible and the API seems a bit confusing for an asynchronous combobox.

[atomiks]

also allow orphan values regardless of items list. Change in items, should not cause unselection.

I think this can be reasonable

The reason Combobox originally did this was to match Select/<select> behavior, where if a <Select.Item>/<option> disappears from the list, it unselects the value (https://codesandbox.io/p/sandbox/rkh4fm) with the difference being we support null, so it doesn't fallback to the first value. However, the value state actually still remains "a" with <select>.

Combobox could both prevent de-selection if the value disappears from items, plus also retain the state (as in 1.0.0), to better support async items

[sarthakmalik0810]

@atomiks I have created another codesandbox with v1.0.0 where onInputValueChange is called with an empty query when the items change.

You would see the query clears when you search and the items load. Do you know why does this happen?

This is reproducible in v1.0.0 and v1.1.0.

[atomiks]

@sarthakmalik0810 seems related, as the PR to remove the effect that deals with the logic fixes it:

https://pkg.pr.new/mui/base-ui/@base-ui/react@3824

[github-actions]

This fix will be available in the next npm release of Base UI.

In the meantime, you can try it out on our Canary release channel:

npm i https://pkg.pr.new/@base-ui/react@3824

[ahmedd-osama]

The same issue happened with me. Works good on the canary npm i https://pkg.pr.new/@base-ui/react@3824