Sidan

Element som kanske inte finns, eller är något annat än du tror.

Användaren

Formulär: value är alltid en sträng, även i ett nummerfält.

Nätverket

fetch: ett API kan ändras, svara med fel, eller skicka något annat.

Webbläsaren

localStorage och URL:en: vem som helst kan ha skrivit något där.

Typen

const status = document.querySelector('#status');
// Element | null

status.textContent = 'Hej';
// Fel: 'status' is possibly 'null'

Kolla en gång

if (!status) {
  throw new Error('Hittade inte #status');
}
status.textContent = 'Hej'; // ok

Tagg eller id

document.querySelector('ul');
// HTMLUListElement | null

document.querySelector('#name');
// Element | null
// Är det en input? TypeScript
// kan inte veta.

instanceof kontrollerar

const name = document
  .querySelector('#name');

if (!(name instanceof HTMLInputElement)) {
  throw new Error('Saknar #name');
}
name.value; // ok

querySelector<T>()

Du lovar TypeScript vad det är. Har någon gjort om fältet till en select märker du det först när koden kraschar.

const name = document
  .querySelector<HTMLInputElement>('#name');

instanceof

Kontrollerar när koden körs, och TypeScript narrowar efter kontrollen. Ett fel blir ett tydligt felmeddelande i stället för undefined längre fram.

TypeScript vet eventtypen

form.addEventListener('submit', (event) => {
  // event: SubmitEvent
  event.preventDefault();
});

value är alltid en sträng

priceInput.value;         // '29'
priceInput.valueAsNumber; // 29

Tid

15 min

Mål

Du kan hämta element från DOM:en utan as, och TypeScript vet vilken typ varje element har.

any

const data = await response.json();
// data: any
data.produkter.map(...);
// inget fel nu, krasch sedan

unknown

const data: unknown = await response.json();
data.map(...);
// Fel: 'data' is of type 'unknown'

Hjälparen

const isRecord = (value: unknown)
  : value is Record<string, unknown> =>
  typeof value === 'object'
  && value !== null;

Guarden

const isProduct = (value: unknown)
  : value is Product =>
  isRecord(value)
  && typeof value.id === 'string'
  && typeof value.name === 'string'
  && typeof value.price === 'number'
  && isCategory(value.category);

Ett värde

if (isProduct(data)) {
  data.price; // number
}

En lista

if (!Array.isArray(data)) {
  throw new Error('Inte en lista');
}
const products = data.filter(isProduct);
// Product[]

Gränsen

const fetchJson = async (url: string)
  : Promise<unknown> => {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`Fel ${response.status}`);
  }
  return response.json();
};

const parseProducts = (data: unknown)
  : Product[] => { /* ... */ };

Användningen

try {
  const products = parseProducts(
    await fetchJson('./products.json'),
  );
  showMenu(products);
} catch (error) {
  showStatus(
    error instanceof Error
      ? error.message
      : 'Något gick fel',
  );
}

Schemat

import { z } from 'zod';

const ProductSchema = z.object({
  id: z.string(),
  name: z.string(),
  price: z.number(),
  category: z.enum(['dryck', 'bröd', 'mat']),
});

type Product = z.infer<typeof ProductSchema>;

Kontrollen

const result = z.array(ProductSchema)
  .safeParse(data);

if (result.success) {
  result.data; // Product[]
} else {
  z.prettifyError(result.error);
}

Med den trasiga filen

✖ Invalid input: expected number,
  received string
  → at [1].price
✖ Invalid input: expected string,
  received undefined
  → at [2].name
✖ Invalid option: expected one of
  "dryck"|"bröd"|"mat"
  → at [3].category

Jämför med guarden

Guarden säger bara false. Zod säger vilken post och vilket fält. Det är guld när ett API har ändrats.

Handskriven guard

Inga beroenden, och du ser exakt vad som kontrolleras. Blir lång när datan är stor, och typen och kontrollen kan glida isär.

Zod

Kort, bra felmeddelanden, och typen kommer ur schemat. Men det är ett beroende till: i code-alongen gick bundlen från 2 kB till 86 kB.

Grunden är densamma

Båda gör samma sak: tar unknown och ger typad data, vid gränsen. Förstå guarden först, så förstår du vad Zod gör åt dig.