Definitelytyped: response-select: Select.onChange вводит неверно (?)

Я нашел это совершенно запутанным.

value в дескрипторе - это массив выбранных опций (при использовании isMuli prop).

_onTagChange(
  value: ReactSelectTypes.ValueType<{value: number; label: string}>,
  action: ReactSelectTypes.ActionMeta
) {
  console.log('l68:', value, ' action:', action);
  switch(action.action) {
    case 'pop-value':
    case 'remove-value':
  }
  if (value && value.length > 0) {
   e let firstOption = value[0]; // Errors here with: Element implicitly has an 'any' type because type '{ value: number; label: string; } | { value: number; label: string; }[]' has no index signature.

  }
  // this.setState({ categoryTags: tags });
}

Первый аргумент обработчика onChange не может просто иметь тип OptionType , поскольку он может быть одно-, многозначным или не иметь значений OptionType .

См. Https://github.com/JedWatson/react-select/issues/2902 для более подробного обсуждения обработчика onChange в сочетании с TypeScript.

@rvanlaarhoven - Обновлен OP, чтобы принимать одиночный или массив. IMO массив должен быть передан обработчику независимо от того, выбран ли select isMulti . Мы должны просто ожидать массив и не проверять, является ли параметр массивом. Но да ладно ...

Я согласен с @JoshMcCullough
Было бы проще, если бы нам приходилось иметь дело только с одним типом данных, в данном случае с массивами.
Если мы используем одиночный выбор, мы просто берем единственный элемент из массива, иначе мы работаем с массивом - никаких дополнительных проверок не требуется. В то же время я понимаю, что это непростое изменение при работе с такой библиотекой.

Больше всего меня раздражает то, что возвращается массив или одно значение в зависимости от значения isMulti . Это означает, что система типов уже должна знать тип onChange .

Можем ли мы сделать какое-то объединение или условную типизацию, чтобы решить эту проблему? (предупреждение: непроверенные идеи)

interface BaseProps<OptionType extends OptionTypeBase = { label: string; value: string }> extends SelectComponentsProps {
  ... /* all existing fields except isMulti and onChange */
}

interface SingleValueProps<...> extends BaseProps<...> {
  isMulti: false;
  onChange: (value: OptionType | null | undefined, action: ActionMeta) => void;
}

interface MultiValueProps<...> extends BaseProps<...> {
  isMulti: true;
  onChange: (value: OptionsType<OptionType> | null | undefined, action: ActionMeta) => void;
}

/* where the props are defined */
selectProps: SingleValueProps<...> | MultiValueProps<...>

или возможно

interface Props<IsMulti extends boolean, OptionType extends OptionTypeBase = { label: string; value: string }> extends SelectComponentsProps {
  ...
  isMulti: IsMulti,
  onChange: (value: ValueType<IsMulti, OptionType>, action: ActionMeta) => void;
  ...
}

export type ValueType<IsMulti extends boolean, OptionType extends OptionTypeBase> =
  (IsMulti extends false ? OptionType : OptionsType<OptionType>) | null | undefined;

РЕДАКТИРОВАТЬ: подумав об этом еще раз, тип можно вывести, если вы жестко запрограммируете isMulti (например, <Select isMulti={false} /> но не, если вы предоставите такой оператор, как <Select isMulti={getValue()} /> , поэтому эта стратегия наверное не сработает.

Как использовать текущее определение без ошибок компилятора?

Кажется, что проверки isArray уже недостаточно, поскольку тип не OptionType | OptionType[] и машинописный текст не может вывести его.

В качестве обходного пути я использовал утверждение типа:

props.onChange((v as YourOptionTypeHere).value);

Доступен ли интерфейс (Typescript) для мульти-значения undefined, Array<Option>, Option ?

@hoetmaaiers Вы могли бы стать помощником:

type Nullable<T> = T | null | undefined;

В качестве обходного пути я определил интерфейс:
interface iOption { label: string; value: string; };

А затем передал параметр:
onChange={(option) => myMethod((option as iOption).value) }

использование as уничтожает всю цель использования машинописного текста. Кто я должен получить выгоду от

option: ValueType<{value :string, label: string}>

без использования as ? Текущий обходной путь не является решением и может (вероятно, приведет) к ошибкам в будущем.

У меня все еще есть эта проблема, и это действительно раздражает, когда при каждом onChange (потому что я не использую какой-либо множественный выбор) приведение к единственному типу параметра ....

Каждый раз, когда я должен использовать item => (item as OptionTypeBase) .value. Действительно плохо.