Вариантов на самом деле много. Этот был самый быстрый и в целом закрывал боли. Так же io-ts и подобные библиотеки можно использовать не только для взаимодействия с сервером, что закроет ещё несколько сценариев.
Но соглашусь, что вариант с io-ts для api не идеален, но гораздо лучше, чем принудительная типизация из any без проверок после fetch.
Это достаточно абстрактный пример. React немного избаловал, поэтому даже не резало глаз.
В принципе ничего страшного в описании типов на io-ts руками нет, так логика почти не отличается от обычных TS типов кроме пары моментов: опциональные поля в объекте и рекурсивные типы. Я посмотрел на superstruct-ts-transformer и не очень хочется его тянуть и добавлять магию :)
Насчет кодогенерации соглашусь, я тоже думаю в её сторону время от времени, но для этого нужно будет много времени потратить: изучить, настроить и переписать типы (если речь идёт про openapi). Хотя и в чистом виде io-ts всё равно нужно будет в нескольких местах использовать, которые не связанны с сервером. Пока цель была сделать работу комфортнее минимальными усилиями, что по ощущениям мне удалось.
Но соглашусь, что вариант с io-ts для api не идеален, но гораздо лучше, чем принудительная типизация из any без проверок после fetch.
В принципе ничего страшного в описании типов на io-ts руками нет, так логика почти не отличается от обычных TS типов кроме пары моментов: опциональные поля в объекте и рекурсивные типы. Я посмотрел на superstruct-ts-transformer и не очень хочется его тянуть и добавлять магию :)
Насчет кодогенерации соглашусь, я тоже думаю в её сторону время от времени, но для этого нужно будет много времени потратить: изучить, настроить и переписать типы (если речь идёт про openapi). Хотя и в чистом виде io-ts всё равно нужно будет в нескольких местах использовать, которые не связанны с сервером. Пока цель была сделать работу комфортнее минимальными усилиями, что по ощущениям мне удалось.