Aetae

Ну в комменте уже ответили, что приходит тебе не совсем то, что ты там в типе написал.
Рекомендую не писать руками интерфейсы для готового json, лучше тыкнуть в консоли на ответе "Copy object" и вставь в любой конвертер, который гуглится по "json to ts", например https://app.quicktype.io/. Так ты точно не ошибёшься, а потом уже можешь уточнить тип руками.

В идеале, конечно, неплохо бы каждый ответ от сервера считать unknown и прогонять через тайпгард, проверяя руками, что он соответствует типу, но это не частая практика, увы.

Никак. Использовать два стейта.

А ты для начала придумай синтаксис для этого, который бы не вступал в прямой кофликт с JS и при этом был интуитивен.)
Вот тут на тему много копий сломано, но, ИМХО, нет нормальных достойных релиза вариантов.)

Где-то среди >260 свойств из React.ComponentPropsWithRef<'select'> находится свойство, которое дженерик Option в Select устанавливает как string | number с большим приоритетом, чем то что ты кладёшь собственно в Options. Можешь поискать сам убирая по одному или сравнивая с декларацией для Select.

Но в принципе решение просто выкинуть React.ComponentPropsWithRef<'select'>, т.к. ты расширяешь не нативный select, а react-select.

import Select, { Props } from 'react-select';

interface ISelectProps extends Props<OptionType> {
    caption?: string;
    disabled?: boolean
}

[ {title: string, cardList: []} ] - это не массив, заполняемый значениями типа {title: string, cardList: []}, это кортеж из одного значения данного типа.
Массив обозначается так Array<{title: string, cardList: []}> или так {title: string, cardList: []}[].
Кортеж используется когда нужно конкретное количество значений конкретного тип на конкретных позициях.

Если не используете Node.js то просто исключите типы для неё из конфига TS.
Тогда у вас setTimeout будет возвращать простой number, а clearTimeout будет принимать number | undefined. И никаких проблем.)

Если же код ноды по каким-то причинам у вас идёт вперемешку со фронтовым кодом, то для фронтовых таймеров можете писать явно window.setTimeout и window.clearTimeout.

Не слушай Василий Банников, плодить копипаст-типы точно не надо.

А по размещению типов точно такая же логика как с обычными модулями. Так что абсолютно нормально импортировать связанные типы из связанного модуля. Все теории и паттерны проектирования применяются и тут.

По хорошему конечно стоит придерживаться SOLID или чего-то подобного.
Т.е. в Grid сделать тип IGridItemProps с теми свойствами которые точно нужны для работы Grid, а в GridItem наследовать от него уже конкретную реализацию

interface GridItemProps extends IGridItemProps { ... }

. Однако это нужно только если теоретически могут появиться ещё GridItemSuper и GrigItemNice, если же такого быть не может и модули(компоненты) сами по себе тесно связны, то заморачиваться не стоит.

Всё работает, ищи ошибку в другом месте:

Ну какбэ если поля должны быть на одном экране то 1., если на нескольких шагах то 2.
Если ты именно что выбираешь между опциями, то зачем ты делаешь работу дизайнера?)

В целом - не имеет значения.

P.S. Если получается громоздко - что-то у тебя не так с инпут-элементами. Если тебе приходится им прописывать одно и тоже - сделай обёртку юзающую контекст\provide, в коде не должно быть повторов.

let key: keyof EventStatusType;
for (key in eventTypes) {

Typescript не может автоматически вывести тип key потому что он структурный, и никак не может знать, что в объекте точно нет ещё каких-нибудь ключей, кроме тех что указаны в типе EventStatusType:

const foo = {
   Closed: false,
   Maintaince: false,
   Open: false,
   внезапно: 'Вася'
};

const bar: EventStatusType = foo; // ok

Поскольку с помощью кода в начале ты фактически говоришь Typescript: "я знаю лучше, там точно не будет ничего другого", то на всякий непредвиденный случай следует добавить в switch default который что-то сделает(например кинет ошибку) если таки лишний неведомый ключ прилетит.

P,S. А ещё у тебя в имени одного ключа опечатка: Maintaince и Maintenance.