Чтобы не прыгать с проверкой типа DTO нужно прикручивать валидацию ответа. yup/zod - чуть дольше, но гарантированно на выходе правильный тип. Тема с satisfies раскрыта слабо
Ну вы решили вполне себе частную задачу на один раз и это нормально. А вот с написанием кода так чтобы его можно было потом поддерживать и отлаживать возникают проблемы. И возникают они именно из-за вот таких, без обид, как вы, которые “немного понимаю код” Такой подход напрочь убивает какую-либо оптимизацию и архитектурные походы, что в свою очередь ведёт к тому что общий проект становится фрагментирован на различные участки кода написанные разными ИИ разными людьми в разном стиле
Ну и кому ты что пытаешься донести? Очевидный факт что МС сознательно тормозят открытие своего стандарта. Оно и понятно, что не охота терять деньги. И твой опус на и этом фоне выглядит как попытка натянуть сову на глобус
И в каком месте тут реактивность? Обычный прямой вызов функции. Вы лучше покажите как при клике кнопки в табе уходит запрос, его ответ корректно обрабатывается и потом отображается в виде датасета или таблицы, которая умеет работать с этим же запросом - сортировка/фильтрация, и вот тогда поговорим о реактивности)
Отказ от undefined не спасет от криворуких кодеров. Ну не тут, так в другом месте напишут такое, что будет падать. И сделают они это со свойственной им тупизной. ТС, конечно, накидывает на вентилятор - кто сейчас в js проверяет опциональные свойства когда для этого есть специальный оператор?
И если кандидат не прошел, то я ему ставлю отметку - "Не соответствует уровню, заявленному в резюме". Второго шанса у таких кандидатов нет. А ещё работодатель может оставить отзыв на ХХ, который к кандидат не увидит, но этот рейтинг будет влиять на дальнейший подбор вакансий.
Хм... Враньё и использование ИИ. Ну да, ну да. Я провел 200+ собеседований и скажу вам так, что практически любые попытки обмана раскрываются на раз два. Достаточно задать пару нестандартных вопросов или дать небольшую задачку на code review и сразу становится понятно кто перед тобой... Проблема в том, что сегодняшний Джун не хочет сначала поработать за маленькие деньги в ООО Рога и Копыта. Ему надо сразу оверпрайс. Но, простите, с какого? А ваши советы врать могут привести к тому, что кандидат просто попадет в ЧС и второй раз его просто рассматривать не будут! Враньё с самого начала это путь в никуда. Другое дело когда интервьюер такой же бездарь и вот с этого момента начинается деградация ИТ
Я бы посоветовал вам разобраться как происходит сборка банда. Вы же сами пишете, что создаётся рутовый компонент на и основе которого создаются другие компоненты для сторибука + интеграция сервиса с моком и всё это отдается наружу для тестирования. Возникает вопрос - Зачем? Какую задачу вы решаете? Если вы думаете, что у вас будет проблема с вёрсткой, то это решается путем углубленного изучения css. Если вам надо проверять функциональную часть, то для этого пишутся юнит тесты. QA команда должна тестировать вашу разработку только в реальных условиях иначе ценность таких проверок околонулевая. Это уже проверено, сколько бы аккуратно не пишется код, а в реальных условиях всё равно будут отклонения.
Да все ваши варианты один сплошной минус. Изобретаете велосипед там, где не надо. Прозрачности разработки нет. Постоянно надо перед выкаткой удалять, либо жонглировать состоянием что использовать моки или реальные сервисы. Код становится мусорным как раз из-за лишних примесей. Как тестировать сервисы тоже неясно. Из логики поста мне для каждого сервиса необходимо написать N вариантов моков для каждого из случаев! Ах да, заголовок же как раз про 200к LOC Отличная идея выжечь команду на первом же проекте! А всего-то надо взять и подключить msw в режиме разработки и всё Сервисы работают как и задуманы без лишних включений. Нет лишних мок-непонятных компонентов. Код прозрачный и пишется так как он и должен. Моки живут отдельно от продакшнена и их нет в бандле. Тестирование ускоряется за счёт автогенерации...
Сейчас бы в 2025 быть фулстеком, учитывая какое количество требований появилось как на BE, так и на FE. Если склеить две любые вакансии бек/фронт, то уверяю получится список на 2-3 страницы. Чтобы соответствовать всем этим требованиям вам нужно минимум 3-5 лет работы со всем этим барахлом. При этом, что ценник у фулстека не х2. Просто компании хотят вместо двух разработчиков нанять одного универсала...
Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Напоминает BolgenOS)
Чтобы не прыгать с проверкой типа DTO нужно прикручивать валидацию ответа. yup/zod - чуть дольше, но гарантированно на выходе правильный тип. Тема с satisfies раскрыта слабо
Ну вы решили вполне себе частную задачу на один раз и это нормально. А вот с написанием кода так чтобы его можно было потом поддерживать и отлаживать возникают проблемы. И возникают они именно из-за вот таких, без обид, как вы, которые “немного понимаю код” Такой подход напрочь убивает какую-либо оптимизацию и архитектурные походы, что в свою очередь ведёт к тому что общий проект становится фрагментирован на различные участки кода написанные разными ИИ разными людьми в разном стиле
Ну и кому ты что пытаешься донести? Очевидный факт что МС сознательно тормозят открытие своего стандарта. Оно и понятно, что не охота терять деньги. И твой опус на и этом фоне выглядит как попытка натянуть сову на глобус
Серьезно? Тебе до сих пор нужна поддержка форматов word95/98 ? Ты плохой тролль
И в каком месте тут реактивность? Обычный прямой вызов функции. Вы лучше покажите как при клике кнопки в табе уходит запрос, его ответ корректно обрабатывается и потом отображается в виде датасета или таблицы, которая умеет работать с этим же запросом - сортировка/фильтрация, и вот тогда поговорим о реактивности)
Отказ от undefined не спасет от криворуких кодеров. Ну не тут, так в другом месте напишут такое, что будет падать. И сделают они это со свойственной им тупизной. ТС, конечно, накидывает на вентилятор - кто сейчас в js проверяет опциональные свойства когда для этого есть специальный оператор?
И если кандидат не прошел, то я ему ставлю отметку - "Не соответствует уровню, заявленному в резюме". Второго шанса у таких кандидатов нет. А ещё работодатель может оставить отзыв на ХХ, который к кандидат не увидит, но этот рейтинг будет влиять на дальнейший подбор вакансий.
Хм... Враньё и использование ИИ. Ну да, ну да. Я провел 200+ собеседований и скажу вам так, что практически любые попытки обмана раскрываются на раз два. Достаточно задать пару нестандартных вопросов или дать небольшую задачку на code review и сразу становится понятно кто перед тобой... Проблема в том, что сегодняшний Джун не хочет сначала поработать за маленькие деньги в ООО Рога и Копыта. Ему надо сразу оверпрайс. Но, простите, с какого? А ваши советы врать могут привести к тому, что кандидат просто попадет в ЧС и второй раз его просто рассматривать не будут! Враньё с самого начала это путь в никуда. Другое дело когда интервьюер такой же бездарь и вот с этого момента начинается деградация ИТ
Я бы посоветовал вам разобраться как происходит сборка банда. Вы же сами пишете, что создаётся рутовый компонент на и основе которого создаются другие компоненты для сторибука + интеграция сервиса с моком и всё это отдается наружу для тестирования. Возникает вопрос - Зачем? Какую задачу вы решаете?
Если вы думаете, что у вас будет проблема с вёрсткой, то это решается путем углубленного изучения css. Если вам надо проверять функциональную часть, то для этого пишутся юнит тесты. QA команда должна тестировать вашу разработку только в реальных условиях иначе ценность таких проверок околонулевая. Это уже проверено, сколько бы аккуратно не пишется код, а в реальных условиях всё равно будут отклонения.
Да все ваши варианты один сплошной минус. Изобретаете велосипед там, где не надо. Прозрачности разработки нет. Постоянно надо перед выкаткой удалять, либо жонглировать состоянием что использовать моки или реальные сервисы. Код становится мусорным как раз из-за лишних примесей. Как тестировать сервисы тоже неясно. Из логики поста мне для каждого сервиса необходимо написать N вариантов моков для каждого из случаев! Ах да, заголовок же как раз про 200к LOC Отличная идея выжечь команду на первом же проекте!
А всего-то надо взять и подключить msw в режиме разработки и всё Сервисы работают как и задуманы без лишних включений. Нет лишних мок-непонятных компонентов. Код прозрачный и пишется так как он и должен. Моки живут отдельно от продакшнена и их нет в бандле. Тестирование ускоряется за счёт автогенерации...
Сейчас бы в 2025 быть фулстеком, учитывая какое количество требований появилось как на BE, так и на FE. Если склеить две любые вакансии бек/фронт, то уверяю получится список на 2-3 страницы. Чтобы соответствовать всем этим требованиям вам нужно минимум 3-5 лет работы со всем этим барахлом. При этом, что ценник у фулстека не х2. Просто компании хотят вместо двух разработчиков нанять одного универсала...
structuredClone - "Да, да, пошёл я на хер!"
Ещё бы заглянуть в бандлы, собранные с target: es2015 и ниже, тогда у автора инфаркт будет)
Это называется по-другому - я что-то накодил такое, что нормально нельзя покрыть юнит-тестами, но переделывать не буду, т.к. тесты отстой, а я гений!
Бегите из такой разработки. Это хаос и отсутствие системного подхода.
Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Ничего интересного. Перед однокурсниками выпендриваться)