[EuiSearchBar] Surface change source on `onChange` so consumers can distinguish typing from custom-filter changes

[clintandrewhall]

Problem

EuiSearchBar.onChange is invoked from two internal entry points — onSearch (free-text typing) and onFiltersChange (a custom_component filter calling its provided onChange) — but both funnel through notifyControllingParent, which only forwards { query, queryText, error } to the consumer. The consumer cannot tell which path produced the change.

Use case

In @kbn/content-list-toolbar, Content List drives URL persistence via history.push vs history.replace:

• Typing keystrokes → history.replace (don't create one history entry per character).
• Committed filter actions → history.push (Back/Forward should move between filter states).

Because EUI doesn't expose the source, the toolbar currently has to wrap each custom_component filter in a tiny HOC that intercepts onChange before EUI sees it, dispatches with source: 'filter', and bypasses EUI's controlled-state notification entirely. A WeakMap<Component, WrappedComponent> cache is needed because CustomComponentFilter renders config.component directly, so a fresh wrapper per recompute would unmount/remount each filter's internals (popover state, debounce timers, in-flight facet queries).

Proposal

Plumb a source discriminator through notifyControllingParent into the consumer's onChange:

onChange?: (args: {
  query: Query | null;
  queryText: string;
  error: Error | null;
  source: 'search' | 'filters'; // new
}) => void;

Alternatively, expose a separate onFiltersChange prop so the typing path and filter path stay distinct from the top.

Either change would let @kbn/content-list-toolbar (and any other consumer that cares about intent) drop the per-component wrapper and the WeakMap cache, collapsing use_filters.ts to a single handleSearchChange that branches on args.source.

Workaround in tree

See wrapperCache / getWrappedFilterComponent / wrapCustomFilters in use_filters.ts, and the originating discussion at elastic/kibana#267632 (comment).

[clintandrewhall]

Quick update from the Content List side: we shelved the smart-history behavior that motivated this filing (see elastic/kibana#267632), so @kbn/content-list-toolbar no longer needs the source discriminator and the wrapperCache / getWrappedFilterComponent / wrapCustomFilters workaround has been removed.

This issue still seems worth addressing though — the underlying gap is real and likely to bite the next consumer that wants to differentiate committed filter changes from typing in EuiSearchBar. Posting so the issue can be triaged on EUI's own timeline rather than blocked on a Kibana use case that's currently dormant.

[JasonStoltz]

Thanks @clintandrewhall. We'll shelve this one in the backlog for now and we'll address it when/if the need arises. In the meantime, this issue documents it as a known issue along with a workaround.