Eui: [EuiSelectable] type expects undefined `searchProps` with boolean type value for `searchable` prop

[BenAOlson]

The root of this issue is that searchProps cannot be used if the searchable prop is conditionally true or false; say, from a boolean prop, or some other logic that determines whether the EuiSelectable component should be searchable.

Steps to reproduce:

• Write an EuiSelectable component with searchable prop value that is boolean
• Add searchProps prop with any otherwise type-appropriate object
• Observe typescript error Type '[your valid prop object]' is not assignable to type 'undefined'

The example "spaces" component in the first example in the header documentation yields this issue, if that's helpful.

[thompsongl]

Hi, @BenAOlson

The use of ExclusiveUnion to define the searchable-searchProps restriction makes it difficult for TypeScript to validate your case. A workaround with a type guard like as follows should help:

```tsx
const isSearchable = 'yes' ? true : false;
let moreProps;
if (isSearchable) {
moreProps = {
searchable: true,
searchProps: {
compressed: true,
},
};
}

[BenAOlson]

So I guess I would say that the use of the ExclusiveUnion type is itself the problem. Glancing through the component code, I couldn't see any logic that made passing searchProps problematic in case searchable is false (and if that were the case, the examples in the documentation would need to be updated). To me, the issue is just that the type forces the use of an awkward and unproductive type guard in reasonable use-cases.

Sorry for even having this discussion as this is obviously more of an inconvenience issue than a real problem, but if you all are amenable to allowing the type to be made more accommodating, I would be happy to assist.

[chandlerprall]

Glancing through the component code, I couldn't see any logic that made passing searchProps problematic in case searchable is false (and if that were the case, the examples in the documentation would need to be updated). To me, the issue is just that the type forces the use of an awkward and unproductive type guard in reasonable use-cases.

You're likely correct that it would not cause a runtime error. Our inclusion of ExclusiveUnion has intended to provide feedback to developers when they are providing props that are not used, which can lead to bugs or otherwise unintended functionality - if I am providing a configuration that the component accepts I assume it does _something_.

Unfortunately, this occasionally leads to some awkward code gymnastics like the above workaround where it forces that decision making & knowledge to be present in the owning component.

[BenAOlson]

Ah, I see. Is there any interest in documentation examples being updated if they violate this (or other similar rules)? Recognizing that the documentation examples are all in plain JS, it still may provide some utility to other developers as we have already established that it is a best practice to clearly communicate when a prop is or is not definitely going to do _something_, and so there may be some confusion and/or bugs from JS developers building off of examples and leaving in props that are non-functional without the appropriate 'sibling' prop values. As a bonus, having mostly type-safe examples would make it less confusing to TS developers who try and copy and paste to start figuring things out.

Thanks for so much attention to such a small concern.

[chandlerprall]

Is there any interest in documentation examples being updated if they violate this (or other similar rules)?

Absolutely, the more we do to provide valid, thoughtful examples the better.