Соглашусь со спеллчекером. Остальное, как и говорил - мусор. Для чего нужны "выразительные" комментарии? Все Todo будут автоматически собраны при генерации документации + настройте сонар, так он ещё и code smelt покажет. Что за инфантильность я, честно, не понимаю) Отступы в студии прекрасно видно в виде вертикальных серых линеек и без дополнительных плагинов.
BetterComments в помойку, для этого есть JSDoc, который заодно приучает писать документацию. Code Spell Checker туда же, ставим ESLint и настраиваем любые правила. К тому-же, VSCode можно настроить так, чтобы ошибки устранялись автоматически при сохранении с помощью этого линтера. Соответственно, rainbow тоже не нужен - настраиваем правило литера для отступов - студия сама подсветит и предложить вариант замены
Справедливости ради, разработка через msw все же на порядок быстрее и удобнее, чем в браузере ответ подкладывать. Это разве что для ручного тестирования хорошо.
«в реальной жизни фичи устроены немного сложнее, чем «функция X должна принять имя и вывести приветствие с этим именем» Отсюда следует два вывода:
Либо аналитика работает настолько криво, что задачу невозможно нормально декомпозировать
Либо разработчик настолько некомпетентный, что просто не умеет в тесты.
Из своей практики скажу, что один из минусов TDD это высокий порог вхождения - нужна как зрелая команда, так и личная самодисциплина в целом. Кто и раньше писал тесты "тяп-ляп", тому и тдд не поможет.
Да ничего подобного. Опять стандартный набор отговорок тех, кто не умеет или не хочет в тесты. При выборе методики TDD вы должны продумывать архитектуру. Если невозможно написать тест, значит есть изъян в архитектуре. А по поводу данных - это все спокойно решается моками в соответствии с контрактом
Ну вот зачем использовать какой-то кастомный пакет с кучей лишнего. Ну напиши, что это библиотека react-query, а не вот это вот. А потом удивляются, когда в проекте миллион зависимостей после установки одного пакета)
Вставляю 5 копеек. Всё, кроме использования селекта, это нарушение архитектуры приложения. Данные должны преобразовываться в том же слое, где они были запрошены. Это не должен быть транспортный слой - он представляет нам только запрос на бек. Это не должен быть слой рендера - это не его задача трансформировать данные. А вот использование селекта это самый правильный путь. У нас есть точка входа для вызова и тут же точка выхода данных. Контроль осуществляется в единственном месте и не размазан по приложению - коллеги скажут вам спасибо, что не приходится искать места трансформации. Для лучшего контроля можно создать хук useTodoQuery и уже в него дополнительно передавать опции самой квери, конечно же опционально. Это даёт нам переиспольщуемый хук с возможностью контроля данных в месте использования.
Подушню. Неплохо было-бы добавить обработку ошибок, возможность использования middleware и добавить ограничение не только на общий размер файлов, но и отдельно на каждый файл.
Да хоть какого вменяемого найти сложно. Проводим ТИ, приходят кандидаты с такими резюме, что залюбуешся, стек технологий на 10-15 позиций. Начинаешь спрашивать - я это не помню, а это я не использовал, а тут необходимости не было. Ну и зачем он такой, даже мидл, нужен?
Пользователь выбирает необходимую ему дату. Требуется проверить является ли выбранный день рабочим, т.е не выходной, и не приходится на праздники. За это отвечает отдельный микросервис, которым пользуются все формы.
Это не неявное преобразование, если вы работаете с нормальным моделями данных, то у вас даты должны лежать не строками, а объектом Date. С Бека приходит строка, формат строки задаётся спекой. На входные данные конечно можно закрыть глаза(нет), а вот выходные данные придется форматировать
Пользователь выбрал на форме опцию, которая предполагает обязательное заполнение дополнительных полей. В этот момент должна быть другая схема, где эти поля помечены как и обязательные
Понятно, что вы стремитесь улучшить производительность, но при этом упускаете очень много нюансов. Мы уже очень долгое время работаем с yup и вот с какими кейсами мы столкнулись:
Асинхронная валидация, да та самая, которая редко используется. Рано или поздно в больших приложениях вы с ней столкнетесь
Трансформация входящих/исходящих данных - это очень важный момент, особенно для дат. Поскольку даты передаются строкой, важно указывать правильную функцию преобразования.
Комбинированные схемы - обычно это касается исходящих данных. На сложных формах, зачастую, требуются схемы, которые должны собираться по условию. Из коробки yup такое делать корректно не умеет
Валидация одного значения в зависимости от других других
Ваши минусы лишь доказывают, что вы не знаете и не умеете использовать TS. Из-за этого у вас возникает боль в том месте, на котором обычно люди сидят. Выше был дан ответ. Но я дополню - все эти ваши JSON.parse используются, как правило, в двух случаях. 1 - распарсить ответ с бека, 2 - распарсить считанные с диска данные. И в том и в другом случае нужна валидация входных данных. Наброс на вентилятор, конечно же, засчитан.
type TArg = {
a: number;
b: number;
};
function sum(arg: TArg): number {
const { a, b } = arg
return a + b;
}
const a = {
a: 654,
b: '123'
};
// Ой, ошибочка
// Types of property 'b' are incompatible.
// Type 'string' is not assignable to type 'number'.
const result = sum(a)
Интересно почему?
P.S. Единственное чему я рад, что мы работаем в разных компаниях
После "мАзолить" и "кАпнуть" перестал читать. ТС, без негатива, но к читателям надо с б'ольшим уважением подходить
Соглашусь со спеллчекером. Остальное, как и говорил - мусор. Для чего нужны "выразительные" комментарии? Все Todo будут автоматически собраны при генерации документации + настройте сонар, так он ещё и code smelt покажет. Что за инфантильность я, честно, не понимаю) Отступы в студии прекрасно видно в виде вертикальных серых линеек и без дополнительных плагинов.
BetterComments в помойку, для этого есть JSDoc, который заодно приучает писать документацию. Code Spell Checker туда же, ставим ESLint и настраиваем любые правила. К тому-же, VSCode можно настроить так, чтобы ошибки устранялись автоматически при сохранении с помощью этого линтера. Соответственно, rainbow тоже не нужен - настраиваем правило литера для отступов - студия сама подсветит и предложить вариант замены
Дядь, не душни ;)
Есть fork. Он условно платный, но на самом деле просто иногда всплывает окно с просьбой задонатить. А в целом, полноценное приложение
Справедливости ради, разработка через msw все же на порядок быстрее и удобнее, чем в браузере ответ подкладывать. Это разве что для ручного тестирования хорошо.
«в реальной жизни фичи устроены немного сложнее, чем «функция X должна принять имя и вывести приветствие с этим именем»
Отсюда следует два вывода:
Либо аналитика работает настолько криво, что задачу невозможно нормально декомпозировать
Либо разработчик настолько некомпетентный, что просто не умеет в тесты.
Из своей практики скажу, что один из минусов TDD это высокий порог вхождения - нужна как зрелая команда, так и личная самодисциплина в целом. Кто и раньше писал тесты "тяп-ляп", тому и тдд не поможет.
Ну и для чего этот велосипед когда есть TS, message pack и protobuf?
Да ничего подобного. Опять стандартный набор отговорок тех, кто не умеет или не хочет в тесты. При выборе методики TDD вы должны продумывать архитектуру. Если невозможно написать тест, значит есть изъян в архитектуре. А по поводу данных - это все спокойно решается моками в соответствии с контрактом
Ну вот зачем использовать какой-то кастомный пакет с кучей лишнего. Ну напиши, что это библиотека react-query, а не вот это вот. А потом удивляются, когда в проекте миллион зависимостей после установки одного пакета)
Вставляю 5 копеек. Всё, кроме использования селекта, это нарушение архитектуры приложения. Данные должны преобразовываться в том же слое, где они были запрошены. Это не должен быть транспортный слой - он представляет нам только запрос на бек. Это не должен быть слой рендера - это не его задача трансформировать данные. А вот использование селекта это самый правильный путь. У нас есть точка входа для вызова и тут же точка выхода данных. Контроль осуществляется в единственном месте и не размазан по приложению - коллеги скажут вам спасибо, что не приходится искать места трансформации. Для лучшего контроля можно создать хук useTodoQuery и уже в него дополнительно передавать опции самой квери, конечно же опционально. Это даёт нам переиспольщуемый хук с возможностью контроля данных в месте использования.
Ну действительно, при использовании других стейт менеджеров в реакте же оборачивают vdom
Т.е. либа агностик, но для реакта нет реализации. Понятно. А в чем принципиальное отличие от Zustand если вам MobX не угодил?
Подушню. Неплохо было-бы добавить обработку ошибок, возможность использования middleware и добавить ограничение не только на общий размер файлов, но и отдельно на каждый файл.
Да хоть какого вменяемого найти сложно. Проводим ТИ, приходят кандидаты с такими резюме, что залюбуешся, стек технологий на 10-15 позиций. Начинаешь спрашивать - я это не помню, а это я не использовал, а тут необходимости не было. Ну и зачем он такой, даже мидл, нужен?
Пользователь выбирает необходимую ему дату. Требуется проверить является ли выбранный день рабочим, т.е не выходной, и не приходится на праздники. За это отвечает отдельный микросервис, которым пользуются все формы.
Это не неявное преобразование, если вы работаете с нормальным моделями данных, то у вас даты должны лежать не строками, а объектом Date. С Бека приходит строка, формат строки задаётся спекой. На входные данные конечно можно закрыть глаза(нет), а вот выходные данные придется форматировать
Пользователь выбрал на форме опцию, которая предполагает обязательное заполнение дополнительных полей. В этот момент должна быть другая схема, где эти поля помечены как и обязательные
Понятно, что вы стремитесь улучшить производительность, но при этом упускаете очень много нюансов. Мы уже очень долгое время работаем с yup и вот с какими кейсами мы столкнулись:
Асинхронная валидация, да та самая, которая редко используется. Рано или поздно в больших приложениях вы с ней столкнетесь
Трансформация входящих/исходящих данных - это очень важный момент, особенно для дат. Поскольку даты передаются строкой, важно указывать правильную функцию преобразования.
Комбинированные схемы - обычно это касается исходящих данных. На сложных формах, зачастую, требуются схемы, которые должны собираться по условию. Из коробки yup такое делать корректно не умеет
Валидация одного значения в зависимости от других других
Ахах, ну загляни хоть раз в жизни в документацию
https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any
JSON.parse возвращает результат с типом any, тип any отключает все проверки типов. Какое ты ожидаешь поведение ? Что будет проверка ?
Справедливости ради, ошибка будет на этапе выполнения, поскольку и питон, и жабаскрипт - скриптовые языки с их присущими недостатками.
Ваши минусы лишь доказывают, что вы не знаете и не умеете использовать TS. Из-за этого у вас возникает боль в том месте, на котором обычно люди сидят. Выше был дан ответ. Но я дополню - все эти ваши JSON.parse используются, как правило, в двух случаях. 1 - распарсить ответ с бека, 2 - распарсить считанные с диска данные. И в том и в другом случае нужна валидация входных данных. Наброс на вентилятор, конечно же, засчитан.
Интересно почему?
P.S. Единственное чему я рад, что мы работаем в разных компаниях