Как отловить ситуацию, когда backend присылает данные не того типа, который ожидает приложение?

Проблема несоответствия типов

Когда backend присылает данные, не соответствующие ожидаемой структуре, это может привести к ошибкам в работе приложения, таким как падение при обращении к несуществующему свойству или некорректное отображение. Статическая типизация (например, TypeScript) помогает на этапе разработки, но не защищает от ошибок во время выполнения, так как данные приходят извне и не проверяются компилятором.

Решение: runtime-валидация

Для проверки данных на клиенте используются библиотеки валидации, такие как Zod, Yup или io-ts. Они позволяют описать схему ожидаемых данных и проверить полученный объект на соответствие этой схеме. Если данные не проходят проверку, можно выбросить ошибку или применить значения по умолчанию.

import { z } from 'zod';

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
});

const response = await fetch('/api/user');
const data = await response.json();

const result = UserSchema.safeParse(data);
if (!result.success) {
  console.error('Invalid data', result.error);
  // показать пользователю сообщение об ошибке
} else {
  const user = result.data;
  // использовать данные
}

Практическое применение

Валидация особенно важна при работе с внешними API, где нет гарантий стабильности формата. Она также помогает при разработке в команде, когда фронтенд и бэкенд развиваются независимо. Использование схем валидации делает код более надёжным и упрощает отладку, так как ошибки обнаруживаются на раннем этапе.

Вывод

Применяйте runtime-валидацию с помощью библиотек вроде Zod для защиты от некорректных данных от backend. Это особенно полезно в крупных проектах и при работе с ненадёжными API, где важно быстро обнаружить и обработать ошибки.