Comments 7
Почему не генерировать типы сразы из open api контракта который вы согласутете с бекендом? С помощью того же kubb. Тогда переделывать гораздо меньше прийдется.
Почему нужно закладывать сложность на расхождение? Здесь у вас процесс диктует архитектуру. В большинстве случаев когда у вас просто связка бек-фронт (1:1), вы можете диктовать бекенду то каким должно быть api, а бекенд должен быть клиентоориентирлванным. API это продукт и он делается под потребности потребителей.
Имхо грустно когда две команды не могут договорится об общем контракте и нужно еще маперы писать на фронте. Бывает еще BFF засовывают с мапперами.
Плюсану. Как минимум, пока не готов бэк, можно сформировать либо фронту, либо бэку простой OpenAPI схему, прогнать через kubb / orval и т.п. генераторы, чтобы не плодить вручную типы со схемами и клиенсткими запросами.
Затем по готовности готового бэка, обновить OpenAPI схему, заново сгенерировать клиентский код, получить подстветку в коде, где нужно заменить методы, типы, схемы и т.п. Тем самым исключая рутинные задачи в традиционной фронтенд разработке с обвязкой бэка.
По поводу генерации типов с бека был грустный опыт на предыдущем проекте: проект был большой и динамичный, типы приезжали новые каждый день и мы каждый день начинали с починки сборки. ИМХО это подходит, когда проект уже входит в более спокойную стадию. А здесь у нас просто не та ситуация - несколько источников данных и не всегда они просто в состоянии отдать в наиболее простом виде структуры. В частности в CMS Directus есть ограничения. Не всегда удвется это предсказать
Да все ваши варианты один сплошной минус. Изобретаете велосипед там, где не надо. Прозрачности разработки нет. Постоянно надо перед выкаткой удалять, либо жонглировать состоянием что использовать моки или реальные сервисы. Код становится мусорным как раз из-за лишних примесей. Как тестировать сервисы тоже неясно. Из логики поста мне для каждого сервиса необходимо написать N вариантов моков для каждого из случаев! Ах да, заголовок же как раз про 200к LOC Отличная идея выжечь команду на первом же проекте!
А всего-то надо взять и подключить msw в режиме разработки и всё Сервисы работают как и задуманы без лишних включений. Нет лишних мок-непонятных компонентов. Код прозрачный и пишется так как он и должен. Моки живут отдельно от продакшнена и их нет в бандле. Тестирование ускоряется за счёт автогенерации...
Речь не про сервисы, а про фронтовые компоненты.
Никаких моков в бандле и так нет - они использованы для покрытия тестами разных вариантов компонента. Зачастую достаточно большие компоненты существуют только в сторибуке и дают при разработке полную картину компонента, не заставляя тестировщика разыскивать эти варианты в разных местах сайта. Поэтому мы имеем полностью протестированные компоненты еще до интеграции. И 200000 строк, поверьте, не от моков.
Чтобы делать автогенерацию, нужно ее от бека получить, а именно этого и нет. И не всегда она так хороша - выше ответ был
Я бы посоветовал вам разобраться как происходит сборка банда. Вы же сами пишете, что создаётся рутовый компонент на и основе которого создаются другие компоненты для сторибука + интеграция сервиса с моком и всё это отдается наружу для тестирования. Возникает вопрос - Зачем? Какую задачу вы решаете?
Если вы думаете, что у вас будет проблема с вёрсткой, то это решается путем углубленного изучения css. Если вам надо проверять функциональную часть, то для этого пишутся юнит тесты. QA команда должна тестировать вашу разработку только в реальных условиях иначе ценность таких проверок околонулевая. Это уже проверено, сколько бы аккуратно не пишется код, а в реальных условиях всё равно будут отклонения.
Вам бы действительно с бэком договориться, как тут уже сказали. Если они могут сделать open api схему, то это сильно вам упростит жизнь.
Дальше про моки из апи клиента. Мысль хорошая, но это уже решили до вас с помощью msw. Дальше все становится все очень просто. Вы мокаете напрямую запросы к беку, включая их локально либо на дев-сервере, а в прод они просто не уезжают
Фронтенд обгоняет бек или как мы написали 200_000 строк кода на моках