O
Привет. Приходит дата в таком формате: 2022-01-23T23:59:59-05:00 при форматировании в "MMM DD, YYYY" - ее переводит в Jun 24, 2022, а не в Jun 23 2022 как должно быть
Size: a a a
2021 September 02
O
что можно с этим сделать?
T
-05:00 ни о чем не говорит?
O
таймзона -5
KR
ну вот 23:59 23 января для таймзоны -5 это вполне себе уже 24 января для таймзоны +3, например
KR
Например, у date-fns есть отдельный пакет для работы с таймзонами https://date-fns.org/v2.23.0/docs/Time-Zones
O
Спасибо, буду смотреть
M
В нашем приложении мы получаем много данных с сервера. Эти данные записываются другими командами из других приложений.
Периодически возникают проблемы - где-то нет какого-то поля. Где-то использовали другое значение. Где-то написали число вместо строки.
Последнее вот было недавно. Из-за этого все приложение упало.
Имеет ли смысл добавить какую-то json валидацию? Если да, то как это делается (никогда с таким не работал)? Или есть какие-то другие варианты.
Тайпскрипт ничерта тут не помогает.
Периодически возникают проблемы - где-то нет какого-то поля. Где-то использовали другое значение. Где-то написали число вместо строки.
Последнее вот было недавно. Из-за этого все приложение упало.
Имеет ли смысл добавить какую-то json валидацию? Если да, то как это делается (никогда с таким не работал)? Или есть какие-то другие варианты.
Тайпскрипт ничерта тут не помогает.
KR
Абсолютно точно имеет смысл. обрабатывать некорректный инпут нужно как можно раньше
KR
Советую библиотеку zod для этого
KR
с typescript она вообще хорошо смотрится, так как на основе схемы валидации выводятся типы
M
Спасибо, посмотрю!
И как при такой валидации хендлить ситуации когда тип не совпадает?
И как при такой валидации хендлить ситуации когда тип не совпадает?
IE
Похоже, что это для этого вполне подойдут контракты
DZ
throw new MappingError(reason);
TD
еще предложу зайти со стороны контрактного тестирования https://www.npmjs.com/package/@pact-foundation/pact
IE
M
В чем отличие от json валидации?
IE
У тебя есть типизация определенная и ограничения. Паттерн матчинг есть. С помощью него можно обрабатывать различные ситуации. Я в нем не силен. Концепт знаю, но пока не дошли руки применить. Глянь видео. Если тебе покажется, что это твой кейс, то используй
DZ
У нас эта проблема решена протобуфом. При этом структуры все-равно мапятся в модели приложения, при этом мапперы покрыты тестами, где фикстуры тоже проверяются при создании. Данные с бэка валидируются, используя протобаф. Модельки приложения описаны с помощью superstruct (пойдет вообще любая либа для валидации) и гарантируют, что фикстры не разойдутся
M
что такое протобуф и суперстракт?