I was thinking about making this component a wrapper to EuiPopover that displays a badge and gets array of items and a render function but there are few issues with that approach:

1. if vulnerability.id = ['a'] in that case if we don't render the first item here then the consumer should render it. So we will end up with a '+ 0' text in the badge since we are displaying the amount of items left - 1. That leads to the next issue.
2. To avoid displaying '+ 0' badge we need to check if the array's length is bigger than 1 - in that case we rely on the consumer to display the first item - IMO it leads to split responsibility between consumer and component, risk of inconsistency if conusmers doesn't handle single item case and if we add items.length - 1 logic to the component it is coupled with display logic.
   E.G consumer will do something like this:
   

therefore we hide this logic in the component and render it as it is or allow the user to pass optional param firstItemRenderer function to handle the first item rendering. So this component handles the first item and the subsequent ones are rendered in the popover. it is possible to render only the badge and pass firstItemRenderer as an empty function.
Other params are:

• items , which are the items to be renders in the popover.
• field - the field we are rendering - e.g 'vulnerability.id', 'package.name' etc.
• object - the object which the value is extracted from, needed for the renderItem callback.
• renderItem function - renders each item in the popover
• firstItemRenderer optional - custom render function to handle first item.

I think the proposal makes sense, as it aims on flexbility and reusability

please use z index from euiTheme

please use z index from euiTheme

Yes, z-index levels can be tricky to maintain. As an example, if everyone were using arbitrary values, Kibana could end up with several components overriding each other, so ideally, we should use the appropriate levels token according to the context where it's being rendered.

Also, could you consider taking a look at EuiPortal instead of createPortal to see if it works for us? It seems to work by relying on using natural order where it adds the element of the portal on the end of the page, so it leverages natural z-index stacking, and then we (hopefully) wouldn't even need to worry about z-index

@JordanSh @opauloh updated z-index to use euiTheme.levels.modal instead. regarding EuiPortal, I tried to use it originally but it didn't render properly. Maybe I'll do some research separately to understand what is the difference.

a small ux improvement could be that regardless of the columns width, the expand badge should always show. meaning the text should truncate to fit the column's width including the expand badge. it shouldn't be too complicated but if that turns out to be so, its not a must

@JordanSh you mean the expand badge which is the first column or the cve column badge?

i suggest to use 'add-filter' 'remove-filter' instead of +-
also, im not sure but i think we already have a hook that does that, or maybe it was removed when we changed to the UnifiedDataTable? @opauloh do you know?

@JordanSh I'm using filterManager which is what is used in other places, and since it accepts '+' or '-' types I don't see the reason to create another type and then map it to this type.
const onAddFilter = useCallback<AddFieldFilterHandler>( (clickedField, value, operation) => { const newFilters = generateFilters(filterManager, clickedField, value, operation, dataView); filterManager.addFilters(newFilters); setUrlQuery({ filters: filterManager.getFilters(), }); }, [dataView, filterManager, setUrlQuery] );

export type AddFieldFilterHandler = ( field: string, value: unknown, type: '+' | '-' ) => void;

kind of a nit pick since its only within this function's scope but i would suggest not to use generic names like 'object', you could call this a finding or a document, it makes the rest of the code easier to read

@JordanSh Its not necessarily a finding or a document it could be any json. Regarding the naming I changed the function name to better represent what we are rendering when passing it as a param but the 'object' name should remain because the signature of the callback function is:
interface MultiValueCellPopoverProps<T, K = string> { items: K[]; field: string; object: T; renderItem: (item: K, i: number, field: string, object: T) => React.ReactNode; firstItemRenderer?: (item: K) => React.ReactNode; }

please use z index from euiTheme

Yes, z-index levels can be tricky to maintain. As an example, if everyone were using arbitrary values, Kibana could end up with several components overriding each other, so ideally, we should use the appropriate levels token according to the context where it's being rendered.

Also, could you consider taking a look at EuiPortal instead of createPortal to see if it works for us? It seems to work by relying on using natural order where it adds the element of the portal on the end of the page, so it leverages natural z-index stacking, and then we (hopefully) wouldn't even need to worry about z-index

I think the proposal makes sense, as it aims on flexbility and reusability