Как в TypeScript указать, что параметр метода должен быть определенного типа?

А, TypeScript, ёпта! Ну, смотри, тут всё просто, как три копейки. Если ты привык к JavaScript, где можно в функцию чёрта лысого передать, и она схавает, то тут придётся мозги включать. Типы параметров — это как паспортный контроль на границе: без правильной бумажки не пустят, хоть ты тресни.

Базовый синтаксис — хуй с горы: Просто пишешь, что ожидаешь, прямо в объявлении. Никакой магии.

function greetUser(name: string): void {
    console.log(`Hello, ${name}!`);
}

const logMessage = (message: string, priority: number): void => {
    console.log(`[${priority}] ${message}`);
};

Видишь? name: string. Попробуй передать туда цифру — получишь ошибку ещё на этапе написания кода, а не когда всё уже накрылось медным тазом в продакшене. Удобно, блядь.

Union Types — когда на один параметр претендуют несколько типов: Бывает же такое, что функция готова принять и строку, и число. В JavaScript ты бы внутри ifами это проверял. Тут — объявляешь союз.

function formatInput(input: string | number): string {
    return String(input).trim();
}

Вот и всё. Тип input — это string | number. Читается как "строка ИЛИ число". Элегантно, сука. Никаких костылей.

Объекты — тут уже интереснее, ебать мои старые костыли: Ты же не будешь каждый раз писать { id: number, email: string, isActive?: boolean } в параметрах? Задолбаешься. Выносишь это в интерфейс или тип.

interface User {
    id: number;
    email: string;
    isActive?: boolean; // Вопросик — значит, можешь передать, а можешь и нет. Опциональное, короче.
}

function createUser(userData: User): User {
    return db.users.create(userData);
}

// Или через type (псевдоним типа). Разница тонкая, но для начала — да похуй.
type FilterCallback = (item: any) => boolean;
function filterArray(arr: any[], callback: FilterCallback): any[] {
    return arr.filter(callback);
}

Главное — объект, который ты передашь в createUser, должен соответствовать форме User. Если email будет числом — получишь по шапке от компилятора. Подозрение ёбать чувствую, что это многих бесит сначала, но потом привыкаешь.

Дженерики (Generics) — вот где начинается настоящая магия, а не этот цирк: Это как если бы функция была умной и подстраивалась под то, что ты в неё суёшь.

function getFirstElement<T>(arr: T[]): T | undefined {
    return arr[0];
}
// Вызываешь с массивом чисел — T становится number.
const firstNum = getFirstElement([1, 2, 3]); // firstNum: number | undefined
// Вызываешь со строками — T становится string.
const firstStr = getFirstElement(['a', 'b', 'c']); // firstStr: string | undefined

Буква T — это просто условное обозначение. Можешь написать Type, Item, хоть MySuperType. Суть в том, что тип вычисляется в момент вызова. Без дженериков пришлось бы писать отдельную функцию для чисел, отдельную для строк — пиздец, а не жизнь.

В классах — тоже ок:

class ApiService {
    async fetchData<T>(url: string): Promise<T> {
        const response = await fetch(url);
        return response.json() as T; // Говорим компилятору: "Поверь мне, это будет тип T".
    }
}

// Используем:
interface Post { title: string; body: string; }
const service = new ApiService();
const post = await service.fetchData<Post>('https://api.example.com/posts/1');
// Теперь `post` типизирован как `Post`. Можно обращаться к `post.title` без всяких "а вдруг undefined?".

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