Справедливости ради, разработка через 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. Единственное чему я рад, что мы работаем в разных компаниях
Конечно конечно, писать каждый раз проверки внутри функции, что входная переменная является числом вместо того, чтобы сразу типизировать аргумент безусловно быстрее и полезнее для разработчика. Это так весело в чистом JS писать instanceof и typeof. А аргумент по отстрел ноги просто великолепен! А для чего по вашему существуют типы в других языках? Ровно для этого, чтобы все вызывалось с нужными параметрами и не ломалось. Никто не пишет без нужды параметр как dynamic. А если аргументом является функция вы как проверяете ее сигнатуру, если не секрет? А если ее параметром будет сложный объект? Мне на TS потребуется ровно минута, а вам ?
Да ничего он не убивает. Просто это язык не для вкатышей в IT, которым надо все и сразу, и быстро. У него есть определенный высокий порог вхождения, но потом уже этого не замечаешь. Вас послушать, тогда и С# убивает производительность да? Там тоже типы, там тоже дженерики, там тоже надо сигнатуры функций правильно описывать. Я не сравниваю TS и Шарп, но принцип один. Это вы ещё на С+ не писали. Нервы у него видите ли...
Используйте readonly по умолчанию, это позволит избежать случайного перезаписывания типов в вашем интерфейсе
Поправочка, не в интерфейсе, а в объекте заданного типа. На этапе компиляции будет проведена проверка, что вы пытаетесь присвоить значение свойству, которое указано как readonly.
И стоит добавить сюда описание что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.
Справедливости ради, разработка через 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. Единственное чему я рад, что мы работаем в разных компаниях
Конечно конечно, писать каждый раз проверки внутри функции, что входная переменная является числом вместо того, чтобы сразу типизировать аргумент безусловно быстрее и полезнее для разработчика. Это так весело в чистом JS писать instanceof и typeof. А аргумент по отстрел ноги просто великолепен! А для чего по вашему существуют типы в других языках? Ровно для этого, чтобы все вызывалось с нужными параметрами и не ломалось. Никто не пишет без нужды параметр как dynamic. А если аргументом является функция вы как проверяете ее сигнатуру, если не секрет? А если ее параметром будет сложный объект? Мне на TS потребуется ровно минута, а вам ?
Да ничего он не убивает. Просто это язык не для вкатышей в IT, которым надо все и сразу, и быстро. У него есть определенный высокий порог вхождения, но потом уже этого не замечаешь. Вас послушать, тогда и С# убивает производительность да? Там тоже типы, там тоже дженерики, там тоже надо сигнатуры функций правильно описывать. Я не сравниваю TS и Шарп, но принцип один. Это вы ещё на С+ не писали. Нервы у него видите ли...
Поправочка, не в интерфейсе, а в объекте заданного типа. На этапе компиляции будет проведена проверка, что вы пытаетесь присвоить значение свойству, которое указано как readonly.
И стоит добавить сюда описание что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.
Используйте тип напрямую в определении функции вместе с деструктуризацией
Все отлично, но зачем вы везде используете React.FC ? Признано устаревшим в т.ч. и в 18 реакте.