Кто-нибудь видел/работал с сагами в продукции которые не были сильным оверхэдом и на самом деле помогали ?

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

хотя периодически ловлю разработчиков которые саги пытаются влепить для простых вещей потому что "скучно хочется потыкать"

Просто часто есть такое что человек услышал про саги/другуютехнологиюХ и бежит сразу применять везде где можно без обдумывания пронс и конс

Что уж говорить сам не без греха

То же самое говорю про redux-saga и топлю за хуки

все верно, свои шишки больнее, чем чужие) а как еще научиться?

а потом видишь в коде хуки в стиле

const onClick = useCallback(() => {}, [
   all, props, in, the, component, just, because, we, need, to, use, hooks
])

По поводу саг - часто их оверюзят из-за фич вроде таймаутов. Во всяком случае я часто такое вижу - хочется выполнить задачу через 30 секунд - сага. Надо трекать когда чёт завершилось - вешаем тайм-аут на 10 секунд что б забрать инфы

У меня есть кейс когда мне прям сага нужна что б ходить в апишки внешние - но мне там сага сравнивает ответы и кидает сообщения если чёт поменялось. Просто удобно хотя саги тут не обязательно. Скорее я выбрал стратегию с компитинг консюмерами и для этого кейса удобно стэйт процесса менеджить через саги

Вакансия: Архитектор системных моделей
Компания: Концерн ВКО Алмаз-Антей, Москва

Анализ и детализация требований, этапность и разработка архитектуры ПО.
Работая в нашей команде, Вы получите:
• Бесценный опыт быстрой разработки систем на базе Model Based Design (не годы, а месяцы на проект);
• Выполнение реальных интересных проектов (не «работа в стол»).
Обязанности:
• Создание архитектуры сложных оптико-электронных комплексов на основании требований
• Продумывание интеграции моделей различной физической природы в единую системную модель
• Выбор наилучшего средства для реализации математической модели
• Организация процесса разработки изделия по методике модельно-ориентированного проектирования.
Требования:
1. Хорошее знание инструментов моделирования Simulink и Simscape
2. Понимание современных процессов разработки ПО (архитектура, потоки данных, CI/CD)
3. Уверенное знание теории автоматического управления
4. Умение обосновывать выбор технического решения команде.
Условия:
• Оклад согласно уровню подготовки
• ДМС, полностью белая ЗП
• Адаптивное начало дня (можно согласовать с руководителем)
• Корпоративный трансфер от м. Славянский Бульвар и м. Парк победы.

Можно откликнуться по ссылке или резюме в личку: @Alex_exponenta

Даже в теории не становится. Каждый "малэнкий штук" требует создания своей копии-заглушки для тестирования других. Это минимум. Сравни с послойной архитектурой, где тестировать нужно только API слоя. Тут как бы и говорить не о чем.

pact.io - и нет проблем

> Сравни с послойной архитектурой, где тестировать нужно только API слоя.

сравниваю. ты дернул api метод и оно потрогало 30% кода твоего приложения - хуй знает что оно потестило хуй знает как все пермутации проверить

Нет, вызов API затрагивает только часть кода только этого слоя и это никак не 30% и даже не 5, а с учетом модульных тестов все еще проще. Остальные слои тестируются по принципу матрешки.

даже больше - можно так же делать контракты и в монолите. Вместо "дернул api метод и оно там пошло трогат ьвсе подряд" жестко определяешь заглушки между "модулями".

ну да ну да

матрешки... слои...

пойду посмотрю на свою "матрешку" и репорты каверджа и буду смотреть где там слои