Aetae

TS тебе предельно понятно написал в чём проблема. Учись читать ошибки.

Конкретнее же: у тебя не задан тип значения которое может принимать контекст, а выведено самим TS - null(потому что именно такое значение по умолчанию ты передал).

export const Context = createContext<{
  sidebarIsOpen: boolean;
  toggleSidebar: (value: boolean) => void;
} | null>(null)

или лучше

export const Context = createContext({
  sidebarIsOpen: false,
  toggleSidebar: () => {}
});

Ну по enter у тебя же что-то происходит? Вот перед основным кодом триггерни blur руками:

document.activeElement.dispatchEvent(new Event('blur'));

Это конечно костыль, и по логике тебе надо написать кастомную обработку варианта с onChange, но и так, наверное, сойдёт.

Ну в комменте уже ответили, что приходит тебе не совсем то, что ты там в типе написал.
Рекомендую не писать руками интерфейсы для готового 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, в коде не должно быть повторов.