├── .gitignore
├── assets
    ├── code.png
    └── typescript.svg
├── .github
    ├── FUNDING.yml
    ├── CONTRIBUTING.md
    └── PULL_REQUEST_TEMPLATE.md
├── .prettierrc
├── SECURITY.md
├── LICENSE.txt
├── CODE_OF_CONDUCT.md
└── README.md


/.gitignore:
--------------------------------------------------------------------------------
1 | #Junk
2 | .DS_Store
3 | .vscode/
4 | .idea/


--------------------------------------------------------------------------------
/assets/code.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DevLoversTeam/typescript-interview-questions/HEAD/assets/code.png


--------------------------------------------------------------------------------
/.github/FUNDING.yml:
--------------------------------------------------------------------------------
1 | # FUNDING.yml
2 | # Налаштування можливостей підтримки проєкту
3 | 
4 | github: ViktorSvertoka
5 | buy_me_a_coffee: viktor.svertoka
6 | 


--------------------------------------------------------------------------------
/.prettierrc:
--------------------------------------------------------------------------------
 1 | {
 2 |   "printWidth": 80,
 3 |   "useTabs": false,
 4 |   "semi": true,
 5 |   "singleQuote": true,
 6 |   "trailingComma": "es5",
 7 |   "bracketSpacing": true,
 8 |   "arrowParens": "avoid",
 9 |   "proseWrap": "always"
10 | }
11 | 


--------------------------------------------------------------------------------
/.github/CONTRIBUTING.md:
--------------------------------------------------------------------------------
 1 | # 🧠 Як зробити внесок у DevLovers
 2 | 
 3 | Дякуємо, що хочете зробити внесок у наш проєкт! Нижче описано кілька простих правил, які допоможуть вам підготувати якісний pull request.
 4 | 
 5 | ## 🔧 Формат доповнення
 6 | 
 7 | - Кожне питання повинне бути оформлене в HTML-елементі `<details>` зі структурою:
 8 | 
 9 | ![Code](../assets/code.png)
10 | 


--------------------------------------------------------------------------------
/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
 1 | <!-- Дякуємо за ваш внесок у DevLovers 🎉 -->
 2 | 
 3 | <!-- Ці коментарі є лише підказкою — вони не будуть видимі у створеному pull request -->
 4 | 
 5 | Чекліст:
 6 | 
 7 | - [ ] Я ознайомився з [CONTRIBUTING.md](CONTRIBUTING.md) і дотримувався вказівок.
 8 | - [ ] Моє доповнення не дублює вже існуюче питання чи відповідь.
 9 | - [ ] Я додав(ла) нове запитання у відповідному форматі (див. існуючі приклади).
10 | - [ ] Я додав(ла) нове запитання **в кінець файлу** з **наступним за порядком номером**.
11 | 
12 | ---
13 | 
14 | <!-- Будь ласка, коротко опишіть, що саме ви додаєте або змінюєте, і чому це варте включення. -->
15 | 
16 | ...
17 | 


--------------------------------------------------------------------------------
/assets/typescript.svg:
--------------------------------------------------------------------------------
1 | <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 128"><path fill="#fff" d="M22.67 47h99.67v73.67H22.67z"/><path data-name="original" fill="#007acc" d="M1.5 63.91v62.5h125v-125H1.5zm100.73-5a15.56 15.56 0 017.82 4.5 20.58 20.58 0 013 4c0 .16-5.4 3.81-8.69 5.85-.12.08-.6-.44-1.13-1.23a7.09 7.09 0 00-5.87-3.53c-3.79-.26-6.23 1.73-6.21 5a4.58 4.58 0 00.54 2.34c.83 1.73 2.38 2.76 7.24 4.86 8.95 3.85 12.78 6.39 15.16 10 2.66 4 3.25 10.46 1.45 15.24-2 5.2-6.9 8.73-13.83 9.9a38.32 38.32 0 01-9.52-.1 23 23 0 01-12.72-6.63c-1.15-1.27-3.39-4.58-3.25-4.82a9.34 9.34 0 011.15-.73L82 101l3.59-2.08.75 1.11a16.78 16.78 0 004.74 4.54c4 2.1 9.46 1.81 12.16-.62a5.43 5.43 0 00.69-6.92c-1-1.39-3-2.56-8.59-5-6.45-2.78-9.23-4.5-11.77-7.24a16.48 16.48 0 01-3.43-6.25 25 25 0 01-.22-8c1.33-6.23 6-10.58 12.82-11.87a31.66 31.66 0 019.49.26zm-29.34 5.24v5.12H56.66v46.23H45.15V69.26H28.88v-5a49.19 49.19 0 01.12-5.17C29.08 59 39 59 51 59h21.83z"/></svg>


--------------------------------------------------------------------------------
/SECURITY.md:
--------------------------------------------------------------------------------
 1 | # 🔒 Security Policy
 2 | 
 3 | ## Reporting a Vulnerability
 4 | 
 5 | If you discover a security issue in any of my projects, I would greatly
 6 | appreciate your help in resolving it responsibly. Here's how you can report it:
 7 | 
 8 | 1. **Contact me:**  
 9 |    Please send an email to
10 |    **[devlovers.net@gmail.com](mailto:devlovers.net@gmail.com)** with:
11 | 
12 |    - A clear description of the issue.
13 |    - Steps to reproduce the vulnerability.
14 |    - Any relevant code or logs for better understanding.
15 | 
16 | 2. **Handling process:**
17 | 
18 |    - I will acknowledge your report within **48 hours**.
19 |    - Together, we will work on resolving the issue as quickly as possible.
20 | 
21 | 3. **Confidentiality:**  
22 |    Please keep the details of the vulnerability private until it has been
23 |    resolved.
24 | 
25 | Your cooperation helps ensure the safety and security of my work. Thank you for
26 | contributing to a safer tech environment! 🙌
27 | 


--------------------------------------------------------------------------------
/LICENSE.txt:
--------------------------------------------------------------------------------
 1 | MIT License
 2 | 
 3 | Copyright (c) 2025 DevLovers
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
21 | SOFTWARE.


--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
  1 | # Contributor Covenant Code of Conduct
  2 | 
  3 | ## Our Pledge
  4 | 
  5 | We as members, contributors, and leaders pledge to make participation in our
  6 | community a harassment-free experience for everyone, regardless of age, body
  7 | size, visible or invisible disability, ethnicity, sex characteristics, gender
  8 | identity and expression, level of experience, education, socio-economic status,
  9 | nationality, personal appearance, race, religion, or sexual identity and
 10 | orientation.
 11 | 
 12 | We pledge to act and interact in ways that contribute to an open, welcoming,
 13 | diverse, inclusive, and healthy community.
 14 | 
 15 | ## Our Standards
 16 | 
 17 | Examples of behavior that contributes to a positive environment for our
 18 | community include:
 19 | 
 20 | - Demonstrating empathy and kindness toward other people
 21 | - Being respectful of differing opinions, viewpoints, and experiences
 22 | - Giving and gracefully accepting constructive feedback
 23 | - Accepting responsibility and apologizing to those affected by our mistakes,
 24 |   and learning from the experience
 25 | - Focusing on what is best not just for us as individuals, but for the overall
 26 |   community
 27 | 
 28 | Examples of unacceptable behavior include:
 29 | 
 30 | - The use of sexualized language or imagery, and sexual attention or advances of
 31 |   any kind
 32 | - Trolling, insulting or derogatory comments, and personal or political attacks
 33 | - Public or private harassment
 34 | - Publishing others' private information, such as a physical or email address,
 35 |   without their explicit permission
 36 | - Other conduct which could reasonably be considered inappropriate in a
 37 |   professional setting
 38 | 
 39 | ## Enforcement Responsibilities
 40 | 
 41 | Community leaders are responsible for clarifying and enforcing our standards of
 42 | acceptable behavior and will take appropriate and fair corrective action in
 43 | response to any behavior that they deem inappropriate, threatening, offensive,
 44 | or harmful.
 45 | 
 46 | Community leaders have the right and responsibility to remove, edit, or reject
 47 | comments, commits, code, wiki edits, issues, and other contributions that are
 48 | not aligned to this Code of Conduct, and will communicate reasons for moderation
 49 | decisions when appropriate.
 50 | 
 51 | ## Scope
 52 | 
 53 | This Code of Conduct applies within all community spaces, and also applies when
 54 | an individual is officially representing the community in public spaces.
 55 | Examples of representing our community include using an official e-mail address,
 56 | posting via an official social media account, or acting as an appointed
 57 | representative at an online or offline event.
 58 | 
 59 | ## Enforcement
 60 | 
 61 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
 62 | reported to the community leaders responsible for enforcement at
 63 | [devlovers.net@gmail.com](mailto:devlovers.net@gmail.com). All complaints will
 64 | be reviewed and investigated promptly and fairly.
 65 | 
 66 | All community leaders are obligated to respect the privacy and security of the
 67 | reporter of any incident.
 68 | 
 69 | ## Enforcement Guidelines
 70 | 
 71 | Community leaders will follow these Community Impact Guidelines in determining
 72 | the consequences for any action they deem in violation of this Code of Conduct:
 73 | 
 74 | ### 1. Correction
 75 | 
 76 | **Community Impact**: Use of inappropriate language or other behavior deemed
 77 | unprofessional or unwelcome in the community.
 78 | 
 79 | **Consequence**: A private, written warning from community leaders, providing
 80 | clarity around the nature of the violation and an explanation of why the
 81 | behavior was inappropriate. A public apology may be requested.
 82 | 
 83 | ### 2. Warning
 84 | 
 85 | **Community Impact**: A violation through a single incident or series of
 86 | actions.
 87 | 
 88 | **Consequence**: A warning with consequences for continued behavior. No
 89 | interaction with the people involved, including unsolicited interaction with
 90 | those enforcing the Code of Conduct, for a specified period of time. This
 91 | includes avoiding interactions in community spaces as well as external channels
 92 | like social media. Violating these terms may lead to a temporary or permanent
 93 | ban.
 94 | 
 95 | ### 3. Temporary Ban
 96 | 
 97 | **Community Impact**: A serious violation of community standards, including
 98 | sustained inappropriate behavior.
 99 | 
100 | **Consequence**: A temporary ban from any sort of interaction or public
101 | communication with the community for a specified period of time. No public or
102 | private interaction with the people involved, including unsolicited interaction
103 | with those enforcing the Code of Conduct, is allowed during this period.
104 | Violating these terms may lead to a permanent ban.
105 | 
106 | ### 4. Permanent Ban
107 | 
108 | **Community Impact**: Demonstrating a pattern of violation of community
109 | standards, including sustained inappropriate behavior, harassment of an
110 | individual, or aggression toward or disparagement of classes of individuals.
111 | 
112 | **Consequence**: A permanent ban from any sort of public interaction within the
113 | community.
114 | 
115 | ## Attribution
116 | 
117 | This Code of Conduct is adapted from the [Contributor Covenant][homepage],
118 | version 2.0, available at
119 | https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
120 | 
121 | Community Impact Guidelines were inspired by
122 | [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
123 | 
124 | [homepage]: https://www.contributor-covenant.org
125 | 
126 | For answers to common questions about this code of conduct, see the FAQ at
127 | https://www.contributor-covenant.org/faq. Translations are available at
128 | https://www.contributor-covenant.org/translations.
129 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
   1 | <h1>
   2 |   TypeScript <img src="./assets/typescript.svg" width="40" height="40" />
   3 | </h1>
   4 | 
   5 | <h2>Найпопулярніші запитання та відповіді на співбесіді з TypeScript</h2>
   6 | 
   7 | ### Основи TypeScript
   8 | 
   9 | <details>
  10 | <summary>1. Поясніть, що таке TypeScript та які його ключові відмінності від JavaScript.</summary>
  11 | 
  12 | #### TypeScript
  13 | 
  14 | **TypeScript** — це надбудова над JavaScript, яка додає статичну типізацію,
  15 | інтерфейси та інші можливості для підвищення надійності коду.
  16 | 
  17 | #### Відмінності:
  18 | 
  19 | - **_Типізація:_** TS має статичні типи, JS — динамічні.
  20 | 
  21 | - **_Розробка:_** TS виявляє помилки на етапі компіляції, JS — під час
  22 |   виконання.
  23 | 
  24 | - **_Сумісність:_** TS компілюється у JS, тому працює у всіх середовищах JS.
  25 | 
  26 | - **_Інструменти:_** краща підтримка IDE (автодоповнення, рефакторинг).
  27 | 
  28 | </details>
  29 | 
  30 | <details>
  31 | <summary>2. Що означає твердження, що TypeScript є надмножиною JavaScript?</summary>
  32 | 
  33 | #### TypeScript
  34 | 
  35 | - Це означає, що будь-який коректний JavaScript-код є також коректним
  36 |   TypeScript-кодом. TypeScript розширює можливості JS, додаючи типи та інші
  37 |   фічі, але при цьому не змінює базову мову.
  38 | 
  39 | </details>
  40 | 
  41 | <details>
  42 | <summary>3. Які основні вбудовані типи даних підтримує TypeScript?</summary>
  43 | 
  44 | #### TypeScript
  45 | 
  46 | **Основні типи в TypeScript:**
  47 | 
  48 | - `string` — рядки
  49 | 
  50 | - `number` — числа (цілі та з плаваючою крапкою)
  51 | 
  52 | - `boolean` — логічні значення
  53 | 
  54 | - `null` та `undefined`
  55 | 
  56 | - `any` — будь-який тип
  57 | 
  58 | - `unknown` — невідомий тип (безпечніша альтернатива any)
  59 | 
  60 | - `void` — відсутність значення (часто у функціях)
  61 | 
  62 | - `never` — функція ніколи не повертає значення (наприклад, кидає помилку)
  63 | 
  64 | - `object` — об’єкти
  65 | 
  66 | - `Масиви` (type[] або Array<type>)
  67 | 
  68 | - `Кортежі` ([type1, type2, ...])
  69 | 
  70 | - `enum` — перерахування
  71 | 
  72 | </details>
  73 | 
  74 | <details>
  75 | <summary>4. Які способи оголошення змінних у TypeScript та як до них застосовується типізація?</summary>
  76 | 
  77 | #### TypeScript
  78 | 
  79 | У TypeScript змінні оголошуються так само, як у JavaScript: `let`, `const`,
  80 | рідше `var`.
  81 | 
  82 | **Тип можна:**
  83 | 
  84 | - вивести автоматично (Type Inference):
  85 | 
  86 | ```TypeScript
  87 | let age = 25; // type: number
  88 | ```
  89 | 
  90 | - задати явно:
  91 | 
  92 | ```TypeScript
  93 | let age: number = 25;
  94 | const name: string = "Alice";
  95 | ```
  96 | 
  97 | Зазвичай рекомендують використовувати `const` для незмінних значень, `let` для
  98 | змінних, а явну типізацію — там, де виведення типу неочевидне.
  99 | 
 100 | </details>
 101 | 
 102 | <details>
 103 | <summary>5. Що таке інтерфейси в TypeScript і для чого вони використовуються?</summary>
 104 | 
 105 | #### TypeScript
 106 | 
 107 | Інтерфейси в TypeScript описують структуру об’єкта (його властивості та їх
 108 | типи), не створюючи конкретної реалізації. Вони допомагають забезпечити контракт
 109 | між частинами коду.
 110 | 
 111 | **Основні можливості:**
 112 | 
 113 | - Опис форми об’єкта:
 114 | 
 115 | ```TypeScript
 116 | interface User {
 117 |   id: number;
 118 |   name: string;
 119 |   isAdmin?: boolean; // необов’язкове поле
 120 | }
 121 | 
 122 | const user: User = { id: 1, name: "Alice" };
 123 | ```
 124 | 
 125 | - Підтримка опціональних властивостей (?).
 126 | 
 127 | - Можливість розширення (extends).
 128 | 
 129 | - Використання для опису структур функцій, класів та масивів.
 130 | 
 131 | По суті, інтерфейси — це спосіб зробити код більш передбачуваним і безпечним.
 132 | 
 133 | </details>
 134 | 
 135 | <details>
 136 | <summary>6. Що таке enum у TypeScript та в яких випадках його доцільно використовувати?</summary>
 137 | 
 138 | #### TypeScript
 139 | 
 140 | - `enum` (перерахування) — це тип, який дозволяє задати набір іменованих
 141 |   констант.
 142 | 
 143 | #### Види:
 144 | 
 145 | - **Numeric enum** (значення автоматично інкрементуються):
 146 | 
 147 | ```TypeScript
 148 | enum Direction {
 149 |   Up,    // 0
 150 |   Down,  // 1
 151 |   Left,  // 2
 152 |   Right  // 3
 153 | }
 154 | ```
 155 | 
 156 | - **String enum:**
 157 | 
 158 | ```TypeScript
 159 | enum Role {
 160 |   Admin = "ADMIN",
 161 |   User = "USER",
 162 |   Guest = "GUEST"
 163 | }
 164 | ```
 165 | 
 166 | Використовується, коли є обмежений набір варіантів (напр. ролі користувачів,
 167 | статуси замовлення, напрямки руху). Це робить код більш читабельним і безпечним,
 168 | ніж "магічні числа" чи рядки.
 169 | 
 170 | </details>
 171 | 
 172 | <details>
 173 | <summary>7. Як правильно оголошувати та використовувати функції в TypeScript із врахуванням типів?</summary>
 174 | 
 175 | #### TypeScript
 176 | 
 177 | - Функції визначаються так само, як у JavaScript, але в TypeScript можна явно
 178 |   задавати типи параметрів і результату:
 179 | 
 180 | ```TypeScript
 181 | // З явними типами
 182 | function add(a: number, b: number): number {
 183 |   return a + b;
 184 | }
 185 | 
 186 | // Функціональний вираз
 187 | const greet = (name: string): string => {
 188 |   return `Hello, ${name}`;
 189 | };
 190 | 
 191 | // Необов’язковий параметр
 192 | function log(message: string, userId?: number): void {
 193 |   console.log(message, userId);
 194 | }
 195 | ```
 196 | 
 197 | - Параметри можна робити обов’язковими, необов’язковими (?) або мати значення за
 198 |   замовчуванням.
 199 | 
 200 | - Тип повернення можна вивести автоматично, але для складних функцій краще
 201 |   вказувати явно.
 202 | 
 203 | - Для callback-ів та складних сигнатур використовують типи або інтерфейси
 204 |   функцій.
 205 | 
 206 | </details>
 207 | 
 208 | <details>
 209 | <summary>8. Що таке виведення типу (type inference) у TypeScript і як воно працює?</summary>
 210 | 
 211 | #### TypeScript
 212 | 
 213 | - Виведення типу — це механізм, коли TypeScript автоматично визначає тип змінної
 214 |   чи результату функції на основі наданого значення без явного оголошення.
 215 | 
 216 | #### Приклади:
 217 | 
 218 | ```TypeScript
 219 | let count = 10;    // TS виводить: number
 220 | let message = "Hi"; // TS виводить: string
 221 | 
 222 | function add(a: number, b: number) {
 223 |   return a + b; // TS виводить: number (тип повернення)
 224 | }
 225 | ```
 226 | 
 227 | - Перевага: менше коду, але збережена типобезпека.
 228 | 
 229 | - Ризик: у складних випадках краще явно вказувати тип, щоб уникнути
 230 |   неочікуваного any.
 231 | 
 232 | </details>
 233 | 
 234 | <details>
 235 | <summary>9. У чому різниця між let і const у TypeScript і як правильно їх використовувати?</summary>
 236 | 
 237 | #### TypeScript
 238 | 
 239 | `let` — дозволяє оголосити змінну, значення якої можна змінювати. Має блочну
 240 | область видимості.
 241 | 
 242 | `const` — створює змінну, якій можна призначити значення лише один раз. Також
 243 | має блочну область видимості.
 244 | 
 245 | #### Приклад:
 246 | 
 247 | ```TypeScript
 248 | let counter: number = 1;
 249 | counter = 2; // ✅ можна
 250 | 
 251 | const name: string = "Alice";
 252 | name = "Bob"; // ❌ помилка
 253 | ```
 254 | 
 255 | Рекомендація: за замовчуванням використовувати `const`, а `let` — лише коли
 256 | змінна дійсно змінюється.
 257 | 
 258 | Важливо: `const` не робить об’єкт immutable, змінювати внутрішні властивості все
 259 | одно можна:
 260 | 
 261 | ```TypeScript
 262 | const user = { id: 1, name: "Alice" };
 263 | user.name = "Bob"; // ✅ дозволено
 264 | ```
 265 | 
 266 | </details>
 267 | 
 268 | <details>
 269 | <summary>10. Яким чином можна скомпілювати TypeScript-файли у JavaScript?</summary>
 270 | 
 271 | #### TypeScript
 272 | 
 273 | - Використовується TypeScript Compiler (tsc).
 274 | 
 275 | - Основні варіанти:
 276 | 
 277 | ```bash
 278 | # компіляція одного файлу
 279 | 
 280 | tsc file.ts
 281 | 
 282 | # компіляція проєкту з налаштуваннями tsconfig.json
 283 | 
 284 | tsc
 285 | ```
 286 | 
 287 | - У tsconfig.json можна задати цільову версію JS (target), директорію виводу
 288 |   (outDir), модулі (module) тощо.
 289 | 
 290 | - Також можна включити watch mode:
 291 | 
 292 | ```bash
 293 | tsc -w
 294 | ```
 295 | 
 296 | У реальних проєктах часто використовують Babel, Webpack, Vite чи ts-node для
 297 | інтеграції компіляції у збірку чи запуск коду напряму.
 298 | 
 299 | </details>
 300 | 
 301 | ### Класи та об'єкти в TypeScript
 302 | 
 303 | <details>
 304 | <summary>11. Що таке класи в TypeScript і чим вони відрізняються від класів у звичайному JavaScript?</summary>
 305 | 
 306 | #### TypeScript
 307 | 
 308 | Класи в TypeScript — це надбудова над JS-класами. Вони працюють так само, як у
 309 | JS, але доповнені системою типів:
 310 | 
 311 | - можна оголошувати типи для полів, параметрів і повертаних значень;
 312 | 
 313 | - є модифікатори доступу (public, private, protected, readonly);
 314 | 
 315 | - є abstract класи та методи;
 316 | 
 317 | - підтримка implements для інтерфейсів;
 318 | 
 319 | - підтримка generics.
 320 | 
 321 | У рантаймі вони компілюються в звичайні JS-класи, а типи прибираються.
 322 | 
 323 | </details>
 324 | 
 325 | <details>
 326 | <summary>12. Як правильно реалізувати спадкування класів у TypeScript?</summary>
 327 | 
 328 | #### TypeScript
 329 | 
 330 | Використовується ключове слово `extends`. Базовий клас може мати загальні
 331 | властивості/методи, похідний — успадковує їх і може перевизначати. При
 332 | перевизначенні конструктора обов’язково викликається `super()`.
 333 | 
 334 | ```TypeScript
 335 | class Animal {
 336 |   constructor(public name: string) {}
 337 |   speak(): void {
 338 |     console.log(`${this.name} makes a sound.`);
 339 |   }
 340 | }
 341 | 
 342 | class Dog extends Animal {
 343 |   constructor(name: string, public breed: string) {
 344 |     super(name);
 345 |   }
 346 |   speak(): void {
 347 |     console.log(`${this.name} barks.`);
 348 |   }
 349 | }
 350 | 
 351 | const rex = new Dog("Rex", "Labrador");
 352 | rex.speak(); // Rex barks.
 353 | ```
 354 | 
 355 | </details>
 356 | 
 357 | <details>
 358 | <summary>13. Які є модифікатори доступу в TypeScript і як вони впливають на властивості та методи класів?</summary>
 359 | 
 360 | #### TypeScript
 361 | 
 362 | TypeScript має 4 модифікатори доступу:
 363 | 
 364 | - `public` (за замовчуванням) – доступний скрізь.
 365 | 
 366 | - `private` – доступний тільки всередині цього класу.
 367 | 
 368 | - `protected` – доступний у класі та його нащадках.
 369 | 
 370 | - `readonly` – властивість доступна тільки для читання після ініціалізації.
 371 | 
 372 | Вони впливають лише на етапі компіляції (для контролю типів), у рантаймі
 373 | JavaScript цього обмеження немає.
 374 | 
 375 | </details>
 376 | 
 377 | <details>
 378 | <summary>14. Що таке абстрактні класи в TypeScript і для чого їх використовують?</summary>
 379 | 
 380 | #### TypeScript
 381 | 
 382 | Абстрактний клас — це клас, який не можна інстанціювати напряму. Він може
 383 | містити:
 384 | 
 385 | - реалізовані методи, які спільні для всіх нащадків,
 386 | 
 387 | - abstract методи без реалізації, які зобов’язані реалізувати похідні класи.
 388 | 
 389 | Призначення: задавати загальний контракт і базову поведінку для групи класів,
 390 | залишаючи конкретну реалізацію нащадкам.
 391 | 
 392 | ```TypeScript
 393 | abstract class Shape {
 394 |   constructor(public color: string) {}
 395 |   abstract area(): number; // має реалізувати підклас
 396 |   describe(): void {
 397 |     console.log(`This shape is ${this.color}`);
 398 |   }
 399 | }
 400 | 
 401 | class Circle extends Shape {
 402 |   constructor(color: string, public radius: number) {
 403 |     super(color);
 404 |   }
 405 |   area(): number {
 406 |     return Math.PI * this.radius ** 2;
 407 |   }
 408 | }
 409 | 
 410 | const c = new Circle("red", 5);
 411 | c.describe(); // This shape is red
 412 | console.log(c.area()); // 78.5398...
 413 | ```
 414 | 
 415 | </details>
 416 | 
 417 | <details>
 418 | <summary>15. Як працюють конструктори в класах TypeScript і які особливості їх використання?</summary>
 419 | 
 420 | #### TypeScript
 421 | 
 422 | Конструктор (constructor) — це метод для ініціалізації об’єкта класу.
 423 | Особливості у TypeScript:
 424 | 
 425 | - можна задавати типи параметрів;
 426 | 
 427 | - можна використовувати модифікатори доступу прямо в параметрах (`public`,
 428 |   `private`, `protected`, `readonly`) — тоді TypeScript автоматично створює
 429 |   відповідні поля;
 430 | 
 431 | - у похідних класах обов’язково викликається `super()` перед використанням
 432 |   `this`.
 433 | 
 434 | #### Приклад:
 435 | 
 436 | ```TypeScript
 437 | class Person {
 438 |   constructor(public name: string, private age: number) {}
 439 |   greet() {
 440 |     console.log(`Hi, my name is ${this.name}`);
 441 |   }
 442 | }
 443 | 
 444 | class Employee extends Person {
 445 |   constructor(name: string, age: number, public position: string) {
 446 |     super(name, age);
 447 |   }
 448 | }
 449 | 
 450 | const emp = new Employee("Alice", 30, "Developer");
 451 | emp.greet(); // Hi, my name is Alice
 452 | console.log(emp.position); // Developer
 453 | ```
 454 | 
 455 | </details>
 456 | 
 457 | <details>
 458 | <summary>16. Що таке декоратори в TypeScript для властивостей класу і як їх застосовувати?</summary>
 459 | 
 460 | #### TypeScript
 461 | 
 462 | Декоратори — це функції, які дозволяють змінювати або розширювати поведінку
 463 | класів, методів, властивостей або параметрів. Декоратор властивості отримує ціль
 464 | (target) та ім’я властивості (property key).
 465 | 
 466 | **Приклад використання властивості:**
 467 | 
 468 | ```TypeScript
 469 | function logProperty(target: any, key: string) {
 470 |   let value = target[key];
 471 | 
 472 |   const getter = () => {
 473 |     console.log(`Getting ${key}: ${value}`);
 474 |     return value;
 475 |   };
 476 | 
 477 |   const setter = (newVal: any) => {
 478 |     console.log(`Setting ${key} to ${newVal}`);
 479 |     value = newVal;
 480 |   };
 481 | 
 482 |   Object.defineProperty(target, key, {
 483 |     get: getter,
 484 |     set: setter,
 485 |     enumerable: true,
 486 |     configurable: true
 487 |   });
 488 | }
 489 | 
 490 | class Person {
 491 |   @logProperty
 492 |   name: string = "";
 493 | }
 494 | 
 495 | const p = new Person();
 496 | p.name = "Alice"; // Setting name to Alice
 497 | console.log(p.name); // Getting name: Alice
 498 | ```
 499 | 
 500 | Декоратори часто використовують для логування, валідації, DI (dependency
 501 | injection) та метаданих.
 502 | 
 503 | </details>
 504 | 
 505 | <details>
 506 | <summary>17. Як реалізуються та працюють геттери (get) і сеттери (set) у TypeScript?</summary>
 507 | 
 508 | #### TypeScript
 509 | 
 510 | Геттери та сеттери дозволяють контролювати доступ до властивостей класу.
 511 | 
 512 | - `get` — повертає значення властивості, дозволяє виконувати додаткову логіку
 513 |   при читанні.
 514 | 
 515 | - `set` — задає значення властивості, дозволяє перевіряти або модифікувати його
 516 |   перед присвоєнням.
 517 | 
 518 | #### Приклад:
 519 | 
 520 | ```TypeScript
 521 | class Person {
 522 |   private _age: number = 0;
 523 | 
 524 |   get age(): number {
 525 |     return this._age;
 526 |   }
 527 | 
 528 |   set age(value: number) {
 529 |     if (value < 0) throw new Error("Age cannot be negative");
 530 |     this._age = value;
 531 |   }
 532 | }
 533 | 
 534 | const p = new Person();
 535 | p.age = 25;          // викликається set
 536 | console.log(p.age);  // викликається get -> 25
 537 | ```
 538 | 
 539 | Геттери і сеттери працюють як звичайні властивості при доступі, але дозволяють
 540 | інкапсулювати логіку.
 541 | 
 542 | </details>
 543 | 
 544 | <details>
 545 | <summary>18. Як реалізується перевантаження методів у TypeScript?</summary>
 546 | 
 547 | #### TypeScript
 548 | 
 549 | TypeScript дозволяє перевантажувати методи через сигнатури, але тільки одна
 550 | реалізація. Це означає: можна оголосити кілька варіантів виклику методу з
 551 | різними параметрами, а в тілі методу реалізувати логіку з перевіркою
 552 | типів/кількості аргументів.
 553 | 
 554 | #### Приклад:
 555 | 
 556 | ```TypeScript
 557 | class Calculator {
 558 |   add(a: number, b: number): number;
 559 |   add(a: string, b: string): string;
 560 |   add(a: any, b: any): any { // реальна реалізація
 561 |     return a + b;
 562 |   }
 563 | }
 564 | 
 565 | const calc = new Calculator();
 566 | console.log(calc.add(2, 3));       // 5
 567 | console.log(calc.add("Hello, ", "TS")); // Hello, TS
 568 | ```
 569 | 
 570 | #### Особливості:
 571 | 
 572 | - Сигнатури визначають дозволені варіанти виклику.
 573 | 
 574 | - Реалізація повинна враховувати всі варіанти.
 575 | 
 576 | - У рантаймі перевантаження як у C#/Java не існує, це чисто типізаційний
 577 |   механізм.
 578 | 
 579 | </details>
 580 | 
 581 | <details>
 582 | <summary>19. Для чого використовується ключове слово static у класах TypeScript?</summary>
 583 | 
 584 | #### TypeScript
 585 | 
 586 | `static` дозволяє створювати члени класу (властивості або методи), які належать
 587 | самому класу, а не його екземплярам.
 588 | 
 589 | - До них звертаються через ім’я класу (ClassName.member), а не через об’єкт.
 590 | 
 591 | - Можна використовувати для констант, утилітарних методів та лічильників.
 592 | 
 593 | #### Приклад:
 594 | 
 595 | ```TypeScript
 596 | class Counter {
 597 |   static count = 0;
 598 | 
 599 |   static increment() {
 600 |     Counter.count++;
 601 |   }
 602 | }
 603 | 
 604 | Counter.increment();
 605 | console.log(Counter.count); // 1
 606 | 
 607 | const c = new Counter();
 608 | // c.increment(); // ❌ помилка, increment — static
 609 | ```
 610 | 
 611 | </details>
 612 | 
 613 | ### Типи та приведення типів у TypeScript
 614 | 
 615 | <details>
 616 | <summary>20. Як створити власний тип у TypeScript за допомогою псевдоніму (type alias)?</summary>
 617 | 
 618 | #### TypeScript
 619 | 
 620 | Псевдонім типу (`type`) дозволяє створити нове ім’я для будь-якого типу, включно
 621 | з об’єднаннями (`union`), перетинами (`intersection`) та функціями. Це зручно
 622 | для складних типів, повторного використання і документації коду.
 623 | 
 624 | ```TypeScript
 625 | type ID = string | number;
 626 | type User = {
 627 |   id: ID;
 628 |   name: string;
 629 |   age?: number; // необов’язкове поле
 630 | };
 631 | 
 632 | type Callback = (result: string) => void;
 633 | ```
 634 | 
 635 | Використовуємо як звичайний тип:
 636 | 
 637 | ```TypeScript
 638 | const user: User = { id: 1, name: "Alice" };
 639 | ```
 640 | 
 641 | Псевдоніми не створюють нових типів у рантаймі — це чисто типізація на етапі
 642 | компіляції.
 643 | 
 644 | </details>
 645 | 
 646 | <details>
 647 | <summary>21. Що таке union-типи в TypeScript і як їх застосовувати?</summary>
 648 | 
 649 | #### TypeScript
 650 | 
 651 | Union-тип (|) дозволяє змінній або параметру приймати декілька можливих типів.
 652 | Це зручно, коли значення може бути різного виду.
 653 | 
 654 | #### Приклад:
 655 | 
 656 | ```TypeScript
 657 | type ID = string | number;
 658 | 
 659 | function printId(id: ID) {
 660 |   if (typeof id === "string") {
 661 |     console.log("ID (string): " + id.toUpperCase());
 662 |   } else {
 663 |     console.log("ID (number): " + (id * 10));
 664 |   }
 665 | }
 666 | 
 667 | printId("abc"); // ID (string): ABC
 668 | printId(123); // ID (number): 1230
 669 | ```
 670 | 
 671 | #### Особливості:
 672 | 
 673 | - Потрібно робити type narrowing (перевірку типу) перед використанням
 674 |   специфічних методів.
 675 | 
 676 | - Можна комбінувати кілька типів, навіть `null | undefined`.
 677 | 
 678 | </details>
 679 | 
 680 | <details>
 681 | <summary>22. Що таке intersection-типи в TypeScript і як вони працюють?</summary>
 682 | 
 683 | #### TypeScript
 684 | 
 685 | Intersection-тип (&) поєднує кілька типів в один. Об’єкт повинен відповідати
 686 | всім об’єднаним типам одночасно. Це зручно для створення складних структур з
 687 | кількох контрактів.
 688 | 
 689 | #### Приклад:
 690 | 
 691 | ```TypeScript
 692 | type Person = { name: string };
 693 | type Employee = { company: string };
 694 | type Developer = Person & Employee & { skills: string[] };
 695 | 
 696 | const dev: Developer = {
 697 |   name: "Alice",
 698 |   company: "TechCorp",
 699 |   skills: ["TypeScript", "React"]
 700 | };
 701 | ```
 702 | 
 703 | #### Особливості:
 704 | 
 705 | - Якщо є конфліктні властивості з різними типами → результат може стати never.
 706 | 
 707 | - Добре поєднується з interface і type для композиції.
 708 | 
 709 | </details>
 710 | 
 711 | <details>
 712 | <summary>23. Що таке кортежі (Tuple types) у TypeScript і в яких випадках їх варто застосовувати?</summary>
 713 | 
 714 | #### TypeScript
 715 | 
 716 | Tuple — це масив із фіксованою кількістю елементів та визначеними типами для
 717 | кожної позиції. Використовуються, коли порядок і типи елементів наперед відомі.
 718 | 
 719 | #### Приклад:
 720 | 
 721 | ```TypeScript
 722 | let user: [number, string, boolean];
 723 | user = [1, "Alice", true]; // ✅ правильний порядок і типи
 724 | user = ["Alice", 1, true]; // ❌ помилка
 725 | ```
 726 | 
 727 | #### Особливості:
 728 | 
 729 | - Можна додати назви для кращої читабельності:
 730 | 
 731 | ```TypeScript
 732 | type HttpResponse = [statusCode: number, message: string];
 733 | const res: HttpResponse = [200, "OK"];
 734 | ```
 735 | 
 736 | - Підтримують optional та rest елементи:
 737 | 
 738 | ```TypeScript
 739 | type RGB = [number, number, number?, number?]; // (R, G, B, A?)
 740 | ```
 741 | 
 742 | Використовувати, коли треба передавати структуровані дані з фіксованим форматом
 743 | (наприклад, координати, записи логів, HTTP-відповідь).
 744 | 
 745 | </details>
 746 | 
 747 | <details>
 748 | <summary>24. Що таке твердження типів (type assertions) у TypeScript і для чого вони потрібні?</summary>
 749 | 
 750 | #### TypeScript
 751 | 
 752 | Type assertion — це спосіб сказати компілятору: «повір мені, я знаю реальний тип
 753 | цього значення». Це не змінює рантайм-поведінку, лише впливає на перевірку
 754 | типів.
 755 | 
 756 | #### Синтаксис:
 757 | 
 758 | ```TypeScript
 759 | let value: unknown = "Hello TS";
 760 | 
 761 | // спосіб 1
 762 | let strLength: number = (value as string).length;
 763 | 
 764 | // спосіб 2 (JSX несумісний, тому рідше)
 765 | let strLength2: number = (<string>value).length;
 766 | ```
 767 | 
 768 | #### Навіщо це корисно:
 769 | 
 770 | - коли TypeScript не може вивести точний тип;
 771 | 
 772 | - при роботі з any або unknown;
 773 | 
 774 | - при доступі до DOM-елементів:
 775 | 
 776 | ```TypeScript
 777 | const input = document.getElementById("username") as HTMLInputElement;
 778 | console.log(input.value);
 779 | ```
 780 | 
 781 | ⚠️ Важливо: це не "перетворення типів", а підказка компілятору. Якщо ви
 782 | помилитеся, помилка проявиться вже у рантаймі.
 783 | 
 784 | </details>
 785 | 
 786 | <details>
 787 | <summary>25. Як працює перевірка типів за допомогою typeof у TypeScript і як її використовувати для type narrowing</summary>
 788 | 
 789 | #### TypeScript
 790 | 
 791 | `typeof` у TypeScript використовується для звуження union-типів під час
 792 | виконання. Це type guard, який дозволяє компілятору зрозуміти, який тип у
 793 | змінної в конкретній гілці коду.
 794 | 
 795 | #### Приклад:
 796 | 
 797 | ```TypeScript
 798 | function printId(id: string | number) {
 799 |   if (typeof id === "string") {
 800 |     console.log("Uppercase ID:", id.toUpperCase()); // тут id: string
 801 |   } else {
 802 |     console.log("Numeric ID:", id.toFixed(2)); // тут id: number
 803 |   }
 804 | }
 805 | ```
 806 | 
 807 | #### Особливості:
 808 | 
 809 | - `typeof` перевіряє типи рантайму: `string`, `number`, `boolean`, `object`,
 810 |   `function`, `undefined`, `symbol`, `bigint`.
 811 | 
 812 | - Використовується у функціях для безпечної роботи з union-типами.
 813 | 
 814 | Також typeof можна використовувати для отримання типу змінної чи функції при
 815 | оголошенні:
 816 | 
 817 | ```TypeScript
 818 | let person = { name: "Alice", age: 30 };
 819 | type Person = typeof person; // { name: string; age: number }
 820 | ```
 821 | 
 822 | </details>
 823 | 
 824 | <details>
 825 | <summary>26. Чи можна в TypeScript створювати типи на основі існуючих даних (значень) за допомогою виведення типів?</summary>
 826 | 
 827 | #### TypeScript
 828 | 
 829 | Так, можна. TypeScript дозволяє виводити типи з існуючих значень за допомогою
 830 | typeof і keyof.
 831 | 
 832 | #### Приклади:
 833 | 
 834 | 1. **Отримання типу з об’єкта**
 835 | 
 836 | ```TypeScript
 837 | const user = {
 838 |   id: 1,
 839 |   name: "Alice",
 840 |   isAdmin: true
 841 | };
 842 | 
 843 | type User = typeof user;
 844 | // User = { id: number; name: string; isAdmin: boolean }
 845 | ```
 846 | 
 847 | 2. **Отримання типів ключів**
 848 | 
 849 | ```TypeScript
 850 | type UserKeys = keyof typeof user;
 851 | // "id" | "name" | "isAdmin"
 852 | ```
 853 | 
 854 | 3. **Комбінація з літеральними типами**
 855 | 
 856 | ```TypeScript
 857 | const roles = ["admin", "user", "guest"] as const;
 858 | type Role = typeof roles[number];
 859 | // "admin" | "user" | "guest"
 860 | ```
 861 | 
 862 | Це дозволяє уникати дублювання коду й гарантує синхронізацію типів з даними.
 863 | 
 864 | </details>
 865 | 
 866 | ### Узагальнені типи (Generics) у TypeScript
 867 | 
 868 | <details>
 869 | <summary>27. Що таке узагальнені типи (Generics) у TypeScript і для чого вони потрібні?</summary>
 870 | 
 871 | #### TypeScript
 872 | 
 873 | **Generics** — це параметризовані типи, які дозволяють писати універсальний і
 874 | багаторазовий код, зберігаючи типобезпеку. Вони дозволяють відкладати визначення
 875 | конкретного типу до моменту використання.
 876 | 
 877 | #### Приклад: функція без generics
 878 | 
 879 | ```TypeScript
 880 | function identity(value: any): any {
 881 |   return value;
 882 | }
 883 | ```
 884 | 
 885 | - Проблема: втрачається тип.
 886 | 
 887 | #### Приклад з generics
 888 | 
 889 | ```TypeScript
 890 | function identity<T>(value: T): T {
 891 |   return value;
 892 | }
 893 | 
 894 | let num = identity<number>(42); // num: number
 895 | let str = identity("Hello"); // str: string (TS вивів тип автоматично)
 896 | ```
 897 | 
 898 | #### Generics у класах і інтерфейсах
 899 | 
 900 | ```TypeScript
 901 | class Box<T> { constructor(public content: T) {}
 902 | }
 903 | 
 904 | const stringBox = new Box("TS"); // Box<string>
 905 | const numberBox = new Box(123); // Box<number>
 906 | ```
 907 | 
 908 | #### Навіщо:
 909 | 
 910 | - Писати гнучкий і типобезпечний код (колекції, утиліти, API).
 911 | 
 912 | - Уникати any і втрати інформації про тип.
 913 | 
 914 | - Дозволяє зв’язати вхідний і вихідний типи.
 915 | 
 916 | </details>
 917 | 
 918 | <details>
 919 | <summary>28. Як правильно створити узагальнену (generic) функцію в TypeScript?</summary>
 920 | 
 921 | #### TypeScript
 922 | 
 923 | Узагальнена функція визначається через параметр типу в кутових дужках `<T>`. Це
 924 | дозволяє зберегти типобезпеку і не втрачати інформацію про тип.
 925 | 
 926 | #### Базовий приклад
 927 | 
 928 | ```TypeScript
 929 | function identity<T>(value: T): T {
 930 |   return value;
 931 | }
 932 | 
 933 | let n = identity<number>(10); // n: number
 934 | let s = identity("TS");       // s: string (тип виведено автоматично)
 935 | ```
 936 | 
 937 | #### З кількома параметрами типів
 938 | 
 939 | ```TypeScript
 940 | function pair<T, U>(first: T, second: U): [T, U] {
 941 |   return [first, second];
 942 | }
 943 | 
 944 | const result = pair("id", 123); // [string, number]
 945 | ```
 946 | 
 947 | #### З обмеженням типу (extends)
 948 | 
 949 | ```TypeScript
 950 | function getLength<T extends { length: number }>(item: T): number {
 951 |   return item.length;
 952 | }
 953 | 
 954 | getLength("Hello");       // 5
 955 | getLength([1, 2, 3]);     // 3
 956 | getLength(42);            // ❌ помилка, бо number не має length
 957 | ```
 958 | 
 959 | Таким чином, generics роблять функції універсальними, але строго типізованими.
 960 | 
 961 | </details>
 962 | 
 963 | <details>
 964 | <summary>29. Як визначити узагальнені (generic) інтерфейси у TypeScript і для чого вони використовуються?</summary>
 965 | 
 966 | #### TypeScript
 967 | 
 968 | Узагальнені інтерфейси дозволяють описати контракт, який працює з різними
 969 | типами, зберігаючи типобезпеку. Для цього в інтерфейс додають параметри типів
 970 | `<T>` (або кілька).
 971 | 
 972 | #### Приклад: базовий generic-інтерфейс
 973 | 
 974 | ```TypeScript
 975 | interface Box<T> {
 976 |   value: T;
 977 | }
 978 | 
 979 | const numBox: Box<number> = { value: 42 };
 980 | const strBox: Box<string> = { value: "Hello" };
 981 | ```
 982 | 
 983 | #### З кількома параметрами
 984 | 
 985 | ```TypeScript
 986 | interface Pair<K, V> {
 987 |   key: K;
 988 |   value: V;
 989 | }
 990 | 
 991 | const pair: Pair<string, number> = { key: "age", value: 30 };
 992 | ```
 993 | 
 994 | #### Узагальнені інтерфейси з функціями
 995 | 
 996 | ```TypeScript
 997 | interface Repository<T> {
 998 |   getAll(): T[];
 999 |   getById(id: number): T | null;
1000 | }
1001 | 
1002 | class UserRepo implements Repository<{ id: number; name: string }> {
1003 |   private users = [{ id: 1, name: "Alice" }];
1004 |   getAll() { return this.users; }
1005 |   getById(id: number) { return this.users.find(u => u.id === id) ?? null; }
1006 | }
1007 | ```
1008 | 
1009 | #### Навіщо:
1010 | 
1011 | - дозволяють будувати універсальні API (репозиторії, сервіси, колекції);
1012 | 
1013 | - зберігають зв’язок між типами в методах/властивостях;
1014 | 
1015 | - уникання дублювання коду для різних сутностей.
1016 | 
1017 | </details>
1018 | 
1019 | <details>
1020 | <summary>30. Як працюють узагальнені (generic) типи у класах TypeScript і як їх застосовувати?</summary>
1021 | 
1022 | #### TypeScript
1023 | 
1024 | У TypeScript можна робити класи параметризованими типами, додаючи параметр `<T>`
1025 | після імені класу. Це дозволяє створювати універсальні класи, які працюють з
1026 | різними типами даних, зберігаючи типобезпеку.
1027 | 
1028 | #### Приклад базового generic-класу
1029 | 
1030 | ```TypeScript
1031 | class Box<T> {
1032 |   constructor(public content: T) {}
1033 |   getContent(): T {
1034 |     return this.content;
1035 |   }
1036 | }
1037 | 
1038 | const numberBox = new Box<number>(123);
1039 | const stringBox = new Box<string>("Hello");
1040 | 
1041 | console.log(numberBox.getContent()); // 123
1042 | console.log(stringBox.getContent()); // Hello
1043 | ```
1044 | 
1045 | #### Клас з кількома параметрами типів
1046 | 
1047 | ```TypeScript
1048 | class Pair<K, V> {
1049 |   constructor(public key: K, public value: V) {}
1050 | }
1051 | 
1052 | const pair = new Pair<string, number>("id", 42);
1053 | ```
1054 | 
1055 | #### Обмеження generic через extends
1056 | 
1057 | ```TypeScript
1058 | class Collection<T extends { id: number }> {
1059 |   private items: T[] = [];
1060 |   add(item: T) { this.items.push(item); }
1061 |   getById(id: number): T | undefined {
1062 |     return this.items.find(i => i.id === id);
1063 |   }
1064 | }
1065 | 
1066 | const users = new Collection<{ id: number; name: string }>();
1067 | users.add({ id: 1, name: "Alice" });
1068 | ```
1069 | 
1070 | #### Переваги:
1071 | 
1072 | - Універсальність класів без втрати типобезпеки.
1073 | 
1074 | - Повторне використання логіки для різних типів.
1075 | 
1076 | - Зв’язок між методами і властивостями через один параметр типу.
1077 | 
1078 | </details>
1079 | 
1080 | <details>
1081 | <summary>31. Як реалізувати узагальнене обмеження (generic constraint) у TypeScript і для чого воно потрібне?</summary>
1082 | 
1083 | #### TypeScript
1084 | 
1085 | У TypeScript можна обмежити generic-параметр за допомогою extends, щоб він
1086 | повинен був відповідати певному типу або інтерфейсу. Це дозволяє безпечно
1087 | використовувати властивості або методи об’єкта всередині функції або класу.
1088 | 
1089 | #### Приклад із функцією
1090 | 
1091 | ```TypeScript
1092 | interface HasLength {
1093 |   length: number;
1094 | }
1095 | 
1096 | function logLength<T extends HasLength>(item: T): void {
1097 |   console.log(item.length);
1098 | }
1099 | 
1100 | logLength("Hello");      // ✅ рядок має length
1101 | logLength([1, 2, 3]);    // ✅ масив має length
1102 | logLength(42);           // ❌ помилка, number не має length
1103 | ```
1104 | 
1105 | #### Приклад із класом
1106 | 
1107 | ```TypeScript
1108 | class Collection<T extends { id: number }> {
1109 |   private items: T[] = [];
1110 |   add(item: T) { this.items.push(item); }
1111 |   getById(id: number): T | undefined {
1112 |     return this.items.find(i => i.id === id);
1113 |   }
1114 | }
1115 | 
1116 | const users = new Collection<{ id: number; name: string }>();
1117 | users.add({ id: 1, name: "Alice" }); // ✅ ok
1118 | ```
1119 | 
1120 | #### Переваги:
1121 | 
1122 | - Дозволяє використовувати властивості або методи об’єкта без перевірок типу.
1123 | 
1124 | - Зберігає універсальність функцій і класів, але обмежує використання тільки
1125 |   сумісними типами.
1126 | 
1127 | </details>
1128 | 
1129 | ### Розширені типи та техніки в TypeScript
1130 | 
1131 | <details>
1132 | <summary>32. Що таке дискримінований союз (Discriminated Union) у TypeScript і як він працює?</summary>
1133 | 
1134 | #### TypeScript
1135 | 
1136 | **Discriminated Union** — це патерн, коли `union` типів має спільну
1137 | властивість-дискримінатор (зазвичай літеральний тип), яка дозволяє компілятору
1138 | звузити тип під час перевірок.
1139 | 
1140 | #### Приклад:
1141 | 
1142 | ```TypeScript
1143 | type Circle = {
1144 |   kind: "circle";
1145 |   radius: number;
1146 | };
1147 | 
1148 | type Rectangle = {
1149 |   kind: "rectangle";
1150 |   width: number;
1151 |   height: number;
1152 | };
1153 | 
1154 | type Shape = Circle | Rectangle;
1155 | 
1156 | function area(shape: Shape): number {
1157 |   switch (shape.kind) {
1158 |     case "circle":
1159 |       return Math.PI * shape.radius ** 2;
1160 |     case "rectangle":
1161 |       return shape.width * shape.height;
1162 |   }
1163 | }
1164 | ```
1165 | 
1166 | #### Особливості:
1167 | 
1168 | - `kind` (або інша властивість) має літеральне значення, унікальне для кожного
1169 |   варіанту.
1170 | 
1171 | - Це дозволяє TypeScript робити type narrowing автоматично у `switch` чи `if`.
1172 | 
1173 | - Використовується для моделювання станів, подій, результатів API.
1174 | 
1175 | Фактично, це спосіб реалізації type-safe "enum-like" варіантів з різними
1176 | структурами даних.
1177 | 
1178 | </details>
1179 | 
1180 | <details>
1181 | <summary>33. Що таке утилітний тип Readonly у TypeScript і як його оголосити/використати?</summary>
1182 | 
1183 | #### TypeScript
1184 | 
1185 | `Readonly<T>` — це вбудований утилітний тип, який робить усі властивості об’єкта
1186 | тільки для читання (неможливо змінювати після ініціалізації).
1187 | 
1188 | #### Приклад використання:
1189 | 
1190 | ```TypeScript
1191 | type User = {
1192 |   id: number;
1193 |   name: string;
1194 | };
1195 | 
1196 | const u: Readonly<User> = {
1197 |   id: 1,
1198 |   name: "Alice"
1199 | };
1200 | 
1201 | u.name = "Bob"; // ❌ Помилка: властивість доступна тільки для читання
1202 | ```
1203 | 
1204 | #### Як оголошений всередині TS
1205 | 
1206 | ```TypeScript
1207 | type Readonly<T> = {
1208 |   readonly [P in keyof T]: T[P];
1209 | };
1210 | ```
1211 | 
1212 | - Тобто це mapped type, який додає модифікатор readonly до кожної властивості.
1213 | 
1214 | Використовується для іммутабельних даних, DTO та запобігання випадковим змінам.
1215 | 
1216 | </details>
1217 | 
1218 | <details>
1219 | <summary>34. Що таке mapped types у TypeScript і як їх використовувати?</summary>
1220 | 
1221 | #### TypeScript
1222 | 
1223 | **Mapped types** — це спосіб створювати нові типи на основі існуючих, проходячи
1224 | по ключах (`keyof`) та трансформуючи їх. Це використовується для створення
1225 | утилітних типів (`Readonly`, `Partial`, `Pick` тощо).
1226 | 
1227 | #### Базовий приклад:
1228 | 
1229 | ```TypeScript
1230 | type User = {
1231 |   id: number;
1232 |   name: string;
1233 |   active: boolean;
1234 |   };
1235 | 
1236 | // Робимо всі властивості readonly
1237 | type ReadonlyUser = {
1238 |   readonly [K in keyof User]: User[K];
1239 | };
1240 | ```
1241 | 
1242 | #### Використання з модифікаторами:
1243 | 
1244 | - `readonly` / `-readonly` → додає або прибирає "тільки для читання"
1245 | 
1246 | - `?` / `-?` → робить поле опціональним або обов’язковим
1247 | 
1248 | ```TypeScript
1249 | type PartialUser = {
1250 |   [K in keyof User]?: User[K];
1251 | };
1252 | ```
1253 | 
1254 | #### Generic-приклад:
1255 | 
1256 | ```TypeScript
1257 | type MyMapped<T> = {
1258 |   [P in keyof T]: T[P];
1259 | };
1260 | 
1261 | type Test = MyMapped<{ a: string; b: number }>;
1262 | // { a: string; b: number }
1263 | ```
1264 | 
1265 | #### Реальні приклади (вбудовані утиліти):
1266 | 
1267 | - `Readonly<T>` → робить усі властивості readonly
1268 | 
1269 | - `Partial<T>` → робить усі властивості опціональними
1270 | 
1271 | - `Required<T>` → робить усі властивості обов’язковими
1272 | 
1273 | - `Record<K, T>` → створює об’єкт, де всі ключі мають значення типу T
1274 | 
1275 | Mapped types корисні для масових перетворень типів без дублювання коду.
1276 | 
1277 | </details>
1278 | 
1279 | <details>
1280 | <summary>35. Що таке умовні типи (Conditional Types) у TypeScript і як вони працюють?</summary>
1281 | 
1282 | #### TypeScript
1283 | 
1284 | **Умовні типи** дозволяють описувати залежності між типами за допомогою
1285 | конструкції T extends U ? X : Y.
1286 | 
1287 | - Якщо T підтип U, результат буде X.
1288 | 
1289 | - Інакше — Y.
1290 | 
1291 | #### Базовий приклад:
1292 | 
1293 | ```TypeScript
1294 | type IsString<T> = T extends string ? "yes" : "no";
1295 | 
1296 | type A = IsString<string>; // "yes"
1297 | type B = IsString<number>; // "no"
1298 | ```
1299 | 
1300 | #### Використання з узагальненими типами:
1301 | 
1302 | ```TypeScript
1303 | type ElementType<T> = T extends (infer U)[] ? U : T;
1304 | 
1305 | type A = ElementType<string[]>; // string
1306 | type B = ElementType<number>;   // number
1307 | ```
1308 | 
1309 | #### Застосування у практиці:
1310 | 
1311 | ```TypeScript
1312 | type ApiResponse<T> = T extends Error ? { success: false; error: T }
1313 |                                       : { success: true; data: T };
1314 | 
1315 | type R1 = ApiResponse<string>; // { success: true; data: string }
1316 | type R2 = ApiResponse<Error>;  // { success: false; error: Error }
1317 | ```
1318 | 
1319 | #### Особливості:
1320 | 
1321 | - Працюють у поєднанні з generics, union та mapped types.
1322 | 
1323 | - Часто використовуються у вбудованих утилітах:
1324 | 
1325 |   - `Exclude<T, U>`
1326 | 
1327 |   - `Extract<T, U>`
1328 | 
1329 |   - `NonNullable<T>`
1330 | 
1331 | Умовні типи — це основа для гнучкої метапрограмінгової типізації.
1332 | 
1333 | </details>
1334 | 
1335 | <details>
1336 | <summary>36. Що таке індексні типи (Indexed Access Types) у TypeScript і як працює ключове слово keyof?</summary>
1337 | 
1338 | #### TypeScript
1339 | 
1340 | `keyof`
1341 | 
1342 | - keyof створює об’єднання (union) ключів заданого типу.
1343 | 
1344 | - Використовується для обмеження значень ключами інтерфейсу/типу.
1345 | 
1346 | ```TypeScript
1347 | type User = { id: number; name: string; active: boolean };
1348 | type UserKeys = keyof User;
1349 | // "id" | "name" | "active"
1350 | ```
1351 | 
1352 | #### Indexed Access Types (T[K])
1353 | 
1354 | - Дозволяють отримати тип значення за конкретним ключем.
1355 | 
1356 | ```TypeScript
1357 | type UserIdType = User["id"]; // number
1358 | type UserNameOrActive = User["name" | "active"]; // string | boolean
1359 | ```
1360 | 
1361 | #### Приклад разом
1362 | 
1363 | ```TypeScript
1364 | function getValue<T, K extends keyof T>(obj: T, key: K): T[K] {
1365 |   return obj[key];
1366 | }
1367 | 
1368 | const user: User = { id: 1, name: "Alice", active: true };
1369 | 
1370 | let nameValue = getValue(user, "name");   // string
1371 | let activeValue = getValue(user, "active"); // boolean
1372 | ```
1373 | 
1374 | #### Навіщо це потрібно:
1375 | 
1376 | - Для generic-утиліт, які працюють із довільними об’єктами.
1377 | 
1378 | - Для побудови type-safe доступу до властивостей.
1379 | 
1380 | - Основа для утилітних типів (Pick, Omit, Record тощо).
1381 | 
1382 | </details>
1383 | 
1384 | <details>
1385 | <summary>37. У чому різниця між приведенням типів (type casting) і твердженням типів (type assertion) у TypeScript?</summary>
1386 | 
1387 | #### TypeScript
1388 | 
1389 | 1. **Твердження типів (Type Assertion)**
1390 | 
1391 | - Це інструкція для компілятора, що значення має певний тип.
1392 | 
1393 | - Не змінює значення у рантаймі.
1394 | 
1395 | - Використовується, коли розробник краще знає тип, ніж TypeScript.
1396 | 
1397 | ```TypeScript
1398 | let value: unknown = "Hello";
1399 | let strLength = (value as string).length; // "повір, це string"
1400 | ```
1401 | 
1402 | 2. **Приведення типів (Type Casting, runtime cast)**
1403 | 
1404 | - Це перетворення значення в інший тип у рантаймі (наприклад, Number("123") →
1405 |   123).
1406 | 
1407 | - Виконується реальною функцією чи оператором у JS.
1408 | 
1409 | ```TypeScript
1410 | let str = "123";
1411 | let num = Number(str); // runtime casting → 123
1412 | ```
1413 | 
1414 | #### Відмінність
1415 | 
1416 | - **Type assertion:** впливає тільки на компіляцію, ніяких змін у рантаймі.
1417 | 
1418 | - **Type casting:** реально змінює значення під час виконання.
1419 | 
1420 | У TypeScript під "casting" часто мають на увазі type assertions, але це не одне
1421 | й те саме.
1422 | 
1423 | </details>
1424 | 
1425 | <details>
1426 | <summary>38. Що таке утилітні типи Partial, Required, Readonly та Pick у TypeScript і для чого вони потрібні?</summary>
1427 | 
1428 | #### TypeScript
1429 | 
1430 | 1. `Partial<T>`
1431 | 
1432 | - Робить усі властивості опціональними.
1433 | 
1434 | ```TypeScript
1435 | type User = { id: number; name: string; };
1436 | type PartialUser = Partial<User>;
1437 | // { id?: number; name?: string }
1438 | ```
1439 | 
1440 | - Використовується для об’єктів оновлення/патчів.
1441 | 
1442 | 2. `Required<T>`
1443 | 
1444 | - Робить усі властивості обов’язковими (знімає ?).
1445 | 
1446 | ```TypeScript
1447 | type UserOptional = { id?: number; name?: string; };
1448 | type RequiredUser = Required<UserOptional>;
1449 | // { id: number; name: string }
1450 | ```
1451 | 
1452 | - Корисно для валидації, коли потрібен повний об’єкт.
1453 | 
1454 | 3. `Readonly<T>`
1455 | 
1456 | - Робить усі властивості доступними тільки для читання.
1457 | 
1458 | ```TypeScript
1459 | type User = { id: number; name: string; };
1460 | type ReadonlyUser = Readonly<User>;
1461 | 
1462 | const u: ReadonlyUser = { id: 1, name: "Alice" };
1463 | u.name = "Bob"; // ❌ Помилка
1464 | ```
1465 | 
1466 | - Застосовується для іммутабельних даних.
1467 | 
1468 | 4. `Pick<T, K>`
1469 | 
1470 | - Вибирає підмножину властивостей з типу T.
1471 | 
1472 | ```TypeScript
1473 | type User = { id: number; name: string; active: boolean };
1474 | type UserPreview = Pick<User, "id" | "name">;
1475 | // { id: number; name: string }
1476 | ```
1477 | 
1478 | - Корисно для DTO, селекторів, відображення лише потрібних полів.
1479 | 
1480 | Усі вони побудовані на mapped types + keyof.
1481 | 
1482 | Найчастіше застосовуються для гнучкої типізації API, DTO, form state, патчів
1483 | даних.
1484 | 
1485 | </details>
1486 | 
1487 | <details>
1488 | <summary>39. Що таке тип never у TypeScript і в яких випадках він застосовується?</summary>
1489 | 
1490 | #### TypeScript
1491 | 
1492 | `never`
1493 | 
1494 | - Це спеціальний тип, який означає значення, що ніколи не існує.
1495 | 
1496 | - Використовується там, де функція або вираз не повертає значення взагалі.
1497 | 
1498 | #### Основні випадки використання
1499 | 
1500 | 1. **Функція, яка ніколи не завершується успішно**
1501 | 
1502 | ```TypeScript
1503 | function fail(message: string): never {
1504 |   throw new Error(message);
1505 | }
1506 | ```
1507 | 
1508 | 2. **Функція з нескінченним циклом**
1509 | 
1510 | ```TypeScript
1511 | function infiniteLoop(): never {
1512 |   while (true) {}
1513 | }
1514 | ```
1515 | 
1516 | 3. **Exhaustive checking (перевірка вичерпності union-типів)**
1517 | 
1518 | ```TypeScript
1519 | type Shape = { kind: "circle"; radius: number }
1520 |            | { kind: "square"; side: number };
1521 | 
1522 | function area(shape: Shape): number {
1523 |   switch (shape.kind) {
1524 |     case "circle": return Math.PI * shape.radius ** 2;
1525 |     case "square": return shape.side ** 2;
1526 |     default:
1527 |       const _exhaustiveCheck: never = shape; // якщо додати новий варіант → помилка
1528 |       return _exhaustiveCheck;
1529 |   }
1530 | }
1531 | ```
1532 | 
1533 | #### Ключові моменти
1534 | 
1535 | - `never` — підтип будь-якого типу, але жоден тип не є підтипом never (крім
1536 |   нього самого).
1537 | 
1538 | - Використовується для строгих перевірок типів і ситуацій, де значення бути не
1539 |   може.
1540 | 
1541 | never корисний у type-safe error handling та для гарантій повного покриття
1542 | union-типів.
1543 | 
1544 | </details>
1545 | 
1546 | ### Модулі та простори імен у TypeScript
1547 | 
1548 | <details>
1549 | <summary>40. Як організувати код за допомогою модулів у TypeScript?</summary>
1550 | 
1551 | #### TypeScript
1552 | 
1553 | **Основи модулів у TypeScript**
1554 | 
1555 | - Кожен файл з import або export стає модулем.
1556 | 
1557 | - Використовуються ключові слова export та import (як у ES6).
1558 | 
1559 | #### Приклад організації
1560 | 
1561 | `math.ts`
1562 | 
1563 | ```TypeScript
1564 | export function add(a: number, b: number): number {
1565 |   return a + b;
1566 | }
1567 | 
1568 | export const PI = 3.14;
1569 | ```
1570 | 
1571 | `app.ts`
1572 | 
1573 | ```TypeScript
1574 | import { add, PI } from "./math";
1575 | 
1576 | console.log(add(2, 3)); // 5
1577 | console.log(PI);        // 3.14
1578 | ```
1579 | 
1580 | #### Експорт за замовчуванням
1581 | 
1582 | ```TypeScript
1583 | // logger.ts
1584 | export default function log(msg: string) {
1585 |   console.log("LOG:", msg);
1586 | }
1587 | 
1588 | // app.ts
1589 | import log from "./logger";
1590 | log("hello");
1591 | ```
1592 | 
1593 | #### Перейменування та групування
1594 | 
1595 | ```TypeScript
1596 | import * as MathUtils from "./math";
1597 | console.log(MathUtils.add(1, 2));
1598 | ```
1599 | 
1600 | #### Організація проекту
1601 | 
1602 | - Файлова структура: групувати код за доменами (наприклад, services/, models/,
1603 |   utils/).
1604 | 
1605 | - Barrel files (індексні модулі): об’єднувати кілька експортувань в одному
1606 |   файлі.
1607 | 
1608 | ```TypeScript
1609 | // utils/index.ts
1610 | export * from "./math";
1611 | export * from "./logger";
1612 | 
1613 | // app.ts
1614 | import { add, PI } from "./utils";
1615 | ```
1616 | 
1617 | #### Конфігурація
1618 | 
1619 | - У `tsconfig.json` можна налаштувати:
1620 | 
1621 |   - "module": (esnext, commonjs, amd, залежно від оточення).
1622 | 
1623 |   - "baseUrl", "paths": для зручних alias-імпортів.
1624 | 
1625 | ```json
1626 | {
1627 |   "compilerOptions": {
1628 |     "baseUrl": "./src",
1629 |     "paths": {
1630 |       "@utils/*": ["utils/*"]
1631 |     }
1632 |   }
1633 | }
1634 | ```
1635 | 
1636 | Модулі в TypeScript = ті самі ES6 модулі, але з повною підтримкою типів.
1637 | 
1638 | </details>
1639 | 
1640 | <details>
1641 | <summary>41. У яких випадках доцільно використовувати простори імен (namespace) у TypeScript</summary>
1642 | 
1643 | #### TypeScript
1644 | 
1645 | #### Простори імен (namespace)
1646 | 
1647 | - Це спосіб групувати логіку всередині одного глобального об’єкта.
1648 | 
1649 | - Використовувалися до появи модулів для уникнення колізій у глобальному
1650 |   просторі імен.
1651 | 
1652 | ```TypeScript
1653 | namespace Utils {
1654 |   export function add(a: number, b: number): number {
1655 |     return a + b;
1656 |   }
1657 | 
1658 |   export const PI = 3.14;
1659 | }
1660 | 
1661 | console.log(Utils.add(2, 3));
1662 | ```
1663 | 
1664 | #### Коли можна застосовувати
1665 | 
1666 | 1. У legacy-проєктах або коли немає системи модулів (наприклад, код вбудовується
1667 |    напряму в `<script>` без `bundler`).
1668 | 
1669 | 2. Для простих демо/маленьких проєктів, де немає потреби в модульній структурі.
1670 | 
1671 | 3. Для декларацій `.d.ts` файлів, щоб групувати типи/інтерфейси.
1672 | 
1673 | #### Чому зазвичай не варто
1674 | 
1675 | - У сучасному TypeScript стандартом є ES6 модулі (import/export).
1676 | 
1677 | - Bundlers (Webpack, Vite, esbuild) та Node.js працюють із модулями, а не
1678 |   namespace.
1679 | 
1680 | - Простори імен у великих проєктах ускладнюють масштабування.
1681 | 
1682 | #### Рекомендація:
1683 | 
1684 | - Нові проєкти → використовувати модулі.
1685 | 
1686 | - Простори імен → тільки у специфічних випадках (legacy, declaration merging,
1687 |   глобальні бібліотеки без модулів).
1688 | 
1689 | </details>
1690 | 
1691 | <details>
1692 | <summary>42. У чому різниця між внутрішніми та зовнішніми модулями в TypeScript?</summary>
1693 | 
1694 | #### TypeScript
1695 | 
1696 | 1. **Внутрішні модулі (старий підхід)**
1697 | 
1698 | - Використовували ключове слово namespace.
1699 | 
1700 | - Код групується в один глобальний об’єкт.
1701 | 
1702 | - Завантаження відбувається через `<script>` без системи модулів.
1703 | 
1704 | ```TypeScript
1705 | namespace Utils {
1706 |   export function add(a: number, b: number) {
1707 |     return a + b;
1708 |   }
1709 | }
1710 | 
1711 | console.log(Utils.add(2, 3));
1712 | ```
1713 | 
1714 | Зараз вважаються застарілими — замінені на ES6-модулі.
1715 | 
1716 | 2. **Зовнішні модулі (сучасний підхід)**
1717 | 
1718 | - Використовують export / import (ES6).
1719 | 
1720 | - Кожен файл із export → модуль.
1721 | 
1722 | - Працюють із bundlers, Node.js, Deno.
1723 | 
1724 | ```TypeScript
1725 | // math.ts
1726 | export function add(a: number, b: number) {
1727 |   return a + b;
1728 | }
1729 | 
1730 | // app.ts
1731 | import { add } from "./math";
1732 | console.log(add(2, 3));
1733 | ```
1734 | 
1735 | #### Ключова різниця
1736 | 
1737 | - **Внутрішні (namespace)** → організація всередині одного глобального простору.
1738 | 
1739 | - **Зовнішні (modules)** → організація через систему файлів з ізольованим
1740 |   простором імен.
1741 | 
1742 | #### На практиці:
1743 | 
1744 | - Використовуємо зовнішні модулі (ES6/TypeScript import/export).
1745 | 
1746 | - Внутрішні модулі (namespace) лишилися тільки для legacy та .d.ts декларацій.
1747 | 
1748 | </details>
1749 | 
1750 | <details>
1751 | <summary>43. Як у TypeScript експортувати та імпортувати модулі?</summary>
1752 | 
1753 | #### TypeScript
1754 | 
1755 | 1. **Іменований експорт**
1756 | 
1757 | ```TypeScript
1758 | // math.ts
1759 | export function add(a: number, b: number): number {
1760 |   return a + b;
1761 | }
1762 | export const PI = 3.14;
1763 | 
1764 | // app.ts
1765 | import { add, PI } from "./math";
1766 | console.log(add(2, 3), PI);
1767 | ```
1768 | 
1769 | - Можна імпортувати тільки потрібне.
1770 | 
1771 | 2. **Експорт за замовчуванням (default)**
1772 | 
1773 | ```TypeScript
1774 | // logger.ts
1775 | export default function log(message: string) {
1776 |   console.log("LOG:", message);
1777 | }
1778 | 
1779 | // app.ts
1780 | import log from "./logger";
1781 | log("hello");
1782 | ```
1783 | 
1784 | - Імпортується без {}, ім’я можна змінювати довільно.
1785 | 
1786 | 3. **Перейменування при імпорті/експорті**
1787 | 
1788 | ```TypeScript
1789 | // math.ts
1790 | export { add as sum };
1791 | 
1792 | // app.ts
1793 | import { sum as addNumbers } from "./math";
1794 | ```
1795 | 
1796 | 4. **Імпорт у вигляді простору імен**
1797 | 
1798 | ```TypeScript
1799 | // app.ts
1800 | import * as MathUtils from "./math";
1801 | console.log(MathUtils.add(2, 3));
1802 | ```
1803 | 
1804 | 5. **Повторний експорт (re-export)**
1805 | 
1806 | ```TypeScript
1807 | // utils.ts
1808 | export * from "./math";
1809 | export { default as log } from "./logger";
1810 | 
1811 | // app.ts
1812 | import { add, PI, log } from "./utils";
1813 | ```
1814 | 
1815 | #### Рекомендація:
1816 | 
1817 | - Використовувати іменований експорт для кількох сутностей.
1818 | 
1819 | - Використовувати default для однієї "головної" сутності з файлу.
1820 | 
1821 | </details>
1822 | 
1823 | <details>
1824 | <summary>44. Що таке роздільна здатність модулів (module resolution) у TypeScript і які існують стратегії?</summary>
1825 | 
1826 | #### TypeScript
1827 | 
1828 | #### Роздільна здатність модулів
1829 | 
1830 | Це алгоритм, за яким TypeScript знаходить файл, що відповідає шляху з import або
1831 | require. Приклад:
1832 | 
1833 | ```TypeScript
1834 | import { add } from "./math";
1835 | ```
1836 | 
1837 | TypeScript має зрозуміти, чи це math.ts, math.d.ts, math.js чи інший файл.
1838 | 
1839 | #### Основні стратегії
1840 | 
1841 | 1. **Classic (старий режим, до ES6)**
1842 | 
1843 | - Працює подібно до компілятора C/C++.
1844 | 
1845 | - Використовується для старих скриптів, без node_modules.
1846 | 
1847 | - Пошук іде відносно файлу, де зроблений імпорт.
1848 | 
1849 | Використовується рідко, в legacy-коді.
1850 | 
1851 | 2. **Node (за замовчуванням)**
1852 | 
1853 | - Імітує механізм Node.js.
1854 | 
1855 | - Шукає файл у такому порядку:
1856 | 
1857 |   - `./module.ts`
1858 | 
1859 |   - `./module.tsx`
1860 | 
1861 |   - `./module.d.ts`
1862 | 
1863 |   - `./module/package.json` (`types` або `main`)
1864 | 
1865 |   - `./module/index.ts`
1866 | 
1867 |   - `./module/index.d.ts`
1868 | 
1869 | Використовується у більшості сучасних проєктів.
1870 | 
1871 | #### Вибір стратегії
1872 | 
1873 | У `tsconfig.json:`
1874 | 
1875 | ```json
1876 | {
1877 |   "compilerOptions": {
1878 |     "moduleResolution": "node" // або "classic"
1879 |   }
1880 | }
1881 | ```
1882 | 
1883 | #### Додаткові можливості
1884 | 
1885 | `"baseUrl"` – вказує базову директорію для відносних шляхів.
1886 | 
1887 | `"paths"` – дозволяє створювати alias-и для імпортів.
1888 | 
1889 | ```json
1890 | {
1891 |   "compilerOptions": {
1892 |     "baseUrl": "./src",
1893 |     "paths": {
1894 |       "@utils/*": ["utils/*"]
1895 |     }
1896 |   }
1897 | }
1898 | ```
1899 | 
1900 | ```TypeScript
1901 | import { add } from "@utils/math";
1902 | ```
1903 | 
1904 | #### Підсумок:
1905 | 
1906 | `Classic` – для старих проєктів без модульної системи.
1907 | 
1908 | `Node` – стандарт для сучасних TypeScript/Node.js застосунків.
1909 | 
1910 | </details>
1911 | 
1912 | ### Декоратори та метадані у TypeScript
1913 | 
1914 | <details>
1915 | <summary>45. Як модулі TypeScript сумісні з модулями ES6?</summary>
1916 | 
1917 | #### TypeScript
1918 | 
1919 | #### Основна ідея
1920 | 
1921 | TypeScript повністю базується на ES6-модулях:
1922 | 
1923 | - import / export працюють так само, як у JS.
1924 | 
1925 | - Кожен файл з import або export вважається модулем.
1926 | 
1927 | - Під час компіляції TS може перетворювати код у різні системи модулів
1928 |   (CommonJS, ES6, AMD, UMD тощо).
1929 | 
1930 | #### Приклади
1931 | 
1932 | **TypeScript**
1933 | 
1934 | ```TypeScript
1935 | // math.ts
1936 | export function add(a: number, b: number): number {
1937 |   return a + b;
1938 | }
1939 | ```
1940 | 
1941 | **Використання в ES6**
1942 | 
1943 | ```JavaScript
1944 | import { add } from "./math.js";
1945 | console.log(add(2, 3));
1946 | ```
1947 | 
1948 | Після компіляції з "module": "ESNext" у tsconfig.json результат буде ідентичним
1949 | ES6.
1950 | 
1951 | #### Сумісність із CommonJS (Node.js)
1952 | 
1953 | TypeScript дозволяє імпортувати CommonJS-модулі:
1954 | 
1955 | ```TypeScript
1956 | import fs from "fs"; // default-імпорт
1957 | import * as path from "path"; // namespace-імпорт
1958 | ```
1959 | 
1960 | Працює завдяки прапору "esModuleInterop": true у tsconfig.json.
1961 | 
1962 | #### Ключові моменти сумісності
1963 | 
1964 | 1. **TypeScript → ES6**
1965 | 
1966 | - TS просто додає типи, які зникають при компіляції.
1967 | 
1968 | - Залишається чистий ES6-код.
1969 | 
1970 | 2. **Interop із CommonJS**
1971 | 
1972 | - Можна імпортувати старі бібліотеки (require) без проблем.
1973 | 
1974 | 3. **Default vs Named exports**
1975 | 
1976 | - ES6 → default експортується як export default.
1977 | 
1978 | - TS дозволяє змішувати default та named (через esModuleInterop).
1979 | 
1980 | #### Підсумок:
1981 | 
1982 | - TypeScript сумісний із ES6-модулями 1:1.
1983 | 
1984 | - Додатково підтримує CommonJS через компілятор.
1985 | 
1986 | - Використання "module": "ESNext" і "esModuleInterop": true робить код
1987 |   максимально універсальним.
1988 | 
1989 | </details>
1990 | 
1991 | <details>
1992 | <summary>46. Що таке декоратори у TypeScript і як їх використовують?</summary>
1993 | 
1994 | #### TypeScript
1995 | 
1996 | #### Визначення
1997 | 
1998 | **Декоратори** — це спеціальні функції, які можна застосовувати до класів,
1999 | методів, властивостей або параметрів, щоб змінювати або розширювати їхню
2000 | поведінку. Вони працюють як метадані + синтаксичний цукор над патерном
2001 | higher-order functions.
2002 | 
2003 | - У TypeScript декоратори — експериментальна функція, вмикаються прапором:
2004 | 
2005 | ```json
2006 | {
2007 |   "experimentalDecorators": true,
2008 |   "emitDecoratorMetadata": true
2009 | }
2010 | ```
2011 | 
2012 | #### Синтаксис
2013 | 
2014 | ```TypeScript
2015 | function MyDecorator(target: any) {
2016 |   console.log("Декоратор застосовано до:", target);
2017 | }
2018 | 
2019 | @MyDecorator
2020 | class Example {}
2021 | ```
2022 | 
2023 | #### Види декораторів
2024 | 
2025 | 1. **Класів**
2026 | 
2027 | ```TypeScript
2028 | function LogClass(constructor: Function) {
2029 |   console.log("Class:", constructor.name);
2030 | }
2031 | 
2032 | @LogClass
2033 | class User {}
2034 | ```
2035 | 
2036 | 2. **Методів**
2037 | 
2038 | ```TypeScript
2039 | function LogMethod(
2040 |   target: any,
2041 |   propertyKey: string,
2042 |   descriptor: PropertyDescriptor
2043 | ) {
2044 |   const original = descriptor.value;
2045 |   descriptor.value = function (...args: any[]) {
2046 |     console.log(`Call ${propertyKey} with`, args);
2047 |     return original.apply(this, args);
2048 |   };
2049 | }
2050 | 
2051 | class Calculator {
2052 |   @LogMethod
2053 |   add(a: number, b: number) {
2054 |     return a + b;
2055 |   }
2056 | }
2057 | 
2058 | new Calculator().add(2, 3);
2059 | ```
2060 | 
2061 | 3. **Властивостей**
2062 | 
2063 | ```TypeScript
2064 | function Readonly(target: any, propertyKey: string) {
2065 |   Object.defineProperty(target, propertyKey, { writable: false });
2066 | }
2067 | 
2068 | class Car {
2069 |   @Readonly
2070 |   brand: string = "Tesla";
2071 | }
2072 | ```
2073 | 
2074 | 4. **Параметрів**
2075 | 
2076 | ```TypeScript
2077 | function LogParam(target: any, method: string, index: number) {
2078 |   console.log(`Param at index ${index} in method ${method}`);
2079 | }
2080 | 
2081 | class Service {
2082 |   print(@LogParam msg: string) {
2083 |     console.log(msg);
2084 |   }
2085 | }
2086 | ```
2087 | 
2088 | #### Використання на практиці
2089 | 
2090 | - DI-фреймворки (NestJS, Angular) — для позначення сервісів, компонентів.
2091 | 
2092 | - Логування, кешування, валідація.
2093 | 
2094 | - Метадані (через reflect-metadata).
2095 | 
2096 | #### Підсумок:
2097 | 
2098 | **Декоратори** — це функції-обгортки для класів та їх елементів, що дозволяють
2099 | декларативно додавати поведінку.
2100 | 
2101 | </details>
2102 | 
2103 | <details>
2104 | <summary>47. Що таке декоратори класів у TypeScript і як вони змінюють поведінку класів?</summary>
2105 | 
2106 | #### TypeScript
2107 | 
2108 | #### Визначення
2109 | 
2110 | **Декоратор класу** — це функція, яка отримує конструктор класу як аргумент. Він
2111 | може:
2112 | 
2113 | - додати метадані,
2114 | 
2115 | - змінити або підмінити конструктор,
2116 | 
2117 | - модифікувати/доповнити прототип.
2118 | 
2119 | #### Сигнатура
2120 | 
2121 | ```TypeScript
2122 | type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;
2123 | ```
2124 | 
2125 | #### Приклад 1. Логування створення класу
2126 | 
2127 | ```TypeScript
2128 | function LogClass(constructor: Function) {
2129 |   console.log(`Клас створено: ${constructor.name}`);
2130 | }
2131 | 
2132 | @LogClass
2133 | class User {}
2134 | ```
2135 | 
2136 | - При завантаженні модуля виведе: Клас створено: User.
2137 | 
2138 | #### Приклад 2. Додавання властивості через прототип
2139 | 
2140 | ```TypeScript
2141 | function WithTimestamp(constructor: Function) {
2142 |   constructor.prototype.timestamp = new Date();
2143 | }
2144 | 
2145 | @WithTimestamp
2146 | class Order {}
2147 | 
2148 | const o = new Order();
2149 | console.log(o.timestamp); // Дата створення
2150 | ```
2151 | 
2152 | #### Приклад 3. Підміна конструктора
2153 | 
2154 | ```TypeScript
2155 | function Sealed<T extends { new (...args: any[]): {} }>(constructor: T) {
2156 |   return class extends constructor {
2157 |     id = Math.random();
2158 |   };
2159 | }
2160 | 
2161 | @Sealed
2162 | class Product {
2163 |   name = "Book";
2164 | }
2165 | 
2166 | const p = new Product();
2167 | console.log(p.name, p.id); // "Book", 0.12345
2168 | ```
2169 | 
2170 | - Декоратор створив новий клас, що розширює оригінальний.
2171 | 
2172 | #### Використання на практиці
2173 | 
2174 | - **Angular/NestJS:** `@Component`, `@Injectable`, `@Module`.
2175 | 
2176 | - **Логування, трейсинг:** автоматично додавати поведінку.
2177 | 
2178 | - **Метадані:** вказувати схеми валідації, ролі доступу тощо.
2179 | 
2180 | #### Підсумок:
2181 | 
2182 | Декоратори класів дозволяють декларативно змінювати або розширювати клас
2183 | (метадані, властивості, конструктор), що робить їх основою для DI та
2184 | метапрограмування в TypeScript.
2185 | 
2186 | </details>
2187 | 
2188 | <details>
2189 | <summary>48. Що таке декоратори методів у TypeScript і як їх використовувати?</summary>
2190 | 
2191 | #### TypeScript
2192 | 
2193 | #### Визначення
2194 | 
2195 | **Декоратор методу** — це функція, яка застосовується до методу класу. Він
2196 | отримує:
2197 | 
2198 | 1. `target` — прототип класу (для екземплярного методу) або конструктор (для
2199 |    статичного).
2200 | 
2201 | 2. `propertyKey` — ім’я методу.
2202 | 
2203 | 3. `descriptor` — PropertyDescriptor, що описує метод (можна змінювати).
2204 | 
2205 | Використовується для перехоплення викликів, логування, кешування, валідації
2206 | тощо.
2207 | 
2208 | #### Сигнатура
2209 | 
2210 | ```TypeScript
2211 | type MethodDecorator = (
2212 |   target: Object,
2213 |   propertyKey: string | symbol,
2214 |   descriptor: PropertyDescriptor
2215 | ) => void | PropertyDescriptor;
2216 | ```
2217 | 
2218 | #### Приклад 1. Логування викликів
2219 | 
2220 | ```TypeScript
2221 | function LogMethod(
2222 |   target: Object,
2223 |   propertyKey: string,
2224 |   descriptor: PropertyDescriptor
2225 | ) {
2226 |   const original = descriptor.value;
2227 |   descriptor.value = function (...args: any[]) {
2228 |     console.log(`Виклик ${propertyKey} з аргументами:`, args);
2229 |     return original.apply(this, args);
2230 |   };
2231 | }
2232 | 
2233 | class Calculator {
2234 |   @LogMethod
2235 |   add(a: number, b: number) {
2236 |     return a + b;
2237 |   }
2238 | }
2239 | 
2240 | new Calculator().add(2, 3);
2241 | // Лог: "Виклик add з аргументами: [2, 3]"
2242 | ```
2243 | 
2244 | #### Приклад 2. Захист від повторних викликів
2245 | 
2246 | ```TypeScript
2247 | function Once(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
2248 |   let called = false;
2249 |   const original = descriptor.value;
2250 |   descriptor.value = function (...args: any[]) {
2251 |     if (called) {
2252 |       console.log(`Метод ${propertyKey} вже викликано!`);
2253 |       return;
2254 |     }
2255 |     called = true;
2256 |     return original.apply(this, args);
2257 |   };
2258 | }
2259 | 
2260 | class Service {
2261 |   @Once
2262 |   init() {
2263 |     console.log("Ініціалізація...");
2264 |   }
2265 | }
2266 | 
2267 | const s = new Service();
2268 | s.init(); // "Ініціалізація..."
2269 | s.init(); // "Метод init вже викликано!"
2270 | ```
2271 | 
2272 | #### Приклад 3. Async error handler
2273 | 
2274 | ```TypeScript
2275 | function CatchErrors(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
2276 |   const original = descriptor.value;
2277 |   descriptor.value = async function (...args: any[]) {
2278 |     try {
2279 |       return await original.apply(this, args);
2280 |     } catch (err) {
2281 |       console.error(`Помилка у ${propertyKey}:`, err);
2282 |     }
2283 |   };
2284 | }
2285 | 
2286 | class Api {
2287 |   @CatchErrors
2288 |   async fetchData() {
2289 |     throw new Error("Network error");
2290 |   }
2291 | }
2292 | 
2293 | new Api().fetchData(); // Лог: "Помилка у fetchData: Error: Network error"
2294 | ```
2295 | 
2296 | #### Підсумок:
2297 | 
2298 | Декоратори методів у TypeScript дають можливість переписати або обгорнути метод
2299 | (через PropertyDescriptor), що робить їх зручними для реалізації AOP-патернів
2300 | (логування, кешування, обробка помилок, throttle/debounce).
2301 | 
2302 | </details>
2303 | 
2304 | <details>
2305 | <summary>49. Що таке декоратори аксесорів (get/set) у TypeScript і як вони працюють?</summary>
2306 | 
2307 | #### TypeScript
2308 | 
2309 | #### Визначення
2310 | 
2311 | **Декоратори аксесорів** застосовуються до геттерів або сеттерів у класах. Вони
2312 | працюють майже так само, як декоратори методів, але застосовуються до get/set.
2313 | 
2314 | - Сигнатура:
2315 | 
2316 | ```TypeScript
2317 | type AccessorDecorator = (
2318 |   target: Object,
2319 |   propertyKey: string | symbol,
2320 |   descriptor: PropertyDescriptor
2321 | ) => void | PropertyDescriptor;
2322 | ```
2323 | 
2324 | #### Приклад 1. Логування доступу
2325 | 
2326 | ```TypeScript
2327 | function LogAccessor(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
2328 |   const originalGet = descriptor.get;
2329 |   const originalSet = descriptor.set;
2330 | 
2331 |   if (originalGet) {
2332 |     descriptor.get = function () {
2333 |       console.log(`Отримання значення ${propertyKey}`);
2334 |       return originalGet.apply(this);
2335 |     };
2336 |   }
2337 | 
2338 |   if (originalSet) {
2339 |     descriptor.set = function (value: any) {
2340 |       console.log(`Присвоєння ${propertyKey} = ${value}`);
2341 |       return originalSet.apply(this, [value]);
2342 |     };
2343 |   }
2344 | }
2345 | 
2346 | class User {
2347 |   private _name: string = "Anonymous";
2348 | 
2349 |   @LogAccessor
2350 |   get name() {
2351 |     return this._name;
2352 |   }
2353 | 
2354 |   set name(value: string) {
2355 |     this._name = value;
2356 |   }
2357 | }
2358 | 
2359 | const u = new User();
2360 | console.log(u.name);   // Лог: Отримання значення name
2361 | u.name = "Viktor";     // Лог: Присвоєння name = Viktor
2362 | ```
2363 | 
2364 | #### Приклад 2. Валідація сеттера
2365 | 
2366 | ```TypeScript
2367 | function MinLength(length: number) {
2368 |   return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
2369 |     const originalSet = descriptor.set!;
2370 |     descriptor.set = function (value: string) {
2371 |       if (value.length < length) {
2372 |         throw new Error(`${propertyKey} має бути мінімум ${length} символів`);
2373 |       }
2374 |       originalSet.call(this, value);
2375 |     };
2376 |   };
2377 | }
2378 | 
2379 | class Product {
2380 |   private _title: string = "";
2381 | 
2382 |   @MinLength(3)
2383 |   set title(value: string) {
2384 |     this._title = value;
2385 |   }
2386 | 
2387 |   get title() {
2388 |     return this._title;
2389 |   }
2390 | }
2391 | 
2392 | const p = new Product();
2393 | p.title = "TV";   // ❌ Error: title має бути мінімум 3 символів
2394 | ```
2395 | 
2396 | #### Підсумок
2397 | 
2398 | - Декоратори аксесорів працюють з геттерами/сеттерами.
2399 | 
2400 | - Дозволяють:
2401 | 
2402 |   - логувати доступ,
2403 | 
2404 |   - робити валідацію,
2405 | 
2406 |   - контролювати зміну значень.
2407 | 
2408 | - Як і метод-декоратори, вони змінюють PropertyDescriptor.
2409 | 
2410 | </details>
2411 | 
2412 | <details>
2413 | <summary>50. Що таке декоратори властивостей у TypeScript і як їх використовувати?</summary>
2414 | 
2415 | #### TypeScript
2416 | 
2417 | #### Визначення
2418 | 
2419 | **Декоратор властивості** застосовується до поля класу. На відміну від методів
2420 | чи аксесорів, він не має доступу до PropertyDescriptor, оскільки властивості ще
2421 | не існують на момент компіляції.
2422 | 
2423 | - Сигнатура:
2424 | 
2425 | ```TypeScript
2426 | type PropertyDecorator = (
2427 |   target: Object,
2428 |   propertyKey: string | symbol
2429 | ) => void;
2430 | ```
2431 | 
2432 | #### Приклад 1. Логування оголошення властивості
2433 | 
2434 | ```TypeScript
2435 | function LogProperty(target: any, propertyKey: string) {
2436 |   console.log(`Властивість "${propertyKey}" додана у клас ${target.constructor.name}`);
2437 | }
2438 | 
2439 | class User {
2440 |   @LogProperty
2441 |   name: string;
2442 | 
2443 |   constructor(name: string) {
2444 |     this.name = name;
2445 |   }
2446 | }
2447 | // Лог: Властивість "name" додана у клас User
2448 | ```
2449 | 
2450 | #### Приклад 2. Додавання метаданих (валидація)
2451 | 
2452 | ```TypeScript
2453 | function Required(target: any, propertyKey: string) {
2454 |   if (!target.__required) {
2455 |     target.__required = [];
2456 |   }
2457 |   target.__required.push(propertyKey);
2458 | }
2459 | 
2460 | class Product {
2461 |   @Required
2462 |   title: string;
2463 | 
2464 |   @Required
2465 |   price: number;
2466 | }
2467 | 
2468 | function validate(obj: any) {
2469 |   const required = obj.__proto__.__required || [];
2470 |   for (const key of required) {
2471 |     if (obj[key] === undefined) {
2472 |       throw new Error(`Поле ${key} є обов’язковим`);
2473 |     }
2474 |   }
2475 | }
2476 | 
2477 | const p = new Product();
2478 | p.title = "TV";
2479 | validate(p); // ❌ Error: Поле price є обов’язковим
2480 | ```
2481 | 
2482 | #### Приклад 3. Автоматична ініціалізація
2483 | 
2484 | ```TypeScript
2485 | function DefaultValue(value: any) {
2486 |   return function (target: any, propertyKey: string) {
2487 |     let val = value;
2488 |     Object.defineProperty(target, propertyKey, {
2489 |       get: () => val,
2490 |       set: (newVal) => (val = newVal),
2491 |       enumerable: true,
2492 |       configurable: true,
2493 |     });
2494 |   };
2495 | }
2496 | 
2497 | class Settings {
2498 |   @DefaultValue("light")
2499 |   theme: string;
2500 | }
2501 | 
2502 | const s = new Settings();
2503 | console.log(s.theme); // "light"
2504 | s.theme = "dark";
2505 | console.log(s.theme); // "dark"
2506 | ```
2507 | 
2508 | #### Підсумок
2509 | 
2510 | - Декоратори властивостей працюють тільки з назвою властивості та прототипом
2511 |   класу.
2512 | 
2513 | - Використовуються для:
2514 | 
2515 |   - логування,
2516 | 
2517 |   - додавання метаданих,
2518 | 
2519 |   - створення власних валідацій,
2520 | 
2521 |   - ініціалізації значень.
2522 | 
2523 | - Для більш складних сценаріїв часто комбінуються з рефлексією
2524 |   (Reflect.metadata) або бібліотеками на кшталт class-validator.
2525 | 
2526 | </details>
2527 | 
2528 | <details>
2529 | <summary>51. Як декоратори допомагають компонувати (організовувати) код у TypeScript?</summary>
2530 | 
2531 | #### TypeScript
2532 | 
2533 | #### Визначення
2534 | 
2535 | **Декоратори** — це спеціальні анотації для класів, методів, властивостей чи
2536 | параметрів, які дозволяють додавати поведінку або метадані, не змінюючи
2537 | безпосередньо бізнес-логіку. Вони реалізують принципи AOP (Aspect-Oriented
2538 | Programming) — винесення повторюваних завдань (логування, валідація, DI) в
2539 | окремі аспекти.
2540 | 
2541 | #### Як саме декоратори компонують код
2542 | 
2543 | 1. **Виносять повторювану логіку** (логування, кешування, валідацію) у незалежні
2544 |    функції.
2545 | 
2546 | 2. **Роблять код декларативним** — замість "писати вручну" можна описати
2547 |    поведінку через анотацію.
2548 | 
2549 | 3. **Додають метадані до класів/методів/властивостей**, які можна зчитувати у
2550 |    runtime.
2551 | 
2552 | 4. **Сприяють модульності** — декоратор можна підключити/відключити без зміни
2553 |    основного коду.
2554 | 
2555 | #### Приклад — логування методів
2556 | 
2557 | **_Без декоратора:_**
2558 | 
2559 | ```TypeScript
2560 | class UserService {
2561 |   getUser(id: number) {
2562 |     console.log(`Викликано getUser з id=${id}`);
2563 |     return { id, name: "Alice" };
2564 |   }
2565 | }
2566 | ```
2567 | 
2568 | **_З декоратором:_**
2569 | 
2570 | ```TypeScript
2571 | function Log(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
2572 |   const original = descriptor.value;
2573 |   descriptor.value = function (...args: any[]) {
2574 |     console.log(`Викликано ${propertyKey} з аргументами:`, args);
2575 |     return original.apply(this, args);
2576 |   };
2577 | }
2578 | 
2579 | class UserService {
2580 |   @Log
2581 |   getUser(id: number) {
2582 |     return { id, name: "Alice" };
2583 |   }
2584 | }
2585 | ```
2586 | 
2587 | - Логіка логування винесена окремо, метод залишився чистим.
2588 | 
2589 | #### Приклад — DI (як у Angular / NestJS)
2590 | 
2591 | ```TypeScript
2592 | function Injectable(constructor: Function) {
2593 |   Reflect.defineMetadata("injectable", true, constructor);
2594 | }
2595 | 
2596 | @Injectable
2597 | class UserService {}
2598 | 
2599 | @Injectable
2600 | class AuthService {
2601 |   constructor(private userService: UserService) {}
2602 | }
2603 | ```
2604 | 
2605 | - Декоратори дозволяють компонувати сервіси у єдину систему без ручного
2606 |   "склеювання".
2607 | 
2608 | #### Підсумок
2609 | 
2610 | - Декоратори — це механізм композиції коду у TypeScript.
2611 | 
2612 | - Вони дозволяють:
2613 | 
2614 |   - підключати поведінку без змін основного коду,
2615 | 
2616 |   - додавати метадані для фреймворків (DI, маршрутизація, ORM),
2617 | 
2618 |   - робити код чистішим і декларативним.
2619 | 
2620 | - Використовуються в Angular, NestJS, TypeORM, MobX для організації архітектури.
2621 | 
2622 | </details>
2623 | 
2624 | <details>
2625 | <summary>52. Що таке рефлексія у TypeScript і як вона використовується разом із декораторами?</summary>
2626 | 
2627 | #### TypeScript
2628 | 
2629 | #### Що таке рефлексія
2630 | 
2631 | **Рефлексія** — це можливість коду отримувати метадані про себе під час
2632 | виконання (runtime). У TypeScript це реалізується через бібліотеку
2633 | `reflect-metadata`, яка дозволяє зчитувати/записувати метадані для класів,
2634 | методів, властивостей і параметрів.
2635 | 
2636 | #### Як це пов’язано з декораторами
2637 | 
2638 | Декоратори не змінюють сам об’єкт напряму, а часто зберігають додаткову
2639 | інформацію у метаданих. Цю інформацію потім можна зчитати через
2640 | `Reflect.getMetadata`.
2641 | 
2642 | #### Приклад — збереження метаданих
2643 | 
2644 | ```TypeScript
2645 | import "reflect-metadata";
2646 | 
2647 | function MinLength(length: number) {
2648 |   return function (target: any, propertyKey: string) {
2649 |     Reflect.defineMetadata("minLength", length, target, propertyKey);
2650 |   };
2651 | }
2652 | 
2653 | class User {
2654 |   @MinLength(5)
2655 |   username: string;
2656 | }
2657 | 
2658 | // Читання метаданих
2659 | const len = Reflect.getMetadata("minLength", User.prototype, "username");
2660 | console.log(len); // 5
2661 | ```
2662 | 
2663 | - Декоратор `@MinLength` записує метадані, а валідаційна логіка може потім їх
2664 |   використовувати.
2665 | 
2666 | #### Приклад — декоратори параметрів (DI, як у NestJS)
2667 | 
2668 | ```TypeScript
2669 | function Inject(token: string) {
2670 |   return function (target: Object, propertyKey: string | symbol, parameterIndex: number) {
2671 |     Reflect.defineMetadata("inject", token, target, `param_${parameterIndex}`);
2672 |   };
2673 | }
2674 | 
2675 | class AuthService {
2676 |   constructor(
2677 |     @Inject("UserService") private userService: any
2678 |   ) {}
2679 | }
2680 | 
2681 | console.log(Reflect.getMetadata("inject", AuthService, "param_0"));
2682 | // "UserService"
2683 | ```
2684 | 
2685 | - Через рефлексію фреймворк розуміє, який сервіс підставити у конструктор.
2686 | 
2687 | #### Використання у фреймворках
2688 | 
2689 | - **NestJS** — `@Controller`, `@Injectable`, `@Param`, `@Body` працюють на базі
2690 |   `reflect-metadata`.
2691 | 
2692 | - **TypeORM** — `@Entity`, `@Column` зберігають схему таблиці у метаданих.
2693 | 
2694 | - **Angular** — `@Injectable` та DI-контейнер також використовують метадані.
2695 | 
2696 | #### Підсумок
2697 | 
2698 | - Рефлексія = механізм зберігання/зчитування метаданих у runtime.
2699 | 
2700 | - Декоратори = зручний спосіб записувати метадані.
2701 | 
2702 | - У поєднанні вони дозволяють будувати декларативні фреймворки (NestJS, Angular,
2703 |   TypeORM), де метадані визначають, як працює DI, маршрутизація чи ORM.
2704 | 
2705 | </details>
2706 | 
2707 | ### Конфігурація та компіляція у TypeScript
2708 | 
2709 | <details>
2710 | <summary>53. Що таке tsconfig.json і для чого він використовується у TypeScript?</summary>
2711 | 
2712 | #### TypeScript
2713 | 
2714 | #### Визначення
2715 | 
2716 | `tsconfig.json` — це конфігураційний файл TypeScript, який:
2717 | 
2718 | 1. описує як компілювати проєкт (шлях до вихідних файлів, вихідна директорія,
2719 |    таргетовану версію JS тощо);
2720 | 
2721 | 2. визначає налаштування компілятора (строгість типів, модульну систему, JSX);
2722 | 
2723 | 3. дозволяє інструментам (IDE, build-системам) розуміти структуру проєкту.
2724 | 
2725 | #### Основні поля
2726 | 
2727 | ```json
2728 | {
2729 |   "compilerOptions": {
2730 |     "target": "ES2020", // версія JS на виході
2731 |     "module": "ESNext", // система модулів
2732 |     "strict": true, // включає сувору перевірку типів
2733 |     "outDir": "./dist", // куди зберігати зкомпільовані файли
2734 |     "rootDir": "./src", // де лежить вихідний код
2735 |     "esModuleInterop": true, // коректний імпорт CommonJS-модулів
2736 |     "skipLibCheck": true // пропускає перевірку *.d.ts
2737 |   },
2738 |   "include": ["src"], // які файли включати
2739 |   "exclude": ["node_modules"] // які ігнорувати
2740 | }
2741 | ```
2742 | 
2743 | #### Призначення
2744 | 
2745 | - Забезпечує єдині правила компіляції для всіх у проєкті.
2746 | 
2747 | - Дозволяє типізувати код жорсткіше чи м’якше залежно від налаштувань.
2748 | 
2749 | - Дає можливість інтегрувати TypeScript з Webpack, Babel, Jest, ts-node тощо.
2750 | 
2751 | #### Підсумок
2752 | 
2753 | `tsconfig.json` = "контракт" між розробниками, компілятором і tooling’ом про те,
2754 | як саме треба збирати й перевіряти TypeScript-код.
2755 | 
2756 | </details>
2757 | 
2758 | <details>
2759 | <summary>54. Як у tsconfig.json вказати, які файли включати або виключати під час компіляції?</summary>
2760 | 
2761 | #### TypeScript
2762 | 
2763 | #### Ключі для цього
2764 | 
2765 | - `include` — список файлів/папок, які слід компілювати.
2766 | 
2767 | - `exclude` — список файлів/папок, які потрібно ігнорувати.
2768 | 
2769 | - `files` — явний перелік файлів (рідко використовується).
2770 | 
2771 | #### Приклади
2772 | 
2773 | 1. **Включення всіх файлів із src**
2774 | 
2775 | ```json
2776 | {
2777 |   "include": ["src"]
2778 | }
2779 | ```
2780 | 
2781 | 2. **Включення тільки .ts і .tsx файлів**
2782 | 
2783 | ```json
2784 | {
2785 |   "include": ["src/**/*.ts", "src/**/*.tsx"]
2786 | }
2787 | ```
2788 | 
2789 | 3. **Виключення тестів і node_modules**
2790 | 
2791 | ```json
2792 | {
2793 |   "include": ["src"],
2794 |   "exclude": ["node_modules", "**/*.test.ts"]
2795 | }
2796 | ```
2797 | 
2798 | 4. **Використання files для точного списку**
2799 | 
2800 | ```json
2801 | {
2802 |   "files": ["src/index.ts", "src/app.ts"]
2803 | }
2804 | ```
2805 | 
2806 | - У такому разі компілюватимуться тільки ці файли, навіть якщо є інші.
2807 | 
2808 | #### Пріоритет
2809 | 
2810 | 1. Якщо є `files` → беруться тільки вони.
2811 | 
2812 | 2. Якщо є `include` → компілятор бере ці файли + всі залежності.
2813 | 
2814 | 3. `exclude` завжди має вищий пріоритет і "вирізає" файли з `include`.
2815 | 
2816 | </details>
2817 | 
2818 | <details>
2819 | <summary>55. Які найчастіше використовувані параметри в compilerOptions файлі tsconfig.json?</summary>
2820 | 
2821 | #### TypeScript
2822 | 
2823 | #### Поширені параметри компілятора
2824 | 
2825 | - `target` — версія JavaScript на виході
2826 | 
2827 | ```json
2828 | "target": "ES2020"
2829 | ```
2830 | 
2831 | - `module` — система модулів
2832 | 
2833 | ```json
2834 | "module": "ESNext"   // або CommonJS, UMD
2835 | ```
2836 | 
2837 | - `strict` — вмикає всі суворі перевірки типів
2838 | 
2839 | ```json
2840 | "strict": true
2841 | ```
2842 | 
2843 | - `outDir` — директорія для зкомпільованих файлів
2844 | 
2845 | ```json
2846 | "outDir": "./dist"
2847 | ```
2848 | 
2849 | - `rootDir` — коренева папка вихідних файлів
2850 | 
2851 | ```json
2852 | "rootDir": "./src"
2853 | ```
2854 | 
2855 | - `esModuleInterop` — коректний імпорт CommonJS-пакетів
2856 | 
2857 | ```json
2858 | "esModuleInterop": true
2859 | ```
2860 | 
2861 | - `allowJs` — дозволяє компілювати .js файли разом із .ts
2862 | 
2863 | ```json
2864 | "allowJs": true
2865 | ```
2866 | 
2867 | - `checkJs` — перевіряє типи у .js файлах
2868 | 
2869 | ```json
2870 | "checkJs": true
2871 | ```
2872 | 
2873 | - `sourceMap` — створює .map для дебагу в браузері
2874 | 
2875 | ```json
2876 | "sourceMap": true
2877 | ```
2878 | 
2879 | - `baseUrl` + `paths` — налаштування alias-імпортів
2880 | 
2881 | ```json
2882 | "baseUrl": "./src",
2883 | "paths": {
2884 |   "@components/*": ["components/*"]
2885 | }
2886 | ```
2887 | 
2888 | - `skipLibCheck` — пропускає перевірку типів у \*.d.ts
2889 | 
2890 | ```json
2891 | "skipLibCheck": true
2892 | ```
2893 | 
2894 | - `resolveJsonModule` — дозволяє імпортувати .json файли
2895 | 
2896 | ```json
2897 | "resolveJsonModule": true
2898 | ```
2899 | 
2900 | - `jsx` — режим для React/JSX
2901 | 
2902 | ```json
2903 | "jsx": "react-jsx"   // або "react", "preserve"
2904 | ```
2905 | 
2906 | **Підсумок:** найчастіше розробники у фронтенді змінюють `target`, `module`,
2907 | `strict`, `outDir`, `jsx`, `esModuleInterop`, `baseUrl/paths`.
2908 | 
2909 | </details>
2910 | 
2911 | <details>
2912 | <summary>56. Як TypeScript підтримує source maps і для чого вони потрібні?</summary>
2913 | 
2914 | #### TypeScript
2915 | 
2916 | #### Визначення
2917 | 
2918 | **Source maps** — це файли, які дозволяють браузеру або інструментам
2919 | налагодження зіставляти зкомпільований JavaScript із оригінальним
2920 | TypeScript-кодом.
2921 | 
2922 | - Формат: .js.map
2923 | 
2924 | - Дозволяє дебагати TS прямо в браузері або IDE, бачачи рядки та колонки TS, а
2925 |   не JS.
2926 | 
2927 | #### Увімкнення у tsconfig.json
2928 | 
2929 | ```json
2930 | {
2931 |   "compilerOptions": {
2932 |     "sourceMap": true,
2933 |     "outDir": "./dist"
2934 |   }
2935 | }
2936 | ```
2937 | 
2938 | - Після компіляції для кожного file.ts з’явиться file.js та file.js.map.
2939 | 
2940 | #### Приклад
2941 | 
2942 | ```TypeScript
2943 | // src/app.ts
2944 | const msg: string = "Hello TS";
2945 | console.log(msg);
2946 | ```
2947 | 
2948 | При компіляції з sourceMap: true:
2949 | 
2950 | - app.js — згенерований JS
2951 | 
2952 | - app.js.map — мапа для дебагу
2953 | 
2954 | - В браузері можна ставити breakpoints у app.ts, а не у JS.
2955 | 
2956 | #### Робота з інструментами
2957 | 
2958 | - **Chrome DevTools / Firefox Debugger** — автоматично підхоплюють .map.
2959 | 
2960 | - **Webpack / Vite** — інтегрують TS source maps у bundle для фронтенду.
2961 | 
2962 | - **Node.js** (з ts-node або source-map-support) — дебаг TS на сервері.
2963 | 
2964 | #### Корисні параметри
2965 | 
2966 | `inlineSourceMap: true` — вставляє карту прямо в JS файл.
2967 | 
2968 | `inlineSources: true` — вставляє оригінальний TS-код у .map.
2969 | 
2970 | ```json
2971 | {
2972 |   "compilerOptions": {
2973 |     "inlineSourceMap": true,
2974 |     "inlineSources": true
2975 |   }
2976 | }
2977 | ```
2978 | 
2979 | #### Підсумок:
2980 | 
2981 | Source maps у TypeScript дозволяють дебагувати оригінальний код після
2982 | компіляції, зберігаючи зв’язок між TS та JS.
2983 | 
2984 | </details>
2985 | 
2986 | <details>
2987 | <summary>57. Що таке поступова (incremental) збірка в TypeScript і як вона працює?</summary>
2988 | 
2989 | #### TypeScript
2990 | 
2991 | #### Визначення
2992 | 
2993 | **Поступова збірка (Incremental build)** — це режим компілятора TypeScript, який
2994 | дозволяє компілювати тільки ті файли, які змінилися, замість повної
2995 | перекомпіляції всього проєкту.
2996 | 
2997 | - Зменшує час збірки великих проєктів.
2998 | 
2999 | - Зберігає інформацію про попередню збірку у файлі .tsbuildinfo.
3000 | 
3001 | #### Увімкнення у tsconfig.json
3002 | 
3003 | ```json
3004 | {
3005 |   "compilerOptions": {
3006 |     "incremental": true,
3007 |     "outDir": "./dist"
3008 |   }
3009 | }
3010 | ```
3011 | 
3012 | - При першій компіляції створюється tsconfig.tsbuildinfo.
3013 | 
3014 | - При наступних компіляціях TS перевіряє, які файли змінилися, і компілює лише
3015 |   їх.
3016 | 
3017 | #### Приклад
3018 | 
3019 | 1. Проєкт з 1000 файлів.
3020 | 
3021 | 2. Змінено тільки 2 файли.
3022 | 
3023 | 3. При incremental: true компілятор згенерує JS тільки для цих 2 файлів і
3024 |    оновить .tsbuildinfo.
3025 | 
3026 | #### Додаткові параметри
3027 | 
3028 | - `composite: true` — потрібен для проєктів з references (Project References).
3029 | 
3030 | - `tsBuildInfoFile` — можна задати власне ім’я та шлях для .tsbuildinfo.
3031 | 
3032 | ```json
3033 | {
3034 |   "compilerOptions": {
3035 |     "incremental": true,
3036 |     "tsBuildInfoFile": "./.cache/tsbuildinfo"
3037 |   }
3038 | }
3039 | ```
3040 | 
3041 | #### Переваги
3042 | 
3043 | - Значне скорочення часу компіляції на великих проєктах.
3044 | 
3045 | - Сумісність із Project References для багатомодульних систем.
3046 | 
3047 | - Підтримка у CLI (tsc --build) та IDE.
3048 | 
3049 | #### Підсумок:
3050 | 
3051 | Поступова збірка дозволяє компілювати лише змінені файли, прискорюючи процес
3052 | розробки та інтеграцію з багатомодульними проєктами.
3053 | 
3054 | </details>
3055 | 
3056 | <details>
3057 | <summary>58. Що робить параметр компілятора noImplicitAny у TypeScript і як він працює?</summary>
3058 | 
3059 | #### TypeScript
3060 | 
3061 | #### Визначення
3062 | 
3063 | `noImplicitAny` — це параметр компілятора, який забороняє TypeScript автоматично
3064 | підставляти тип any там, де він не вказаний явно.
3065 | 
3066 | - Якщо компілятор не може вивести тип і немає явного типу, він видає помилку.
3067 | 
3068 | - Це допомагає робити код більш типізованим і безпечним.
3069 | 
3070 | #### Увімкнення у tsconfig.json
3071 | 
3072 | ```json
3073 | {
3074 |   "compilerOptions": {
3075 |     "noImplicitAny": true
3076 |   }
3077 | }
3078 | ```
3079 | 
3080 | #### Приклад 1. Без noImplicitAny
3081 | 
3082 | ```TypeScript
3083 | function add(a, b) {
3084 |   return a + b;
3085 | }
3086 | ```
3087 | 
3088 | - `a` та `b` автоматично отримують тип `any`.
3089 | 
3090 | - TypeScript не видає помилку, але типізація відсутня.
3091 | 
3092 | #### Приклад 2. З noImplicitAny: true
3093 | 
3094 | ```TypeScript
3095 | function add(a, b) {
3096 |   return a + b;
3097 | }
3098 | 
3099 | // ❌ Помилка: Parameter 'a' implicitly has an 'any' type
3100 | ```
3101 | 
3102 | - Тепер потрібно явно вказати типи:
3103 | 
3104 | ```TypeScript
3105 | function add(a: number, b: number): number {
3106 |   return a + b;
3107 | }
3108 | ```
3109 | 
3110 | #### Приклад 3. Аргументи callback
3111 | 
3112 | ```TypeScript
3113 | [1, 2, 3].map((x) => x * 2); // Без помилки, тип виведено
3114 | ```
3115 | 
3116 | - Тут TypeScript може вивести тип (number), тому помилка не з’являється.
3117 | 
3118 | #### Підсумок
3119 | 
3120 | - noImplicitAny: true = сувора політика типів.
3121 | 
3122 | - Запобігає неявному any, роблячи код більш безпечним.
3123 | 
3124 | - Рекомендується завжди увімкати у проєктах, особливо для великих команд.
3125 | 
3126 | </details>
3127 | 
3128 | <details>
3129 | <summary>59. Як увімкнути суворі перевірки на null та undefined у TypeScript?</summary>
3130 | 
3131 | #### TypeScript
3132 | 
3133 | #### Визначення
3134 | 
3135 | **Сувора перевірка** на `null` і `undefined` допомагає уникати помилок типу
3136 | `Cannot read property of undefined`.
3137 | 
3138 | - Параметр strictNullChecks змушує TypeScript розрізняти типи null та undefined
3139 |   від інших типів.
3140 | 
3141 | - Без нього всі типи за замовчуванням можуть бути null/undefined.
3142 | 
3143 | #### Увімкнення у tsconfig.json
3144 | 
3145 | ```json
3146 | {
3147 |   "compilerOptions": {
3148 |     "strictNullChecks": true
3149 |   }
3150 | }
3151 | ```
3152 | 
3153 | - Альтернатива: увімкнути весь "strict": true — включає strictNullChecks та інші
3154 |   суворі опції.
3155 | 
3156 | #### Приклад
3157 | 
3158 | ```TypeScript
3159 | let name: string = "Viktor";
3160 | name = null; // ❌ Помилка: Type 'null' is not assignable to type 'string'
3161 | 
3162 | let age: number | null = null; // ✅ Допустимо
3163 | ```
3164 | 
3165 | #### Використання в функціях
3166 | 
3167 | ```TypeScript
3168 | function greet(name: string | null) {
3169 |   if (name !== null) {
3170 |     console.log("Hello " + name);
3171 |   }
3172 | }
3173 | 
3174 | greet(null); // Коректно
3175 | greet("Alice"); // Коректно
3176 | ```
3177 | 
3178 | - Тепер TypeScript змушує обробляти можливий null, знижуючи ризик
3179 |   runtime-помилок.
3180 | 
3181 | #### Підсумок
3182 | 
3183 | - strictNullChecks: true → сувора перевірка null/undefined.
3184 | 
3185 | - Рекомендується для безпечнішого і передбачуваного коду.
3186 | 
3187 | - Часто використовується разом із "strict": true для максимальної суворості.
3188 | 
3189 | </details>
3190 | 
3191 | ### Типізація та пакети у TypeScript
3192 | 
3193 | <details>
3194 | <summary>60. Як у TypeScript керувати визначеннями типів (.d.ts) для сторонніх бібліотек?</summary>
3195 | 
3196 | #### TypeScript
3197 | 
3198 | 1. **Бібліотека має власні типи**
3199 | 
3200 | - Деякі пакети вже містять `.d.ts` у собі (наприклад, `axios`, `react`).
3201 | 
3202 | ```TypeScript
3203 | import axios from "axios";
3204 | 
3205 | axios.get<string>("https://api.test"); // працює, бо типи вбудовані
3206 | ```
3207 | 
3208 | 2. **Використання DefinitelyTyped**
3209 | 
3210 | - Якщо типів немає в пакеті → інсталюємо окремо:
3211 | 
3212 | ```bash
3213 | npm install --save-dev @types/lodash
3214 | ```
3215 | 
3216 | - Після цього TS автоматично підхоплює типи.
3217 | 
3218 | 3. **Створення власних визначень**
3219 | 
3220 | Якщо немає офіційних або community-типів:
3221 | 
3222 | - Створюємо файл `*.d.ts`, наприклад `custom.d.ts`:
3223 | 
3224 | ```TypeScript
3225 | declare module "legacy-lib" {
3226 |   export function doSomething(input: string): number;
3227 | }
3228 | ```
3229 | 
3230 | - Тепер можна імпортувати:
3231 | 
3232 | ```TypeScript
3233 | import { doSomething } from "legacy-lib";
3234 | ```
3235 | 
3236 | 4. **Тип any як fallback**
3237 | 
3238 | Якщо типи зовсім невідомі:
3239 | 
3240 | ```TypeScript
3241 | declare module "unknown-lib";
3242 | ```
3243 | 
3244 | - Усі імпорти з цього модуля будуть типу any.
3245 | 
3246 | - Це останній варіант, коли немає часу писати типи.
3247 | 
3248 | 5. **Конфігурація пошуку типів**
3249 | 
3250 | У `tsconfig.json` можна вказати, де брати типи:
3251 | 
3252 | ```json
3253 | {
3254 |   "compilerOptions": {
3255 |     "typeRoots": ["./types", "./node_modules/@types"]
3256 |   }
3257 | }
3258 | ```
3259 | 
3260 | `typeRoots` → де шукати визначення.
3261 | 
3262 | `types` → обмежити список типів, які підключаються.
3263 | 
3264 | #### Підсумок
3265 | 
3266 | - Використовуємо вбудовані типи пакета.
3267 | 
3268 | - Якщо їх немає → ставимо `@types/…`.
3269 | 
3270 | - Якщо і там немає → пишемо власні `.d.ts`.
3271 | 
3272 | - Як fallback → `any`.
3273 | 
3274 | </details>
3275 | 
3276 | <details>
3277 | <summary>61. Що таке DefinitelyTyped і яке його відношення до TypeScript?</summary>
3278 | 
3279 | #### TypeScript
3280 | 
3281 | #### Визначення
3282 | 
3283 | **DefinitelyTyped** — це великий open-source репозиторій GitHub, у якому
3284 | зберігаються файли визначень типів (`.d.ts`) для сторонніх JavaScript-бібліотек,
3285 | які самі по собі не містять типів.
3286 | 
3287 | - URL: https://github.com/DefinitelyTyped/DefinitelyTyped
3288 | 
3289 | - Публікується у вигляді npm-пакетів у просторі імен `@types`.
3290 | 
3291 | #### Як це працює
3292 | 
3293 | 1. Хтось пише бібліотеку на JS без TypeScript.
3294 | 
3295 | 2. Спільнота додає до DefinitelyTyped файл `index.d.ts`, який описує API цієї
3296 |    бібліотеки.
3297 | 
3298 | 3. Ви встановлюєте типи через npm:
3299 | 
3300 | ```bash
3301 | npm install --save-dev @types/lodash
3302 | ```
3303 | 
3304 | 4. TypeScript автоматично знаходить типи й дозволяє безпечно працювати з
3305 |    бібліотекою:
3306 | 
3307 | ```TypeScript
3308 | import _ from "lodash";
3309 | 
3310 | const nums: number[] = [1, 2, 3];
3311 | const doubled = _.map(nums, x => x * 2); // ✅ коректні типи
3312 | ```
3313 | 
3314 | #### Взаємозв’язок з TypeScript
3315 | 
3316 | - TypeScript не постачається з типами для всіх JS-бібліотек.
3317 | 
3318 | - DefinitelyTyped заповнює цю прогалину → робить будь-яку популярну
3319 |   JS-бібліотеку "типобезпечною".
3320 | 
3321 | - Визначення типів автоматично інтегруються з TS без додаткових налаштувань.
3322 | 
3323 | #### Підсумок
3324 | 
3325 | - `DefinitelyTyped` = репозиторій типів для JS-бібліотек.
3326 | 
3327 | - Публікується як пакети `@types/*`.
3328 | 
3329 | - Дозволяє використовувати бібліотеки без вбудованих типів у TypeScript із
3330 |   повноцінною підтримкою IntelliSense і перевіркою типів.
3331 | 
3332 | </details>
3333 | 
3334 | <details>
3335 | <summary>62. Як у TypeScript використовувати файли типів (@types) з npm?</summary>
3336 | 
3337 | #### TypeScript
3338 | 
3339 | 1. Якщо бібліотека має вбудовані типи
3340 | 
3341 | Багато сучасних пакетів (наприклад, axios, react) уже містять index.d.ts у собі.
3342 | Додатково нічого ставити не треба:
3343 | 
3344 | ```TypeScript
3345 | import axios from "axios";
3346 | 
3347 | axios.get<string>("https://api.test");
3348 | ```
3349 | 
3350 | 2. Якщо бібліотека не має типів
3351 | 
3352 | Тоді шукаємо їх у npm-namespace @types:
3353 | 
3354 | ```bash
3355 | npm install --save-dev @types/lodash
3356 | ```
3357 | 
3358 | Тепер у коді:
3359 | 
3360 | ```TypeScript
3361 | import _ from "lodash";
3362 | 
3363 | const result = _.chunk([1,2,3,4], 2); // тип: number[][]
3364 | ```
3365 | 
3366 | 3. Якщо немає готових типів у @types
3367 | 
3368 | Створюємо власний файл декларацій, наприклад src/types/custom-lib.d.ts:
3369 | 
3370 | ```TypeScript
3371 | declare module "custom-lib" {
3372 |   export function doSomething(x: string): number;
3373 | }
3374 | ```
3375 | 
3376 | TypeScript автоматично підхопить ці типи (якщо шлях входить у typeRoots або в
3377 | include у tsconfig.json).
3378 | 
3379 | 4. Керування типами через tsconfig.json
3380 | 
3381 | За замовчуванням TS підтягує всі типи з node_modules/@types.
3382 | 
3383 | Можна обмежити:
3384 | 
3385 | ```json
3386 | {
3387 |   "compilerOptions": {
3388 |     "types": ["node", "jest"]
3389 |   }
3390 | }
3391 | ```
3392 | 
3393 | → тоді інші типи ігноруються.
3394 | 
3395 | #### Підсумок
3396 | 
3397 | - Вбудовані типи → просто імпортуємо.
3398 | 
3399 | - Через @types → ставимо npm install @types/....
3400 | 
3401 | - Власні типи → створюємо .d.ts.
3402 | 
3403 | - Контроль підключення → через tsconfig.json.
3404 | 
3405 | </details>
3406 | 
3407 | ### Інтеграція TypeScript з фреймворками
3408 | 
3409 | <details>
3410 | <summary>63. Як інтегрувати TypeScript у проєкт Angular?</summary>
3411 | 
3412 | #### TypeScript
3413 | 
3414 | #### Відповідь
3415 | 
3416 | 1. Angular побудований поверх TypeScript
3417 | 
3418 | - Починаючи з Angular 2+, офіційний фреймворк завжди працює з TS як основною
3419 |   мовою.
3420 | 
3421 | - Angular CLI автоматично генерує tsconfig.json з оптимальними параметрами.
3422 | 
3423 | 2. Створення проєкту
3424 | 
3425 | ```bash
3426 | npm install -g @angular/cli
3427 | ng new my-app
3428 | ```
3429 | 
3430 | → CLI налаштує TypeScript, компіляцію та структуру файлів.
3431 | 
3432 | 3. Конфігурація TypeScript
3433 | 
3434 | У корені буде `tsconfig.json`, наприклад:
3435 | 
3436 | ```json
3437 | {
3438 |   "compilerOptions": {
3439 |     "target": "ES2022",
3440 |     "module": "ESNext",
3441 |     "strict": true,
3442 |     "experimentalDecorators": true,
3443 |     "emitDecoratorMetadata": true
3444 |   }
3445 | }
3446 | ```
3447 | 
3448 | - `experimentalDecorators` + `emitDecoratorMetadata` → потрібні для декораторів
3449 |   Angular (`@Component`, `@Injectable` тощо).
3450 | 
3451 | 4. Використання TypeScript у коді Angular
3452 | 
3453 | - Класи компонентів і сервісів пишуться на TS:
3454 | 
3455 | ```TypeScript
3456 | import { Component } from '@angular/core';
3457 | 
3458 | @Component({
3459 |   selector: 'app-root',
3460 |   templateUrl: './app.component.html'
3461 | })
3462 | export class AppComponent {
3463 |   title: string = 'My Angular App';
3464 | }
3465 | ```
3466 | 
3467 | - Використовуються інтерфейси, дженерики, enum’и для моделей даних.
3468 | 
3469 | 5. Типізація сервісів і HTTP-запитів
3470 | 
3471 | ```TypeScript
3472 | getUsers(): Observable<User[]> {
3473 |   return this.http.get<User[]>('/api/users');
3474 | }
3475 | ```
3476 | 
3477 | #### Підсумок
3478 | 
3479 | - Angular = нативна інтеграція з TypeScript.
3480 | 
3481 | - Angular CLI автоматично налаштовує TS.
3482 | 
3483 | - TS використовується у компонентах, сервісах, DI, шаблонній перевірці.
3484 | 
3485 | - Основні параметри: strict, experimentalDecorators, emitDecoratorMetadata.
3486 | 
3487 | </details>
3488 | 
3489 | <details>
3490 | <summary>64. Як інтегрувати TypeScript у React-проєкт?</summary>
3491 | 
3492 | #### TypeScript
3493 | 
3494 | #### Відповідь
3495 | 
3496 | 1. Створення проєкту з TypeScript
3497 | 
3498 | - Використати Next.js:
3499 | 
3500 | ```bash
3501 | npx create-next-app@latest
3502 | ```
3503 | 
3504 | - Або Vite:
3505 | 
3506 | ```bash
3507 | npm create vite@latest my-app -- --template react-ts
3508 | ```
3509 | 
3510 | 2. Конфігурація `tsconfig.json `
3511 | 
3512 | Приклад базових налаштувань:
3513 | 
3514 | ```json
3515 | {
3516 |   "compilerOptions": {
3517 |     "target": "ES2022",
3518 |     "module": "ESNext",
3519 |     "jsx": "react-jsx",
3520 |     "strict": true,
3521 |     "esModuleInterop": true,
3522 |     "skipLibCheck": true
3523 |   }
3524 | }
3525 | ```
3526 | 
3527 | 3. Типізація компонентів
3528 | 
3529 | - Функціональний компонент:
3530 | 
3531 | ```TypeScript
3532 | type Props = { title: string; count?: number };
3533 | 
3534 | const Header: React.FC<Props> = ({ title, count }) => (
3535 |   <h1>{title} {count}</h1>
3536 | );
3537 | ```
3538 | 
3539 | - З children:
3540 | 
3541 | ```TypeScript
3542 | type Props = { children: React.ReactNode };
3543 | 
3544 | const Layout = ({ children }: Props) => <div>{children}</div>;
3545 | ```
3546 | 
3547 | 4. Хуки з дженериками
3548 | 
3549 | ```TypeScript
3550 | const [items, setItems] = useState<string[]>([]);
3551 | const ref = useRef<HTMLInputElement>(null);
3552 | ```
3553 | 
3554 | 5. Типізація подій
3555 | 
3556 | ```TypeScript
3557 | const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
3558 |   console.log(e.target.value);
3559 | };
3560 | ```
3561 | 
3562 | 6. Типи для API / props drilling
3563 | 
3564 | Використовуються інтерфейси та типи для моделей даних:
3565 | 
3566 | ```TypeScript
3567 | interface User {
3568 |   id: number;
3569 |   name: string;
3570 | }
3571 | 
3572 | const UserCard = ({ user }: { user: User }) => <p>{user.name}</p>;
3573 | ```
3574 | 
3575 | #### Підсумок
3576 | 
3577 | - React інтегрується з TS через шаблони Next.js або Vite.
3578 | 
3579 | - `tsconfig.json` має `jsx: react-jsx`.
3580 | 
3581 | - Компоненти, хуки та події типізуються через інтерфейси, дженерики та утиліти
3582 |   React (`React.FC`, `React.ReactNode`).
3583 | 
3584 | - Це підвищує безпеку коду та зручність роботи з пропсами й стейтом.
3585 | 
3586 | </details>
3587 | 
3588 | <details>
3589 | <summary>65. Як інтегрувати TypeScript у Vue.js-проєкт?</summary>
3590 | 
3591 | #### TypeScript
3592 | 
3593 | 1. Створення Vue + TypeScript проєкту
3594 | 
3595 | Зараз офіційний спосіб — Vite + Vue CLI (create-vue):
3596 | 
3597 | ```bash
3598 | npm create vue@latest
3599 | ```
3600 | 
3601 | Під час створення проєкту обираєте Add TypeScript? -> Yes.
3602 | 
3603 | 2. Використання `.vue` з TypeScript
3604 | 
3605 | У Vue 3 <script setup> підтримує TypeScript напряму:
3606 | 
3607 | ```TypeScript
3608 | <script setup lang="ts">
3609 | import { ref } from "vue"
3610 | 
3611 | const count = ref<number>(0)
3612 | 
3613 | function increment(step: number): void {
3614 |   count.value += step
3615 | }
3616 | </script>
3617 | 
3618 | <template>
3619 |   <button @click="increment(1)">
3620 |     Count: {{ count }}
3621 |   </button>
3622 | </template>
3623 | ```
3624 | 
3625 | 3. Типізація пропсів і емісій
3626 | 
3627 | ```TypeScript
3628 | <script setup lang="ts">
3629 | interface Props {
3630 |   msg: string
3631 | }
3632 | const props = defineProps<Props>()
3633 | 
3634 | const emit = defineEmits<{
3635 |   (e: "update", value: number): void
3636 | }>()
3637 | </script>
3638 | ```
3639 | 
3640 | 4. Типи для композиційного API
3641 | 
3642 | ```TypeScript
3643 | import { Ref } from "vue"
3644 | 
3645 | function useCounter(initial: number): { count: Ref<number>, inc: () => void } {
3646 |   const count = ref(initial)
3647 |   const inc = () => count.value++
3648 |   return { count, inc }
3649 | }
3650 | ```
3651 | 
3652 | 5. Конфігурація `tsconfig.json`
3653 | 
3654 | Важливі опції:
3655 | 
3656 | ```json
3657 | {
3658 |   "compilerOptions": {
3659 |     "strict": true,
3660 |     "module": "ESNext",
3661 |     "target": "ESNext",
3662 |     "moduleResolution": "Node",
3663 |     "jsx": "preserve",
3664 |     "allowJs": false,
3665 |     "types": ["vite/client"]
3666 |   }
3667 | }
3668 | ```
3669 | 
3670 | 6. Додаткові пакети
3671 | 
3672 | - `vue-tsc` — статична перевірка .vue файлів
3673 | 
3674 | - `@vue/runtime-core` — типи Vue API
3675 | 
3676 | - `volar` (IDE extension) — краща інтеграція TS у Vue
3677 | 
3678 | У Vue 2 можна було додавати TypeScript через `vue-class-component`, але зараз
3679 | рекомендується Vue 3 + `<script setup lang="ts">` — це найпростіший і нативний
3680 | варіант.
3681 | 
3682 | </details>
3683 | 
3684 | <details>
3685 | <summary>66. Як використовувати TypeScript у Node.js-додатках?</summary>
3686 | 
3687 | #### TypeScript
3688 | 
3689 | 1. Ініціалізація проєкту
3690 | 
3691 | ```bash
3692 | mkdir my-node-ts-app && cd my-node-ts-app
3693 | npm init -y
3694 | npm install typescript ts-node @types/node --save-dev
3695 | npx tsc --init
3696 | ```
3697 | 
3698 | У tsconfig.json для Node.js найчастіше:
3699 | 
3700 | ```json
3701 | {
3702 |   "compilerOptions": {
3703 |     "target": "ES2020",
3704 |     "module": "CommonJS", // або "ESNext" для ESM
3705 |     "moduleResolution": "node",
3706 |     "outDir": "./dist",
3707 |     "rootDir": "./src",
3708 |     "strict": true,
3709 |     "esModuleInterop": true,
3710 |     "skipLibCheck": true
3711 |   }
3712 | }
3713 | ```
3714 | 
3715 | 2. Структура проєкту
3716 | 
3717 | ```
3718 | src/
3719 |  ├─ index.ts
3720 |  └─ utils.ts
3721 | ```
3722 | 
3723 | 3. Приклад коду з типами
3724 | 
3725 | ```TypeScript
3726 | // src/index.ts
3727 | import { readFileSync } from "fs"
3728 | 
3729 | function readConfig(path: string): Record<string, unknown> {
3730 |   const content = readFileSync(path, "utf-8")
3731 |   return JSON.parse(content)
3732 | }
3733 | 
3734 | console.log(readConfig("./config.json"))
3735 | ```
3736 | 
3737 | 4. Запуск
3738 | 
3739 | Прямо через ts-node (зручно для девелопменту):
3740 | 
3741 | ```bash
3742 | npx ts-node src/index.ts
3743 | ```
3744 | 
3745 | З компіляцією в JS (продакшн):
3746 | 
3747 | ```bash
3748 | npx tsc
3749 | node dist/index.js
3750 | ```
3751 | 
3752 | 5. Використання з Express
3753 | 
3754 | ```bash
3755 | npm install express
3756 | npm install @types/express --save-dev
3757 | ```
3758 | 
3759 | ```TypeScript
3760 | import express, { Request, Response } from "express"
3761 | 
3762 | const app = express()
3763 | 
3764 | app.get("/", (req: Request, res: Response) => {
3765 |   res.send("Hello, TS + Node.js")
3766 | })
3767 | 
3768 | app.listen(3000, () => console.log("Server running"))
3769 | ```
3770 | 
3771 | 6. Переваги TypeScript у Node.js
3772 | 
3773 | - Безпечні типи для API (Express, FS, DB).
3774 | 
3775 | - Зручні автопідказки в IDE.
3776 | 
3777 | - Краща підтримка великих кодових баз.
3778 | 
3779 | - Легше уникати runtime-помилок.
3780 | 
3781 | </details>
3782 | 
3783 | ### Інструменти та екосистема TypeScript
3784 | 
3785 | <details>
3786 | <summary>67. Які переваги використання статичного аналізатора коду (TSLint або ESLint з TypeScript-плагіном)?</summary>
3787 | 
3788 | #### TypeScript
3789 | 
3790 | **Переваги:**
3791 | 
3792 | 1. Єдиний кодстайл — забезпечує консистентність у команді (наприклад, лапки ' vs
3793 |    ").
3794 | 
3795 | 2. Раннє виявлення помилок — ловить некоректні конструкції ще до запуску
3796 |    (невикористані змінні, неправильні імпорти).
3797 | 
3798 | 3. Краща читабельність — автоматичне форматування та правила полегшують
3799 |    підтримку коду.
3800 | 
3801 | 4. Інтеграція з IDE/CI — помилки видно під час розробки, а також можна блокувати
3802 |    комміти/білди з помилками.
3803 | 
3804 | 5. Безпека — правила допомагають уникати небезпечних практик (наприклад, any або
3805 |    eval).
3806 | 
3807 | 6. Автоматичні виправлення — більшість проблем виправляється командою eslint
3808 |    --fix.
3809 | 
3810 | ⚠️ TSLint офіційно deprecated (з 2019), рекомендовано використовувати ESLint +
3811 | @typescript-eslint/parser.
3812 | 
3813 | </details>
3814 | 
3815 | <details>
3816 | <summary>68. Як налаштувати збірку проєкту на TypeScript за допомогою Webpack?</summary>
3817 | 
3818 | #### TypeScript
3819 | 
3820 | **Крок 1. Встановлення залежностей**
3821 | 
3822 | ```bash
3823 | npm install --save-dev webpack webpack-cli webpack-dev-server \
3824 |   typescript ts-loader source-map-loader \
3825 |   html-webpack-plugin clean-webpack-plugin
3826 | ```
3827 | 
3828 | **Крок 2. Ініціалізація TypeScript**
3829 | 
3830 | ```bash
3831 | npx tsc --init
3832 | ```
3833 | 
3834 | У `tsconfig.json` важливо:
3835 | 
3836 | ```json
3837 | {
3838 |   "compilerOptions": {
3839 |     "target": "ES6",
3840 |     "module": "ESNext",
3841 |     "moduleResolution": "node",
3842 |     "outDir": "./dist",
3843 |     "sourceMap": true,
3844 |     "strict": true,
3845 |     "esModuleInterop": true
3846 |   },
3847 |   "include": ["src"]
3848 | }
3849 | ```
3850 | 
3851 | **Крок 3. Структура проєкту**
3852 | 
3853 | ```
3854 | project/
3855 |  ├─ src/
3856 |  │   └─ index.ts
3857 |  ├─ dist/
3858 |  ├─ tsconfig.json
3859 |  └─ webpack.config.js
3860 | ```
3861 | 
3862 | **Крок 4. Налаштування Webpack**
3863 | 
3864 | ```JavaScript
3865 | // webpack.config.js
3866 | const path = require("path");
3867 | const HtmlWebpackPlugin = require("html-webpack-plugin");
3868 | const { CleanWebpackPlugin } = require("clean-webpack-plugin");
3869 | 
3870 | module.exports = {
3871 |   entry: "./src/index.ts",
3872 |   module: {
3873 |     rules: [
3874 |       {
3875 |         test: /\.ts$/,
3876 |         use: "ts-loader",
3877 |         exclude: /node_modules/,
3878 |       },
3879 |       {
3880 |         enforce: "pre",
3881 |         test: /\.js$/,
3882 |         loader: "source-map-loader",
3883 |       },
3884 |     ],
3885 |   },
3886 |   resolve: {
3887 |     extensions: [".ts", ".js"],
3888 |   },
3889 |   output: {
3890 |     filename: "bundle.js",
3891 |     path: path.resolve(__dirname, "dist"),
3892 |   },
3893 |   devtool: "source-map",
3894 |   plugins: [
3895 |     new CleanWebpackPlugin(),
3896 |     new HtmlWebpackPlugin({
3897 |       template: "src/index.html",
3898 |     }),
3899 |   ],
3900 |   devServer: {
3901 |     static: "./dist",
3902 |     hot: true,
3903 |     port: 3000,
3904 |   },
3905 | };
3906 | ```
3907 | 
3908 | **Крок 5. Сценарії npm**
3909 | 
3910 | ```json
3911 | "scripts": {
3912 |   "build": "webpack --mode production",
3913 |   "start": "webpack serve --mode development"
3914 | }
3915 | ```
3916 | 
3917 | **В результаті:**
3918 | 
3919 | - `npm start` запускає dev-server з TypeScript і hot reload.
3920 | 
3921 | - `npm run build` створює оптимізований бандл у dist/.
3922 | 
3923 | </details>
3924 | 
3925 | <details>
3926 | <summary>69. Як інтегрувати TypeScript з Babel і в чому різниця від використання tsc?</summary>
3927 | 
3928 | #### TypeScript
3929 | 
3930 | #### Принцип роботи
3931 | 
3932 | - TypeScript Compiler (tsc): компілює TS → JS і перевіряє типи.
3933 | 
3934 | - Babel: трансформує TS-синтаксис → JS, але ігнорує типи (типи видаляються на
3935 |   етапі компіляції).
3936 | 
3937 | **Тобто:**
3938 | 
3939 | - Якщо потрібна лише підтримка синтаксису (наприклад, у React), достатньо Babel.
3940 | 
3941 | - Якщо потрібна перевірка типів, треба додатково запускати tsc --noEmit або
3942 |   використовувати fork-ts-checker-webpack-plugin.
3943 | 
3944 | #### Налаштування Babel з TypeScript
3945 | 
3946 | 1. Залежності
3947 | 
3948 | ```bash
3949 | npm install --save-dev @babel/core @babel/preset-env @babel/preset-typescript \
3950 |   @babel/preset-react
3951 | ```
3952 | 
3953 | 2. `.babelrc`
3954 | 
3955 | ```json
3956 | {
3957 |   "presets": [
3958 |     "@babel/preset-env",
3959 |     "@babel/preset-react",
3960 |     "@babel/preset-typescript"
3961 |   ]
3962 | }
3963 | ```
3964 | 
3965 | 3. `package.json` scripts
3966 | 
3967 | ```json
3968 | "scripts": {
3969 |   "build": "babel src --extensions \".ts,.tsx\" --out-dir dist",
3970 |   "type-check": "tsc --noEmit"
3971 | }
3972 | ```
3973 | 
3974 | #### Коли вибирати Babel?
3975 | 
3976 | - Проєкт на React з сучасними фічами, які Babel трансформує краще за tsc.
3977 | 
3978 | - Потрібна інтеграція з Webpack/Rollup/Vite.
3979 | 
3980 | - Хочеш швидшу збірку (Babel швидший, але без type-check).
3981 | 
3982 | #### Коли вибирати tsc?
3983 | 
3984 | - Якщо потрібен чистий TS-проєкт без зайвих тулів.
3985 | 
3986 | - Якщо важлива строга перевірка типів у компіляції.
3987 | 
3988 | #### На практиці часто використовують гібридний підхід:
3989 | 
3990 | - Babel робить трансформацію коду.
3991 | 
3992 | - tsc --noEmit або fork-ts-checker-webpack-plugin робить перевірку типів.
3993 | 
3994 | </details>
3995 | 
3996 | <details>
3997 | <summary>70. Як TypeScript інтегрується з Visual Studio Code та іншими IDE?</summary>
3998 | 
3999 | #### TypeScript
4000 | 
4001 | #### Використання з VS Code
4002 | 
4003 | - **Вбудована підтримка:** VS Code вже має TypeScript Language Service.
4004 | 
4005 | - **Автодоповнення (IntelliSense):** пропонує методи, змінні, типи в реальному
4006 |   часі.
4007 | 
4008 | - **Навігація по коду:** Go to Definition, Peek Definition, Find References.
4009 | 
4010 | - **Перевірка типів на льоту:** IDE показує помилки ще до компіляції.
4011 | 
4012 | - **Refactoring tools:** перейменування змінних, витягування інтерфейсів, зміна
4013 |   сигнатур функцій.
4014 | 
4015 | - **Source Maps інтеграція:** зручний дебаг у браузері/Node.js.
4016 | 
4017 | - **tsconfig.json awareness:** VS Code читає конфігурацію проєкту й підлаштовує
4018 |   підсвічування.
4019 | 
4020 | #### Інші IDE (WebStorm, IntelliJ, Eclipse, Vim/Neovim)
4021 | 
4022 | - Використовують TypeScript Language Server (tsserver).
4023 | 
4024 | - Дають аналогічний набір можливостей: IntelliSense, типізація, refactor,
4025 |   linting.
4026 | 
4027 | - Перевага WebStorm/IntelliJ — вбудовані інструменти для Angular/React, але VS
4028 |   Code легший і гнучкіший через плагіни.
4029 | 
4030 | ✅ Висновок:
4031 | 
4032 | - TypeScript максимально ефективний у VS Code, бо Microsoft розробляє і сам
4033 |   TypeScript, і VS Code.
4034 | 
4035 | - У інших IDE можливості теж доступні, але VS Code зазвичай оновлюється швидше й
4036 |   краще інтегрований.
4037 | 
4038 | </details>
4039 | 
4040 | ### Найкращі практики та патерни TypeScript
4041 | 
4042 | <details>
4043 | <summary>71. Які best practices для організації коду та структурування TypeScript-застосунку?</summary>
4044 | 
4045 | #### TypeScript
4046 | 
4047 | **Основні принципи структурування**
4048 | 
4049 | 1. Використовуй tsconfig.json для централізованих налаштувань
4050 | 
4051 | - strict: true → строгі перевірки.
4052 | 
4053 | - baseUrl + paths → заміна відносних імпортів (../../../) на зрозумілі alias-и.
4054 | 
4055 | 2. Організація папок
4056 | 
4057 | ```
4058 | src/
4059 |   components/     // UI або бізнес-компоненти
4060 |   services/       // API, робота з даними
4061 |   models/         // інтерфейси та типи
4062 |   utils/          // хелпери
4063 |   hooks/          // кастомні React hooks
4064 |   config/         // налаштування
4065 |   index.ts        // точка входу
4066 | ```
4067 | 
4068 | - Кожен модуль експортує лише те, що потрібно (через index.ts у папці).
4069 | 
4070 | 3. Використовуй інтерфейси/типи для контрактів
4071 | 
4072 | - interface для моделей даних та API.
4073 | 
4074 | - type для Union/Intersection.
4075 | 
4076 | 4. Сервіси й утиліти мають бути незалежні від UI
4077 | 
4078 | - Розділяй бізнес-логіку (services, models) і UI-логіку (components).
4079 | 
4080 | 5. Використовуй Barrel exports (index.ts)
4081 | 
4082 | ```TypeScript
4083 | // src/services/index.ts
4084 | export * from './authService';
4085 | export * from './userService';
4086 | ```
4087 | 
4088 | 6. Розділяй типи в окрему папку types/
4089 | 
4090 | - Добре для спільних моделей (User, Product).
4091 | 
4092 | - Використовуй @types із npm, якщо є.
4093 | 
4094 | 7. Використовуй ESLint + Prettier з правилами для TS
4095 | 
4096 | - Забезпечує єдиний стиль коду.
4097 | 
4098 | - Ловить помилки раніше компіляції.
4099 | 
4100 | 8. Type-safe API-клієнти
4101 | 
4102 | - Використовуй axios/fetch з власними типами респонсів.
4103 | 
4104 | - Винось DTO (Data Transfer Objects) окремо.
4105 | 
4106 | 9. Ніколи не вимикай строгі прапорці
4107 | 
4108 | - noImplicitAny, strictNullChecks, noUnusedLocals.
4109 | 
4110 | 10. Використовуй async/await з типами
4111 | 
4112 | - Обгортай відповіді від API у Promise<T>.
4113 | 
4114 | ✅ Висновок:
4115 | 
4116 | - Правильна структура TS-проєкту = чітке розділення шарів (UI / бізнес / дані),
4117 |   строга типізація, єдиний стиль коду, мінімізація "any".
4118 | 
4119 | </details>
4120 | 
4121 | <details>
4122 | <summary>72. Як правильно використовувати async/await у TypeScript?</summary>
4123 | 
4124 | #### TypeScript
4125 | 
4126 | **Основи**
4127 | 
4128 | - `async` → функція завжди повертає `Promise<T>`.
4129 | 
4130 | - `await` → зупиняє виконання до завершення `Promise`.
4131 | 
4132 | ```TypeScript
4133 | async function fetchUser(id: number): Promise<User> {
4134 |   const res = await fetch(`/api/users/${id}`);
4135 |   return res.json() as Promise<User>;
4136 | }
4137 | ```
4138 | 
4139 | **Обробка помилок**
4140 | 
4141 | Використовуй `try/catch`:
4142 | 
4143 | ```TypeScript
4144 | async function safeFetch(): Promise<void> {
4145 |   try {
4146 |     const data = await fetchUser(1);
4147 |     console.log(data);
4148 |   } catch (err: unknown) {
4149 |     if (err instanceof Error) {
4150 |       console.error(err.message);
4151 |     }
4152 |   }
4153 | }
4154 | ```
4155 | 
4156 | **Паралельні виклики**
4157 | 
4158 | ```TypeScript
4159 | async function loadData() {
4160 |   const [users, posts] = await Promise.all([
4161 |     fetchUsers(),
4162 |     fetchPosts()
4163 |   ]);
4164 | }
4165 | ```
4166 | 
4167 | **Типізація результатів**
4168 | 
4169 | Функція повинна мати чіткий тип повернення:
4170 | 
4171 | ```TypeScript
4172 | async function getNumber(): Promise<number> {
4173 |   return 42;
4174 | }
4175 | ```
4176 | 
4177 | ✅ Висновок:
4178 | 
4179 | - У TypeScript `async/await` = асинхронний код із чіткою типізацією результатів.
4180 | 
4181 | - Завжди використовуй `try/catch`, або обробку через `.catch()` при
4182 |   `Promise.all`.
4183 | 
4184 | </details>
4185 | 
4186 | <details>
4187 | <summary>73. Які підходи до керування станом у TypeScript-застосунках і як їх правильно типізувати?</summary>
4188 | 
4189 | #### TypeScript
4190 | 
4191 | **Локальний стан (React / Vue / Angular)**
4192 | 
4193 | - Використовуй узагальнені хуки/сервіси з чіткими типами.
4194 | 
4195 | ```TypeScript
4196 | const [count, setCount] = useState<number>(0);
4197 | ```
4198 | 
4199 | **Глобальний стан**
4200 | 
4201 | 1. **Redux Toolkit + TypeScript**
4202 | 
4203 | - Типізація RootState, AppDispatch.
4204 | 
4205 | - Використовуй createSlice, щоб уникати boilerplate.
4206 | 
4207 | ```TypeScript
4208 | interface CounterState { value: number }
4209 | const initialState: CounterState = { value: 0 };
4210 | ```
4211 | 
4212 | 2. **MobX**
4213 | 
4214 | - Класи з observable + інтерфейси.
4215 | 
4216 | - Просте зв’язування з TS через декоратори.
4217 | 
4218 | 3. **Context API (React)**
4219 | 
4220 | - Визначай інтерфейси для значень контексту.
4221 | 
4222 | ```TypeScript
4223 | interface AuthContext {
4224 |   user: User | null;
4225 |   login: (u: User) => void;
4226 | }
4227 | ```
4228 | 
4229 | **Сторонні менеджери стану**
4230 | 
4231 | - **Zustand** → легкий синтаксис + TS дружній.
4232 | 
4233 | - **Recoil** → атоми зі строгими типами.
4234 | 
4235 | - **XState** → finite-state machines з автоматичною типізацією переходів.
4236 | 
4237 | **Best Practices**
4238 | 
4239 | - Завжди визначай інтерфейси/типи стану (interface State { ... }).
4240 | 
4241 | - Використовуй enum для action type або as const для уникнення помилок у рядках.
4242 | 
4243 | - Використовуй типобезпечні селектори ((state: RootState) => state.user).
4244 | 
4245 | - Мінімізуй глобальний стан → тримай лише дані, які реально потрібні в багатьох
4246 |   місцях.
4247 | 
4248 | ✅ Висновок:
4249 | 
4250 | - TypeScript робить керування станом більш безпечним: ти отримуєш
4251 |   автодоповнення, контроль над структурою стану та уникнення runtime-помилок.
4252 | 
4253 | </details>
4254 | 
4255 | <details>
4256 | <summary>74. Які шаблони проектування найчастіше застосовують у TypeScript?</summary>
4257 | 
4258 | #### TypeScript
4259 | 
4260 | #### Створюючі (Creational)
4261 | 
4262 | 1. **Singleton** – один екземпляр класу (наприклад, конфігурація, логгер).
4263 | 
4264 | ```TypeScript
4265 | class Logger {
4266 |   private static instance: Logger;
4267 |   private constructor() {}
4268 |   static getInstance() {
4269 |     if (!Logger.instance) Logger.instance = new Logger();
4270 |     return Logger.instance;
4271 |   }
4272 | }
4273 | ```
4274 | 
4275 | 2. **Factory Method / Abstract Factory** – створення об’єктів через фабрику з
4276 |    типами.
4277 | 
4278 | #### Структурні (Structural)
4279 | 
4280 | 1. **Adapter** – адаптація інтерфейсу під інший.
4281 | 
4282 | ```TypeScript
4283 | interface Payment { pay(amount: number): void; }
4284 | class PayPal { makePayment(sum: number) { /* ... */ } }
4285 | class PayPalAdapter implements Payment {
4286 |   constructor(private paypal: PayPal) {}
4287 |   pay(amount: number) { this.paypal.makePayment(amount); }
4288 | }
4289 | ```
4290 | 
4291 | 2. **Decorator** – динамічно додає поведінку до класу.
4292 | 
4293 | 3. **Proxy** – контроль доступу або кешування.
4294 | 
4295 | #### Поведінкові (Behavioral)
4296 | 
4297 | 1. **Observer** – підписка/відписка (події, реактивність).
4298 | 
4299 | ```TypeScript
4300 | type Listener = (data: string) => void;
4301 | class EventEmitter {
4302 |   private listeners: Listener[] = [];
4303 |   subscribe(l: Listener) { this.listeners.push(l); }
4304 |   emit(data: string) { this.listeners.forEach(l => l(data)); }
4305 | }
4306 | ```
4307 | 
4308 | 2. **Strategy** – змінюваний алгоритм (наприклад, різні способи валідації).
4309 | 
4310 | 3. **Command** – інкапсуляція дії у вигляді об’єкта.
4311 | 
4312 | 4. **Mediator** – координація взаємодії між об’єктами.
4313 | 
4314 | #### Переваги в TypeScript
4315 | 
4316 | - Інтерфейси та дженерики роблять шаблони більш строгими.
4317 | 
4318 | - Decorators (експериментальні) дозволяють реалізовувати Decorator, DI та
4319 |   Aspect-Oriented Programming.
4320 | 
4321 | - Union/Discriminated Unions часто спрощують реалізацію State чи Strategy.
4322 | 
4323 | </details>
4324 | 
4325 | <details>
4326 | <summary>75. Які основні підходи для налагодження TypeScript-застосунків?</summary>
4327 | 
4328 | #### TypeScript
4329 | 
4330 | #### Кроки для відлагодження
4331 | 
4332 | 1. Source Maps
4333 | 
4334 | - У `tsconfig.json` додати:
4335 | 
4336 | ```json
4337 | {
4338 |   "compilerOptions": {
4339 |     "sourceMap": true
4340 |   }
4341 | }
4342 | ```
4343 | 
4344 | - Це дозволяє дебагеру (Chrome DevTools, VS Code) показувати оригінальний .ts
4345 |   код замість згенерованого .js.
4346 | 
4347 | 2. Debug у VS Code
4348 | 
4349 | - Налаштувати `launch.json`:
4350 | 
4351 | ```json
4352 | {
4353 |   "version": "0.2.0",
4354 |   "configurations": [
4355 |     {
4356 |       "type": "node",
4357 |       "request": "launch",
4358 |       "name": "Debug TS",
4359 |       "program": "${workspaceFolder}/src/index.ts",
4360 |       "preLaunchTask": "tsc: build - tsconfig.json",
4361 |       "outFiles": ["${workspaceFolder}/dist/**/*.js"]
4362 |     }
4363 |   ]
4364 | }
4365 | ```
4366 | 
4367 | - Ставиш брейкпоінти прямо у TypeScript-файлах.
4368 | 
4369 | 3. Debug у браузері
4370 | 
4371 | - Використовувати `webpack` або `vite` з підтримкою source maps.
4372 | 
4373 | - Відкрити Chrome DevTools → вкладка Sources → знаходиш .ts файл → ставиш
4374 |   брейкпоінт.
4375 | 
4376 | 4. Консольні інструменти
4377 | 
4378 | - `console.log`, `console.table`, `debugger` працюють так само, але з
4379 |   відображенням через source maps.
4380 | 
4381 | 5. Node.js Debugging
4382 | 
4383 | - Запуск з Node.js:
4384 | 
4385 | ```bash
4386 | node --inspect-brk dist/index.js
4387 | ```
4388 | 
4389 | - Підключаєшся через Chrome DevTools або VS Code.
4390 | 
4391 | 6. Unit-тести з дебагом
4392 | 
4393 | - Якщо використовуєш Jest / Mocha → можна запускати з `--inspect`.
4394 | 
4395 | - Це допомагає відслідковувати помилки ще до рантайму.
4396 | 
4397 | ✅ Ключ: завжди компілюй з `sourceMap` і налагоджуй оригінальний `.ts` код, а не
4398 | згенерований `.js`.
4399 | 
4400 | </details>
4401 | 
4402 | ### Тестування та забезпечення якості в TypeScript
4403 | 
4404 | <details>
4405 | <summary>76. Як писати модульні тести для TypeScript-коду?</summary>
4406 | 
4407 | #### TypeScript
4408 | 
4409 | #### Основні кроки
4410 | 
4411 | 1. Вибір тестового фреймворку
4412 | 
4413 | - Найчастіше: Jest, Mocha + Chai, Vitest.
4414 | 
4415 | - Для фронтенду (React/Angular): зазвичай Jest.
4416 | 
4417 | 2. Налаштування TypeScript
4418 | 
4419 | - Встановлення залежностей (на прикладі Jest):
4420 | 
4421 | ```bash
4422 | npm install --save-dev jest ts-jest @types/jest
4423 | ```
4424 | 
4425 | - Ініціалізація:
4426 | 
4427 | ```bash
4428 | npx ts-jest config:init
4429 | ```
4430 | 
4431 | 3. Приклад функції (яку тестуємо):
4432 | 
4433 | ```TypeScript
4434 | // src/utils/math.ts
4435 | export function add(a: number, b: number): number {
4436 |   return a + b;
4437 | }
4438 | ```
4439 | 
4440 | 4. Приклад тесту
4441 | 
4442 | ```TypeScript
4443 | // tests/math.test.ts
4444 | import { add } from "../src/utils/math";
4445 | 
4446 | test("adds two numbers", () => {
4447 |   expect(add(2, 3)).toBe(5);
4448 | });
4449 | ```
4450 | 
4451 | 5. Запуск тестів
4452 | 
4453 | ```bash
4454 | npx jest
4455 | ```
4456 | 
4457 | 6. Типізація у тестах
4458 | 
4459 | - Використовуєш ті самі TS-типи.
4460 | 
4461 | - Якщо треба mock-и → `jest.mock` або `ts-mockito`.
4462 | 
4463 | 7. Кращі практики
4464 | 
4465 | - Тести зберігати в `__tests__/` або `*.test.ts`.
4466 | 
4467 | - Перевіряти і позитивні, і негативні кейси.
4468 | 
4469 | - Використовувати beforeEach / afterEach для підготовки оточення.
4470 | 
4471 | - Перекривати тільки те, що потрібно (не мокати все без потреби).
4472 | 
4473 | ✅ Резюме: модульні тести в TypeScript пишуться так само, як у JavaScript, але з
4474 | додатковими перевагами типізації. Найзручніше — Jest + ts-jest.
4475 | 
4476 | </details>
4477 | 
4478 | <details>
4479 | <summary>77. Які тестові фреймворки зазвичай застосовують для TypeScript-проєктів?</summary>
4480 | 
4481 | #### TypeScript
4482 | 
4483 | **Найпопулярніші**
4484 | 
4485 | 1. Jest
4486 | 
4487 | - Найпоширеніший для фронтенду та Node.js.
4488 | 
4489 | - Підтримує TypeScript через ts-jest.
4490 | 
4491 | - Вбудовані мокі, асинхронні тести, snapshot testing.
4492 | 
4493 | 2. Vitest
4494 | 
4495 | - Швидкий, сучасний, інтегрується з Vite.
4496 | 
4497 | - Підтримує TS нативно.
4498 | 
4499 | - API сумісний із Jest.
4500 | 
4501 | 3. Mocha + Chai
4502 | 
4503 | - Класичний стек для Node.js.
4504 | 
4505 | - ts-node дозволяє запускати тести на TS без компіляції.
4506 | 
4507 | - Чудово підходить для серверних застосунків.
4508 | 
4509 | 4. AVA
4510 | 
4511 | - Мінімалістичний, паралельне виконання тестів.
4512 | 
4513 | - Підтримка TS через ts-node/register.
4514 | 
4515 | 5. Jasmine
4516 | 
4517 | - Використовувався для Angular, можна писати тести на TS.
4518 | 
4519 | - Менш популярний сьогодні через Jest/Vitest.
4520 | 
4521 | </details>
4522 | 
4523 | <details>
4524 | <summary>78. Як виконувати наскрізне (E2E) тестування у TypeScript-застосунках?</summary>
4525 | 
4526 | #### TypeScript
4527 | 
4528 | #### Основні інструменти
4529 | 
4530 | 1. Cypress
4531 | 
4532 | - Дуже популярний для фронтенду.
4533 | 
4534 | - Підтримує TypeScript через tsconfig.json.
4535 | 
4536 | - Вбудований девтулс, мок-сервер, зручні API для селекторів.
4537 | 
4538 | 2. Playwright
4539 | 
4540 | - Кросбраузерне тестування (Chromium, Firefox, WebKit).
4541 | 
4542 | - TypeScript підтримується "з коробки".
4543 | 
4544 | - Можна тестувати UI, API, мобільні емуляції.
4545 | 
4546 | 3. Puppeteer
4547 | 
4548 | - Автоматизація браузера Chrome.
4549 | 
4550 | - TypeScript через npm типи (@types/puppeteer).
4551 | 
4552 | #### Налаштування TypeScript для E2E
4553 | 
4554 | 1. tsconfig.json
4555 | 
4556 | ```json
4557 | {
4558 |   "compilerOptions": {
4559 |     "target": "ES6",
4560 |     "module": "CommonJS",
4561 |     "strict": true,
4562 |     "esModuleInterop": true,
4563 |     "types": ["cypress", "node"]
4564 |   },
4565 |   "include": ["cypress/**/*.ts"]
4566 | }
4567 | ```
4568 | 
4569 | 2. Cypress приклад тесту на TS
4570 | 
4571 | ```TypeScript
4572 | describe('Login page', () => {
4573 |   it('should log in successfully', () => {
4574 |     cy.visit('/login');
4575 |     cy.get('input[name="email"]').type('user@example.com');
4576 |     cy.get('input[name="password"]').type('password123');
4577 |     cy.get('button[type="submit"]').click();
4578 |     cy.url().should('include', '/dashboard');
4579 |   });
4580 | });
4581 | ```
4582 | 
4583 | 3. Playwright приклад
4584 | 
4585 | ```TypeScript
4586 | import { test, expect } from '@playwright/test';
4587 | 
4588 | test('login test', async ({ page }) => {
4589 |   await page.goto('http://localhost:3000/login');
4590 |   await page.fill('input[name=email]', 'user@example.com');
4591 |   await page.fill('input[name=password]', 'password123');
4592 |   await page.click('button[type=submit]');
4593 |   await expect(page).toHaveURL(/dashboard/);
4594 | });
4595 | ```
4596 | 
4597 | #### Best practices
4598 | 
4599 | - Типізувати тести і селектори через інтерфейси або константи.
4600 | 
4601 | - Використовувати Page Object Model (POM) для організації коду тестів.
4602 | 
4603 | - Писати окремі тести для функціональних сценаріїв, а не перевіряти все одним
4604 |   тестом.
4605 | 
4606 | - Інтегрувати E2E у CI/CD (GitHub Actions, GitLab CI) з відловом помилок.
4607 | 
4608 | ✅ Висновок: TypeScript + E2E тести дозволяють мати типобезпечні, надійні та
4609 | підтримувані тести для UI і API.
4610 | 
4611 | - **Cypress** → швидкий для фронтенду.
4612 | 
4613 | - **Playwright** → кросбраузерна автоматизація.
4614 | 
4615 | </details>
4616 | 
4617 | ### TypeScript для бекенд-розробки
4618 | 
4619 | <details>
4620 | <summary>79. Як налаштувати і використовувати TypeScript з Express.js?</summary>
4621 | 
4622 | #### TypeScript
4623 | 
4624 | 1. Ініціалізуєш проект:
4625 | 
4626 | ```bash
4627 | npm init -y
4628 | npm install express
4629 | npm install -D typescript ts-node @types/node @types/express
4630 | ```
4631 | 
4632 | 2. Створюєш tsconfig.json (базово з npx tsc --init).
4633 | 
4634 | 3. Пишеш код у src/index.ts:
4635 | 
4636 | ```TypeScript
4637 | import express, { Request, Response } from "express";
4638 | 
4639 | const app = express();
4640 | 
4641 | app.get("/", (req: Request, res: Response) => {
4642 |   res.send("Hello TypeScript + Express!");
4643 | });
4644 | 
4645 | app.listen(3000, () => console.log("Server running on port 3000"));
4646 | ```
4647 | 
4648 | 4. Запускаєш у дев-режимі:
4649 | 
4650 | ```bash
4651 | npx ts-node src/index.ts
4652 | ```
4653 | 
4654 | 5. Для продакшена — компілюєш (npx tsc) і запускаєш node dist/index.js.
4655 | 
4656 | Цього мінімуму достатньо, щоб підняти Express-сервер на TypeScript.
4657 | 
4658 | </details>
4659 | 
4660 | <details>
4661 | <summary>80. Як створювати RESTful сервіси з використанням TypeScript?</summary>
4662 | 
4663 | #### TypeScript
4664 | 
4665 | 1. **Архітектура**
4666 | 
4667 | - Використовують Express/Koa/NestJS як HTTP-фреймворк.
4668 | 
4669 | - Розділяють шари: routes → controllers → services → repositories.
4670 | 
4671 | - Використовують DTO/інтерфейси для типобезпеки.
4672 | 
4673 | 2. **Маршрути**
4674 | 
4675 | - Описують ендпоінти (CRUD).
4676 | 
4677 | - Типізують Request, Response.
4678 | 
4679 | - Використовують middleware для аутентифікації, валідації.
4680 | 
4681 | 3. **Валідація та типізація**
4682 | 
4683 | - zod, class-validator або joi для перевірки вхідних даних.
4684 | 
4685 | - Інтерфейси/типи для моделей.
4686 | 
4687 | 4. **Документація**
4688 | 
4689 | - Swagger/OpenAPI для автогенерації документації.
4690 | 
4691 | 5. **Приклад мінімального REST-контролера (Express + TS):**
4692 | 
4693 | ```TypeScript
4694 | import { Router, Request, Response } from "express";
4695 | const router = Router();
4696 | 
4697 | interface User {
4698 |   id: number;
4699 |   name: string;
4700 | }
4701 | 
4702 | let users: User[] = [];
4703 | 
4704 | router.get("/users", (req: Request, res: Response) => {
4705 |   res.json(users);
4706 | });
4707 | 
4708 | router.post("/users", (req: Request, res: Response) => {
4709 |   const newUser: User = { id: Date.now(), ...req.body };
4710 |   users.push(newUser);
4711 |   res.status(201).json(newUser);
4712 | });
4713 | 
4714 | export default router;
4715 | ```
4716 | 
4717 | **Ключова перевага TS** — чітка типізація моделей та DTO, що знижує ризик
4718 | помилок у великих REST API.
4719 | 
4720 | </details>
4721 | 
4722 | <details>
4723 | <summary>81. Як організувати моделювання даних у бекенді на TypeScript?</summary>
4724 | 
4725 | #### TypeScript
4726 | 
4727 | 1. **Інтерфейси та типи**
4728 | 
4729 | - Використовуються для опису доменних моделей (User, Product, Order).
4730 | 
4731 | - Забезпечують статичну перевірку відповідності даних.
4732 | 
4733 | 2. **Класи / DTO**
4734 | 
4735 | - Використовуються для передачі даних між шарами (DTO: Data Transfer Object).
4736 | 
4737 | - Можуть мати валідацію (наприклад, через class-validator).
4738 | 
4739 | 3. **ORM/ODM інтеграція**
4740 | 
4741 | - З TypeScript добре працюють:
4742 | 
4743 | - TypeORM / Prisma (SQL)
4744 | 
4745 | - Mongoose (MongoDB)
4746 | 
4747 | - Вони генерують типи моделей з бази або навпаки — з TS-кодів.
4748 | 
4749 | 4. **Валідація + серіалізація**
4750 | 
4751 | - zod, yup, class-validator для перевірки схем.
4752 | 
4753 | - Це дає гарантію, що дані з клієнта відповідають моделі.
4754 | 
4755 | 5. **Приклад моделі (Prisma + TS):**
4756 | 
4757 | ```TypeScript
4758 | // schema.prisma
4759 | model User {
4760 |   id    Int     @id @default(autoincrement())
4761 |   email String  @unique
4762 |   name  String?
4763 | }
4764 | 
4765 | // user.service.ts
4766 | import { PrismaClient } from "@prisma/client";
4767 | const prisma = new PrismaClient();
4768 | 
4769 | export async function createUser(email: string, name?: string) {
4770 |   return prisma.user.create({ data: { email, name } });
4771 | }
4772 | ```
4773 | 
4774 | Основна ідея: моделі у TypeScript описують доменні сутності, поєднуються з ORM
4775 | для роботи з БД і доповнюються валідацією для захисту від некоректних даних.
4776 | 
4777 | </details>
4778 | 
4779 | <details>
4780 | <summary>82. Які підходи є для роботи з базами даних у бекенді на TypeScript і як ними керувати?</summary>
4781 | 
4782 | #### TypeScript
4783 | 
4784 | 1. **Рівні взаємодії**
4785 | 
4786 | - SQL-запити напряму → pg, mysql2, mssql драйвери. Гнучко, але більше
4787 |   boilerplate.
4788 | 
4789 | - Query builders → Knex.js, Kysely. Дає типобезпеку і менш громіздкі запити.
4790 | 
4791 | - ORM/ODM → Prisma, TypeORM, Sequelize, Mongoose (для MongoDB). Автоматично
4792 |   генерують моделі, типи, відношення.
4793 | 
4794 | 2. **Організація коду**
4795 | 
4796 | - Створюють шар repository для роботи з БД.
4797 | 
4798 | - Сервіси звертаються до репозиторіїв, а не напряму до драйвера.
4799 | 
4800 | - Використовують DTO/інтерфейси для повернення типізованих результатів.
4801 | 
4802 | 3. **Міграції та схеми**
4803 | 
4804 | - Prisma/TypeORM мають вбудовані інструменти для міграцій.
4805 | 
4806 | - Забезпечує контроль версій БД.
4807 | 
4808 | 4. **Приклад (Prisma + TS):**
4809 | 
4810 | ```TypeScript
4811 | import { PrismaClient } from "@prisma/client";
4812 | const prisma = new PrismaClient();
4813 | 
4814 | // Repository
4815 | export async function getUserById(id: number) {
4816 |   return prisma.user.findUnique({ where: { id } });
4817 | }
4818 | 
4819 | export async function createUser(email: string, name?: string) {
4820 |   return prisma.user.create({ data: { email, name } });
4821 | }
4822 | ```
4823 | 
4824 | Ключова ідея: у TypeScript завжди прагнемо до типобезпеки — тому ORM/Query
4825 | Builder + інтерфейси/DTO найкраще підходять для керованої взаємодії з БД.
4826 | 
4827 | </details>
4828 | 
4829 | <details>
4830 | <summary>83. Які стратегії автентифікації та авторизації застосовуються в TypeScript API?</summary>
4831 | 
4832 | #### TypeScript
4833 | 
4834 | 1. **Автентифікація (Authentication)**
4835 | 
4836 | - JWT (JSON Web Token) → найпоширеніший варіант. Токен зберігається в
4837 |   `Authorization: Bearer <token>`.
4838 | 
4839 | - Session + Cookies → через `express-session`, часто з Redis. Підходить для
4840 |   веб-додатків.
4841 | 
4842 | - OAuth2 / OpenID Connect → інтеграція з Google, GitHub, Microsoft.
4843 | 
4844 | - API Keys → для сервіс-ту-сервіс інтеграцій.
4845 | 
4846 | 2. **Авторизація (Authorization)**
4847 | 
4848 | - Role-based (RBAC) → ролі (`admin`, `user`, `manager`).
4849 | 
4850 | - Permission-based (PBAC) → більш гранульований контроль доступу.
4851 | 
4852 | - Attribute-based (ABAC) → правила на основі атрибутів користувача й ресурсу.
4853 | 
4854 | 3. **Практики реалізації в TypeScript API**
4855 | 
4856 | - Middleware для перевірки токенів (наприклад, `express-jwt`, `passport-jwt`).
4857 | 
4858 | - Використання DTO для типізації `req.user`.
4859 | 
4860 | - Зберігання секретів у Vault/AWS Secrets Manager, а не в коді.
4861 | 
4862 | 4. **Приклад (JWT + Express + TS):**
4863 | 
4864 | ```TypeScript
4865 | import jwt from "jsonwebtoken";
4866 | import { Request, Response, NextFunction } from "express";
4867 | 
4868 | interface JwtPayload { userId: number; role: string; }
4869 | 
4870 | export function authMiddleware(req: Request, res: Response, next: NextFunction) {
4871 |   const token = req.headers.authorization?.split(" ")[1];
4872 |   if (!token) return res.status(401).json({ error: "Unauthorized" });
4873 | 
4874 |   try {
4875 |     const payload = jwt.verify(token, process.env.JWT_SECRET!) as JwtPayload;
4876 |     (req as any).user = payload;
4877 |     next();
4878 |   } catch {
4879 |     res.status(403).json({ error: "Invalid token" });
4880 |   }
4881 | }
4882 | ```
4883 | 
4884 | Основна ідея:
4885 | 
4886 | - Authentication = підтвердити, хто користувач.
4887 | 
4888 | - Authorization = вирішити, що він може робити.
4889 | 
4890 | У TypeScript API все робиться через middleware + чітку типізацію `req.user`.
4891 | 
4892 | </details>
4893 | 
4894 | ### Просунуті практики TypeScript
4895 | 
4896 | <details>
4897 | <summary>84. Як застосовувати TypeScript у підході Domain-Driven Design (DDD)?</summary>
4898 | 
4899 | #### TypeScript
4900 | 
4901 | 1. **Основні принципи DDD у TS**
4902 | 
4903 | - Domain layer: інтерфейси, value objects, entities → чисті TS-типи та класи.
4904 | 
4905 | - Application layer: сервіси/юзкейси, які координують доменну логіку.
4906 | 
4907 | - Infrastructure layer: робота з БД, API, сторонні сервіси (реалізації
4908 |   інтерфейсів).
4909 | 
4910 | - Presentation layer: контролери/REST/GraphQL, які викликають application layer.
4911 | 
4912 | 2. **Типобезпека як перевага**
4913 | 
4914 | - Value objects описуються через класи або типи (наприклад, Email, Price).
4915 | 
4916 | - Використання readonly і private захищає інваріанти.
4917 | 
4918 | - DTO/інтерфейси забезпечують чітку межу між шарами.
4919 | 
4920 | 3. **Приклад сутності (Entity + Value Object):**
4921 | 
4922 | ```TypeScript
4923 | // Value Object
4924 | export class Email {
4925 |   private readonly value: string;
4926 |   constructor(value: string) {
4927 |     if (!/^[\w.-]+@[\w.-]+\.\w+$/.test(value)) {
4928 |       throw new Error("Invalid email format");
4929 |     }
4930 |     this.value = value;
4931 |   }
4932 |   getValue(): string {
4933 |     return this.value;
4934 |   }
4935 | }
4936 | 
4937 | // Entity
4938 | export class User {
4939 |   constructor(
4940 |     public readonly id: number,
4941 |     private _email: Email,
4942 |     private _name: string
4943 |   ) {}
4944 | 
4945 |   changeEmail(newEmail: Email) {
4946 |     this._email = newEmail;
4947 |   }
4948 | }
4949 | ```
4950 | 
4951 | 4. **Repositories**
4952 | 
4953 | - Визначаються як інтерфейси у домені:
4954 | 
4955 | ```TypeScript
4956 | export interface UserRepository {
4957 |   findById(id: number): Promise<User | null>;
4958 |   save(user: User): Promise<void>;
4959 | }
4960 | ```
4961 | 
4962 | - Реалізація у infrastructure (ORM/DB).
4963 | 
4964 | 5. **Application Services (Use Cases)**
4965 | 
4966 | - Координують бізнес-логіку без знання деталей інфраструктури.
4967 | 
4968 | Головна ідея: TypeScript дає строгу типізацію, що ідеально лягає на концепцію
4969 | DDD — чіткі доменні моделі, інваріанти, розділення відповідальностей.
4970 | 
4971 | </details>
4972 | 
4973 | <details>
4974 | <summary>85. Як реалізувати пошук подій у бекенді на TypeScript?</summary>
4975 | 
4976 | #### TypeScript
4977 | 
4978 | 1. **Моделювання сутності "Подія" (Event)**
4979 | 
4980 | - Використати інтерфейс або ORM-модель:
4981 | 
4982 | ```TypeScript
4983 | interface Event {
4984 |   id: number;
4985 |   title: string;
4986 |   date: Date;
4987 |   location: string;
4988 |   tags?: string[];
4989 | }
4990 | ```
4991 | 
4992 | 2. **Джерело даних**
4993 | 
4994 | - Якщо база SQL → Prisma/TypeORM (WHERE title ILIKE %...%).
4995 | 
4996 | - Якщо NoSQL (MongoDB) → фільтрація через find({ title: /regex/ }).
4997 | 
4998 | 3. **API-ендпоінт для пошуку**
4999 | 
5000 | ```TypeScript
5001 | import { Request, Response } from "express";
5002 | import { prisma } from "../prisma"; // приклад із Prisma
5003 | 
5004 | export async function searchEvents(req: Request, res: Response) {
5005 |   const { query, date, location } = req.query;
5006 | 
5007 |   const events = await prisma.event.findMany({
5008 |     where: {
5009 |       title: query ? { contains: String(query), mode: "insensitive" } : undefined,
5010 |       date: date ? new Date(String(date)) : undefined,
5011 |       location: location ? String(location) : undefined,
5012 |     },
5013 |   });
5014 | 
5015 |   res.json(events);
5016 | }
5017 | ```
5018 | 
5019 | 4. **Покращення пошуку**
5020 | 
5021 | - Індекси в БД (title, date).
5022 | 
5023 | - Повнотекстовий пошук (Postgres tsvector, Elasticsearch, Meilisearch).
5024 | 
5025 | - Пагінація (skip, take або LIMIT, OFFSET).
5026 | 
5027 | Основна ідея: в TypeScript пошук подій — це типізована модель + query-логіка
5028 | (ORM/DB) + REST/GraphQL endpoint.
5029 | 
5030 | </details>
5031 | 
5032 | <details>
5033 | <summary>86. Що таке ізоморфні (універсальні) додатки в контексті TypeScript і як вони працюють?</summary>
5034 | 
5035 | #### TypeScript
5036 | 
5037 | 1. **Визначення**
5038 | 
5039 | - Ізоморфний (універсальний) додаток — це застосунок, де один і той самий код
5040 |   (зазвичай написаний на TypeScript/JavaScript) виконується і на сервері, і на
5041 |   клієнті.
5042 | 
5043 | - Найчастіше йдеться про рендеринг UI: сервер віддає HTML, а клієнт "гідратує"
5044 |   його і підхоплює подальшу логіку.
5045 | 
5046 | 2. **Технологічна основа**
5047 | 
5048 | - React + TypeScript → Next.js — типовий приклад ізоморфного фреймворку.
5049 | 
5050 | - Код компонентів пишеться на TS, використовується і для SSR (server-side
5051 |   rendering), і для CSR (client-side rendering).
5052 | 
5053 | 3. **Переваги**
5054 | 
5055 | - Кращий SEO завдяки SSR.
5056 | 
5057 | - Швидший TTFB (користувач одразу бачить контент).
5058 | 
5059 | - Повторне використання типів/бізнес-логіки між фронтендом і бекендом.
5060 | 
5061 | 4. **Приклад ізоморфного підходу (Next.js + TS):**
5062 | 
5063 | ```TypeScript
5064 | // pages/index.tsx
5065 | import { GetServerSideProps } from "next";
5066 | 
5067 | interface HomeProps {
5068 |   serverTime: string;
5069 | }
5070 | 
5071 | export default function Home({ serverTime }: HomeProps) {
5072 |   return <h1>Server time: {serverTime}</h1>;
5073 | }
5074 | 
5075 | export const getServerSideProps: GetServerSideProps = async () => {
5076 |   return { props: { serverTime: new Date().toISOString() } };
5077 | };
5078 | ```
5079 | 
5080 | - Тут getServerSideProps виконується на сервері (Node.js), а компонент Home
5081 |   відмальовується на клієнті, використовуючи спільну типізацію TS.
5082 | 
5083 | Суть: ізоморфні додатки на TypeScript дозволяють мати єдину кодову базу для
5084 | бізнес-логіки, моделей і UI, що працюють як на клієнті, так і на сервері.
5085 | 
5086 | </details>
5087 | 
5088 | ### Типи TypeScript та стандарти ECMAScript
5089 | 
5090 | <details>
5091 | <summary>87. Як TypeScript підтримує та реалізує останні стандарти ECMAScript?</summary>
5092 | 
5093 | #### TypeScript
5094 | 
5095 | 1. **Суперсет JavaScript**
5096 | 
5097 | - TypeScript — це надбудова над JS, тому він підтримує всі сучасні можливості
5098 |   ECMAScript (ES6+).
5099 | 
5100 | - Ви можете писати async/await, destructuring, classes, modules, optional
5101 |   chaining, nullish coalescing тощо.
5102 | 
5103 | 2. **Компільований код**
5104 | 
5105 | - TS транслює сучасний синтаксис ES у код, сумісний з цільовою версією JS
5106 |   (target у tsconfig.json), наприклад:
5107 | 
5108 | - target: "ES5" → транскомпіляція для старих браузерів.
5109 | 
5110 | - target: "ES2022" → мінімальна трансформація, сучасні фічі залишаються.
5111 | 
5112 | 3. **Типізація та нові фічі**
5113 | 
5114 | - TypeScript додає статичну типізацію, enums, interfaces, generics, tuples —
5115 |   чого немає в ES.
5116 | 
5117 | - Нові TS-фічі часто випереджають офіційний стандарт ECMAScript, наприклад ??=,
5118 |   ??, as const.
5119 | 
5120 | 4. **Приклад сучасного коду TS/ES:**
5121 | 
5122 | ```TypeScript
5123 | interface User {
5124 |   id: number;
5125 |   name: string;
5126 | }
5127 | 
5128 | const users: User[] = [{ id: 1, name: "Alice" }];
5129 | 
5130 | const firstUserName = users[0]?.name ?? "Unknown";
5131 | console.log(firstUserName);
5132 | ```
5133 | 
5134 | - Використано optional chaining ?. і nullish coalescing ?? — обидві ES2020 фічі.
5135 | 
5136 | 5. **Висновок**
5137 | 
5138 | - TypeScript повністю сумісний з останніми стандартами ECMAScript і дає
5139 |   додаткові можливості для безпечної типізації, які не передбачені у JS.
5140 | 
5141 | </details>
5142 | 
5143 | <details>
5144 | <summary>88. Які додаткові можливості TypeScript пропонує поверх ES6+ стандартів?</summary>
5145 | 
5146 | #### TypeScript
5147 | 
5148 | 1. **Статична типізація**
5149 | 
5150 | - TypeScript вводить type, interface, enum, tuple, readonly, generics.
5151 | 
5152 | - Дозволяє перевіряти типи на етапі компіляції, чого немає в ES6.
5153 | 
5154 | 2. **Покращена робота з класами**
5155 | 
5156 | - Підтримка модифікаторів доступу: public, private, protected.
5157 | 
5158 | - abstract класи та методи.
5159 | 
5160 | - Підтримка інтерфейсів для контрактів класів.
5161 | 
5162 | 3. **Розширені конструкції функцій**
5163 | 
5164 | - Типізація параметрів і поверненого значення функцій.
5165 | 
5166 | - Optional та default параметри з типовою перевіркою.
5167 | 
5168 | 4. **Сучасний синтаксис ES6+**
5169 | 
5170 | - async/await, destructuring, spread/rest, modules, optional chaining ?.,
5171 |   nullish coalescing ??.
5172 | 
5173 | - TS повністю підтримує ці фічі і може транслювати їх під старіші таргети (ES5,
5174 |   ES2015).
5175 | 
5176 | 5. **Краща інтеграція з IDE та автодоповнення**
5177 | 
5178 | - Завдяки типізації, TS забезпечує точне IntelliSense та рефакторинг.
5179 | 
5180 | 6. **Приклад:**
5181 | 
5182 | ```TypeScript
5183 | interface User {
5184 |   id: number;
5185 |   name: string;
5186 | }
5187 | 
5188 | const users: User[] = [];
5189 | const firstUserName = users[0]?.name ?? "Unknown"; // ES2020 фічі + типізація
5190 | ```
5191 | 
5192 | Основна ідея: TypeScript додає типи, інтерфейси, generics та строгіший контроль,
5193 | зберігаючи всі сучасні фічі ES6+ і забезпечуючи сумісність із старішими
5194 | середовищами.
5195 | 
5196 | </details>
5197 | 
5198 | <details>
5199 | <summary>89. Як TypeScript підтримує та працює з асинхронними ітераторами?</summary>
5200 | 
5201 | #### TypeScript
5202 | 
5203 | 1. **Визначення**
5204 | 
5205 | - Асинхронний ітератор (AsyncIterator) дозволяє ітерувати над даними, які
5206 |   надходять асинхронно (Promise, стріми, API-виклики).
5207 | 
5208 | - Використовується разом із for await...of.
5209 | 
5210 | 2. **Типізація в TypeScript**
5211 | 
5212 | - Можна явно вказати тип елементів, що повертає асинхронний ітератор:
5213 | 
5214 | ```TypeScript
5215 | async function* fetchData(): AsyncGenerator<number> {
5216 |   for (let i = 0; i < 3; i++) {
5217 |     await new Promise(res => setTimeout(res, 100));
5218 |     yield i;
5219 |   }
5220 | }
5221 | ```
5222 | 
5223 | 3. **Використання for await...of**
5224 | 
5225 | ```TypeScript
5226 | async function main() {
5227 |   for await (const num of fetchData()) {
5228 |     console.log(num);
5229 |   }
5230 | }
5231 | main();
5232 | ```
5233 | 
5234 | - TypeScript перевіряє, що fetchData() повертає AsyncIterable<number>.
5235 | 
5236 | 4. **Сумісність з ES2018+**
5237 | 
5238 | - Асинхронні ітератори були додані в ES2018.
5239 | 
5240 | - TypeScript підтримує їх, трансформуючи для таргетів ES2018+ без додаткових
5241 |   бібліотек.
5242 | 
5243 | 5. **Переваги в TS**
5244 | 
5245 | - Статична типізація елементів ітератора.
5246 | 
5247 | - Повна інтеграція з Promise та async/await.
5248 | 
5249 | - Можливість створювати потокові дані, не блокуючи основний потік.
5250 | 
5251 | </details>
5252 | 
5253 | ### Оптимізація продуктивності TypeScript
5254 | 
5255 | <details>
5256 | <summary>90. Які стратегії оптимізації продуктивності застосовують у програмах на TypeScript?</summary>
5257 | 
5258 | #### TypeScript
5259 | 
5260 | 1. **Оптимізація на рівні TypeScript/JavaScript**
5261 | 
5262 | - Використовувати типи і інтерфейси для запобігання зайвих перевірок у рантаймі.
5263 | 
5264 | - Мінімізувати використання any, щоб уникнути неочікуваних конверсій.
5265 | 
5266 | - Використовувати readonly, const для зменшення мутабельності.
5267 | 
5268 | 2. **Асинхронність і конкурентність**
5269 | 
5270 | - Promise.all для паралельних запитів.
5271 | 
5272 | - Асинхронні ітератори для потокових даних.
5273 | 
5274 | - Дебаунс і троттл для обробки подій у UI.
5275 | 
5276 | 3. **Оптимізація фронтенд-коду**
5277 | 
5278 | - Динамічний імпорт модулів (import()) → code splitting.
5279 | 
5280 | - Tree-shaking у збірниках (Webpack, Vite).
5281 | 
5282 | - Мінімізація об’єктів і масивів, уникання глибоких копій без потреби.
5283 | 
5284 | 4. **Профілювання і кешування**
5285 | 
5286 | - Використовувати DevTools для виявлення "гарячих" функцій.
5287 | 
5288 | - Кешування результатів складних обчислень (memoization).
5289 | 
5290 | - Кешування API-запитів або локальне збереження даних (IndexedDB, LocalStorage).
5291 | 
5292 | 5. **Оптимізація Node.js бекенду**
5293 | 
5294 | - Використовувати потокову обробку великих даних (streams).
5295 | 
5296 | - Уникати блокуючого коду і синхронних операцій.
5297 | 
5298 | - Підвищити продуктивність через правильний розподіл процесів (cluster,
5299 |   worker_threads).
5300 | 
5301 | 6. **Приклад memoization у TS**
5302 | 
5303 | ```TypeScript
5304 | function memoize<T extends (...args: any[]) => any>(fn: T): T {
5305 |   const cache = new Map<string, ReturnType<T>>();
5306 |   return ((...args: any[]) => {
5307 |     const key = JSON.stringify(args);
5308 |     if (!cache.has(key)) cache.set(key, fn(...args));
5309 |     return cache.get(key)!;
5310 |   }) as T;
5311 | }
5312 | ```
5313 | 
5314 | Основна ідея: поєднання типобезпечного коду, асинхронності, кешування та
5315 | профілювання забезпечує ефективну оптимізацію продуктивності
5316 | TypeScript-додатків.
5317 | 
5318 | </details>
5319 | 
5320 | <details>
5321 | <summary>91. Як реалізувати та використовувати 'tree shaking' у TypeScript-проєктах?</summary>
5322 | 
5323 | #### TypeScript
5324 | 
5325 | 1. **Визначення Tree Shaking**
5326 | 
5327 | - Tree shaking — це процес видалення невикористаного коду під час збірки.
5328 | 
5329 | - Дозволяє зменшити розмір бандла, залишаючи тільки імпортовані функції, класи
5330 |   або константи.
5331 | 
5332 | 2. **Підтримка у TypeScript**
5333 | 
5334 | - TypeScript компілює код у ES-модулі (`import` / `export`).
5335 | 
5336 | - Tree shaking працює лише з ESM, не з CommonJS.
5337 | 
5338 | 3. **Налаштування у TS-проєкті**
5339 | 
5340 | - У `tsconfig.json`:
5341 | 
5342 | ```json
5343 | {
5344 |   "compilerOptions": {
5345 |     "module": "ESNext",
5346 |     "target": "ES6"
5347 |   }
5348 | }
5349 | ```
5350 | 
5351 | - Використовувати збирачі, які підтримують tree shaking: Webpack, Rollup, Vite.
5352 | 
5353 | 4. **Приклад**
5354 | 
5355 | ```TypeScript
5356 | // utils.ts
5357 | export function used() { console.log("Used"); }
5358 | export function unused() { console.log("Unused"); }
5359 | 
5360 | // main.ts
5361 | import { used } from "./utils";
5362 | used();
5363 | ```
5364 | 
5365 | - Під час збірки `unused()` буде видалено, якщо включено tree shaking.
5366 | 
5367 | 5. **Ключові поради**
5368 | 
5369 | - Використовувати іменовані експорти замість `export default`.
5370 | 
5371 | - Мінімізувати side effects у файлах (`"sideEffects": false` у `package.json`).
5372 | 
5373 | - Стежити, щоб всі залежності підтримували ESM.
5374 | 
5375 | Основна ідея: TypeScript + ES-модулі дозволяють збирачу видаляти невикористаний
5376 | код автоматично, зменшуючи розмір бандла і покращуючи продуктивність.
5377 | 
5378 | </details>
5379 | 
5380 | <details>
5381 | <summary>92. Як зменшити розмір фінального бандла в TypeScript-проєкті?</summary>
5382 | 
5383 | #### TypeScript
5384 | 
5385 | 1. **Tree Shaking**
5386 | 
5387 | - Використовувати іменовані експорти замість `export default`.
5388 | 
5389 | - Переконатися, що всі файли ESM-модулі (`"module": "ESNext"` у
5390 |   `tsconfig.json`).
5391 | 
5392 | - Вказати `"sideEffects": false` у `package.json`.
5393 | 
5394 | 2. **Code Splitting / Dynamic Imports**
5395 | 
5396 | - Розбивати великий код на чанки за допомогою `import()` для відкладеного
5397 |   завантаження.
5398 | 
5399 | ```TypeScript
5400 | const module = await import("./heavyModule");
5401 | module.run();
5402 | ```
5403 | 
5404 | 3. **Мінімізація і компресія**
5405 | 
5406 | - Використовувати Terser / esbuild / SWC для мінімізації JS-коду.
5407 | 
5408 | - Gzip або Brotli для продакшн-деплойменту.
5409 | 
5410 | 4. **Видалення неактивного коду та поліморфів**
5411 | 
5412 | - Уникати великих утиліт або бібліотек без конкретного імпорту.
5413 | 
5414 | - Імпортувати тільки потрібні функції (`import { debounce } from "lodash"`
5415 |   замість `import _ from "lodash"`).
5416 | 
5417 | 5. **Оптимізація типів**
5418 | 
5419 | - Типи TS не потрапляють у бандл → використовуй їх для розробки, не додаючи
5420 |   runtime-код.
5421 | 
5422 | - Використовувати `import type` для імпорту типів, щоб не збільшувати код.
5423 | 
5424 | 6. **Приклад import type:**
5425 | 
5426 | ```TypeScript
5427 | import type { User } from "./types";
5428 | 
5429 | function greet(user: User) {
5430 |   console.log(`Hello, ${user.name}`);
5431 | }
5432 | ```
5433 | 
5434 | - TS видаляє типи з компільованого JS.
5435 | 
5436 | Основна ідея: комбінування tree shaking, динамічних імпортів, мінімізації та
5437 | правильного використання типів TS дозволяє суттєво зменшити розмір пакета.
5438 | 
5439 | </details>
5440 | 
5441 | ### Нові можливості та оновлення TypeScript
5442 | 
5443 | <details>
5444 | <summary>93. Які нові можливості з'явилися в останній версії TypeScript?</summary>
5445 | 
5446 | #### TypeScript
5447 | 
5448 | #### Основні нові можливості
5449 | 
5450 | 1. **Покращення продуктивності**
5451 | 
5452 | - Оптимізовано структуру коду та алгоритми, що призвело до зменшення часу
5453 |   компіляції та обсягу пам'яті, необхідного для роботи TypeScript .
5454 | 
5455 | 2. **Покращення роботи з ECMAScript модулями (ESM)**
5456 | 
5457 | - Додано нові можливості для кращої підтримки ESM у Node.js та бандлерах .
5458 | 
5459 | 3. **Покращення роботи з декораторами**
5460 | 
5461 | - Реалізація нового стандарту декораторів, що дозволяє краще налаштовувати класи
5462 |   та їхні члени у повторно використовуваному вигляді .
5463 | 
5464 | 4. **Нова можливість для авторів бібліотек**
5465 | 
5466 | - Додано нові способи для авторів бібліотек контролювати виведення типів для
5467 |   узагальнених параметрів .
5468 | 
5469 | 5. **Розширена підтримка JSDoc**
5470 | 
5471 | - Покращено функціональність JSDoc для кращої інтеграції з TypeScript .
5472 | 
5473 | 6. **Спрощення конфігурації**
5474 | 
5475 | - Спрощено налаштування TypeScript для зручнішого використання .
5476 | 
5477 | #### Оптимізації
5478 | 
5479 | - Зменшення розміру пакета: TypeScript 5.0 містить значні зміни в структурі
5480 |   коду, що дозволяє зменшити розмір пакета .
5481 | 
5482 | - Покращення швидкості: Оптимізовано алгоритми, що призвело до покращення
5483 |   швидкості компіляції .
5484 | 
5485 | #### Інші покращення
5486 | 
5487 | - Покращення повідомлень про помилки: TypeScript 5.0 зосереджено на покращенні
5488 |   досвіду розробника через більш детальні та корисні повідомлення про помилки .
5489 | 
5490 | </details>
5491 | 
5492 | <details>
5493 | <summary>94. Як застосовувати шаблонні літеральні типи (template literal types) у TypeScript?</summary>
5494 | 
5495 | #### TypeScript
5496 | 
5497 | 1. **Визначення**
5498 | 
5499 | - Шаблонні літеральні типи дозволяють комбінувати рядкові літерали та типи для
5500 |   створення нових типів.
5501 | 
5502 | - Синтаксис схожий на template strings у JavaScript, але працює на рівні типів.
5503 | 
5504 | 2. **Приклад базового використання**
5505 | 
5506 | ```TypeScript
5507 | type Color = "red" | "green" | "blue";
5508 | type Shade = "light" | "dark";
5509 | 
5510 | type ColoredShade = `${Shade}-${Color}`;
5511 | // Результат: "light-red" | "light-green" | "light-blue" | "dark-red" | "dark-green" | "dark-blue"
5512 | ```
5513 | 
5514 | 3. **Використання з функціями**
5515 | 
5516 | ```TypeScript
5517 | function setTheme(theme: ColoredShade) {
5518 |   console.log(`Theme set to ${theme}`);
5519 | }
5520 | 
5521 | setTheme("light-red"); // ✅ коректно
5522 | setTheme("dark-yellow"); // ❌ помилка компіляції
5523 | ```
5524 | 
5525 | 4. **Комбінація з умовними типами**
5526 | 
5527 | ```TypeScript
5528 | type Prefix = "on" | "off";
5529 | type Event = "Click" | "Hover";
5530 | 
5531 | type EventHandler = `${Prefix}${Event}`;
5532 | // "onClick" | "onHover" | "offClick" | "offHover"
5533 | ```
5534 | 
5535 | 5. **Переваги**
5536 | 
5537 | - Створення типобезпечних рядкових констант без дублювання.
5538 | 
5539 | - Легко підтримувати конвенції іменування, напр. для CSS-класів або
5540 |   API-параметрів.
5541 | 
5542 | - Інтегрується з union типами та генеріками.
5543 | 
5544 | Основна ідея: шаблонні літеральні типи дають змогу створювати складні рядкові
5545 | типи на основі простих, забезпечуючи сувору типізацію і зменшуючи помилки.
5546 | 
5547 | </details>
5548 | 
5549 | <details>
5550 | <summary>95. Які покращення TypeScript внесла у вивід типів (type inference) для умовних типів?</summary>
5551 | 
5552 | #### TypeScript
5553 | 
5554 | 1. **Визначення**
5555 | 
5556 | - Умовні типи (`T extends U ? X : Y`) дозволяють повертати різні типи залежно
5557 |   від вхідного.
5558 | 
5559 | - TypeScript тепер краще виводить типи при складних комбінаціях, особливо з
5560 |   generic та union типами.
5561 | 
5562 | 2. **Покращений інференс для union типів**
5563 | 
5564 | ```TypeScript
5565 | type ElementType<T> = T extends (infer U)[] ? U : T;
5566 | 
5567 | type A = ElementType<string[]>; // string
5568 | type B = ElementType<number>;   // number
5569 | type C = ElementType<(string | number)[]>; // string | number
5570 | ```
5571 | 
5572 | - Раніше TypeScript міг не коректно виводити `C` як `string | number`, зараз
5573 |   робить точний розбір union.
5574 | 
5575 | 3. **Умовні типи з infer**
5576 | 
5577 | - Покращено вивід типів, коли використовуються вкладені `infer` для витягування
5578 |   внутрішніх типів.
5579 | 
5580 | ```TypeScript
5581 | type ReturnType<T> = T extends (...args: any) => infer R ? R : never;
5582 | 
5583 | const fn = (x: number) => x.toString();
5584 | type R = ReturnType<typeof fn>; // string
5585 | ```
5586 | 
5587 | 4. **Контекстна типізація для generics**
5588 | 
5589 | - TypeScript краще передбачає типи при передачі generic параметрів у функції.
5590 | 
5591 | ```TypeScript
5592 | function wrap<T>(value: T) {
5593 |   return { value };
5594 | }
5595 | 
5596 | const wrapped = wrap(42); // { value: number } без явного вказання <number>
5597 | ```
5598 | 
5599 | 5. **Переваги**
5600 | 
5601 | - Менше явних анотацій типів.
5602 | 
5603 | - Покращене автодоповнення і попередження помилок.
5604 | 
5605 | - Складні типи (union, intersection, mapped types) стають більш передбачуваними.
5606 | 
5607 | Основна ідея: TypeScript зараз точніше виводить типи для умовних конструкцій,
5608 | generics та infer, зменшуючи потребу у ручних анотаціях і роблячи код більш
5609 | безпечним.
5610 | 
5611 | </details>
5612 | 
5613 | <details>
5614 | <summary>96. Для чого потрібні позначені елементи (labeled tuples) у TypeScript?</summary>
5615 | 
5616 | #### TypeScript
5617 | 
5618 | 1. **Визначення**
5619 | 
5620 | Позначені кортежі — це кортежі, де кожен елемент має ім’я, що покращує читаність
5621 | і автодоповнення.
5622 | 
5623 | Синтаксис:
5624 | 
5625 | ```TypeScript
5626 | type Point = [x: number, y: number];
5627 | const p: Point = [10, 20];
5628 | ```
5629 | 
5630 | 2. **Переваги**
5631 | 
5632 | Зрозуміліший код: зрозуміло, що означає кожен елемент.
5633 | 
5634 | Автодоповнення в IDE: TypeScript підказує назви елементів при деструктуризації.
5635 | 
5636 | Типобезпечні операції: помилки при неправильному порядку або типі елемента
5637 | виявляються на етапі компіляції.
5638 | 
5639 | Приклад використання
5640 | 
5641 | ```TypeScript
5642 | type Range = [start: number, end: number];
5643 | 
5644 | function getRange(): Range {
5645 |   return [0, 10];
5646 | }
5647 | 
5648 | const [start, end] = getRange(); // start та end підказуються IDE
5649 | console.log(start, end); // 0 10
5650 | ```
5651 | 
5652 | Особливості
5653 | 
5654 | Позначення є для читабельності, не впливає на runtime.
5655 | 
5656 | Працює з readonly кортежами:
5657 | 
5658 | ```TypeScript
5659 | const coords: readonly [x: number, y: number] = [1, 2];
5660 | ```
5661 | 
5662 | Основна ідея: позначені кортежі підвищують зручність та безпеку коду, покращують
5663 | автодоповнення і допомагають уникати помилок при роботі з позиційними
5664 | елементами.
5665 | 
5666 | </details>
5667 | 
5668 | ### Спільнота та розвиток TypeScript
5669 | 
5670 | <details>
5671 | <summary>97. Як розробник може внести свій внесок у спільноту TypeScript або у сам проект TypeScript?</summary>
5672 | 
5673 | #### TypeScript
5674 | 
5675 | 1. **Внесок у код TypeScript**
5676 | 
5677 | - TypeScript — відкритий проект на GitHub:
5678 |   https://github.com/microsoft/TypeScript
5679 | 
5680 | - Можна:
5681 | 
5682 |   - фіксити баги (`bug reports`),
5683 | 
5684 |   - додавати або покращувати типи,
5685 | 
5686 |   - пропонувати нові фічі (`feature requests`),
5687 | 
5688 |   - робити PR з виправленнями.
5689 | 
5690 | 2. **Покращення екосистеми**
5691 | 
5692 | - Створювати бібліотеки або декларації типів (`DefinitelyTyped`).
5693 | 
5694 | - Писати npm-пакети з TypeScript і надавати `.d.ts` файли.
5695 | 
5696 | - Вносити зміни у типи для популярних бібліотек (PR до DefinitelyTyped ).
5697 | 
5698 | 3. **Документація та навчальні матеріали**
5699 | 
5700 | - Дописувати статті, гіди, блог-пости, туторіали.
5701 | 
5702 | - Перекладати офіційну документацію TS.
5703 | 
5704 | - Писати приклади та шаблони проектів для спільноти.
5705 | 
5706 | 4. **Спільнота та підтримка**
5707 | 
5708 | - Відповідати на питання на StackOverflow, Discord, GitHub Discussions.
5709 | 
5710 | - Організовувати або брати участь у локальних/онлайн митапах.
5711 | 
5712 | - Робити огляди бібліотек, нових фіч TypeScript.
5713 | 
5714 | 5. **Підтримка інструментів**
5715 | 
5716 | - Розробляти плагіни для IDE (VSCode), лінтерів, CLI-інструментів.
5717 | 
5718 | - Тестувати нові версії TypeScript у власних проєктах і звітувати баги.
5719 | 
5720 | Основна ідея: внесок може бути як кодовий (PR, DefinitelyTyped), так і
5721 | інформаційний (документація, навчання, спільнота), і будь-який такий внесок
5722 | робить екосистему TypeScript сильнішою.
5723 | 
5724 | </details>
5725 | 
5726 | <details>
5727 | <summary>98. Яку роль відіграє TypeScript у проєктах з відкритим кодом?</summary>
5728 | 
5729 | #### TypeScript
5730 | 
5731 | 1. **Покращена безпека коду**
5732 | 
5733 | - Статична типізація дозволяє уникати багатьох помилок ще на етапі компіляції.
5734 | 
5735 | - У великих відкритих проєктах це критично для підтримки стабільності.
5736 | 
5737 | 2. **Зрозумілі API та документація через типи**
5738 | 
5739 | - Типи слугують самодокументованим кодом.
5740 | 
5741 | - У відкритих бібліотеках користувачі одразу бачать, які параметри і значення
5742 |   очікуються.
5743 | 
5744 | 3. **Масштабованість**
5745 | 
5746 | - TypeScript полегшує роботу з великими кодовими базами та численними
5747 |   контриб’юторами.
5748 | 
5749 | - Генеровані `.d.ts` файли дозволяють іншим мовам/середовищам (наприклад, JS)
5750 |   безпечно використовувати бібліотеку.
5751 | 
5752 | 4. **Сумісність з існуючим JS-кодом**
5753 | 
5754 | - TypeScript дозволяє поступово типізувати проєкти, що вже існують у JS, без
5755 |   переписування всього коду.
5756 | 
5757 | 5. **Покращене співробітництво**
5758 | 
5759 | - Контриб’ютори легше розуміють структуру і контракти коду.
5760 | 
5761 | - Зменшується кількість помилок у pull request.
5762 | 
5763 | 6. **Приклади успішних open-source проєктів на TS**
5764 | 
5765 | - React, Vue 3, Angular, Deno, NestJS, RxJS — великі проєкти на TypeScript.
5766 | 
5767 | - TypeScript допомагає підтримувати високу якість коду та стабільність API.
5768 | 
5769 | Основна ідея: TypeScript у відкритому коді підвищує безпеку, читаємість,
5770 | масштабованість і полегшує співпрацю багатьох розробників, що критично для
5771 | open-source екосистеми.
5772 | 
5773 | </details>
5774 | 
5775 | <details>
5776 | <summary>99. Як відстежувати зміни та дотримуватися найкращих практик у TypeScript?</summary>
5777 | 
5778 | #### TypeScript
5779 | 
5780 | 1. **Офіційні джерела**
5781 | 
5782 | - TypeScript Blog: https://devblogs.microsoft.com/typescript — анонси нових
5783 |   версій, фічі, release notes.
5784 | 
5785 | - Документація: https://www.typescriptlang.org/docs/ — актуальні гіди та
5786 |   приклади.
5787 | 
5788 | 2. **Соціальні мережі та спільнота**
5789 | 
5790 | - Twitter акаунти розробників TS (наприклад, @dan_abramov, @andrewbranch).
5791 | 
5792 | - GitHub Discussions, StackOverflow, Reddit (r/typescript).
5793 | 
5794 | 3. **Підписка на оновлення**
5795 | 
5796 | - RSS/Email для TypeScript Blog.
5797 | 
5798 | - YouTube-канали з туторіалами та оглядами нових фіч.
5799 | 
5800 | 4. **Відкритий код та аналіз бібліотек**
5801 | 
5802 | - Стежити за популярними проєктами на TypeScript (React, NestJS, RxJS) для
5803 |   прикладів реального використання.
5804 | 
5805 | - Аналізувати PR і release notes бібліотек, щоб бачити, як використовують TS у
5806 |   продакшн.
5807 | 
5808 | 5. **Код-рев’ю та стиль коду**
5809 | 
5810 | - Використовувати ESLint, TSLint (deprecated, але TS ESLint плагін активний).
5811 | 
5812 | - Дотримуватися офіційних рекомендацій TypeScript щодо strict mode, типів,
5813 |   generics і модулів.
5814 | 
5815 | 6. **Практика та реальні проєкти**
5816 | 
5817 | - Постійно писати код на TypeScript, експериментувати з новими фічами (template
5818 |   literal types, conditional types, decorators).
5819 | 
5820 | - Робити рефакторинг старого JS-коду у TS для закріплення знань.
5821 | 
5822 | Основна ідея: комбінувати офіційні ресурси, спільноту, практичний досвід і
5823 | регулярний аналіз open-source проєктів, щоб залишатися в курсі змін і найкращих
5824 | практик TypeScript.
5825 | 
5826 | </details>
5827 | 
5828 | ### Перехід з JavaScript на TypeScript
5829 | 
5830 | <details>
5831 | <summary>100. Як розробнику JavaScript ефективно перейти на TypeScript?</summary>
5832 | 
5833 | #### TypeScript
5834 | 
5835 | 1. **Розуміння основ TypeScript**
5836 | 
5837 | - Вивчити базові типи (`string`, `number`, `boolean`, `any`, `unknown`, `void`,
5838 |   `null`, `undefined`).
5839 | 
5840 | - Розібратися з інтерфейсами (`interface`), типами (`type`) та кортежами
5841 |   (`tuple`).
5842 | 
5843 | - Ознайомитися з `generics` і умовними типами.
5844 | 
5845 | 2. **Налаштування проєкту**
5846 | 
5847 | - Ініціалізувати TypeScript: `tsc --init`.
5848 | 
5849 | - Встановити TypeScript і типи для Node/React/Express:
5850 | 
5851 | ```bash
5852 | npm install --save-dev typescript @types/node
5853 | ```
5854 | 
5855 | - Налаштувати `tsconfig.json` (наприклад, `"strict": true`,
5856 |   `"module": "ESNext"`, `"target": "ES6"`).
5857 | 
5858 | 3. **Поступовий перехід**
5859 | 
5860 | - Почати з переіменування `.js` файлів у `.ts` або `.tsx` (для React).
5861 | 
5862 | - Використовувати `allowJs: true` у `tsconfig` для сумісності з існуючим JS.
5863 | 
5864 | - Додавати типи поетапно (`any` для швидкого старту, потім уточнювати).
5865 | 
5866 | 4. **Інтеграція з інструментами**
5867 | 
5868 | - ESLint з плагіном для TypeScript (`@typescript-eslint`).
5869 | 
5870 | - IDE з підтримкою TypeScript (VSCode) для автодоповнення та рефакторингу.
5871 | 
5872 | 5. **Робота з бібліотеками**
5873 | 
5874 | - Встановлювати типи для сторонніх пакетів:
5875 | 
5876 | ```bash
5877 | npm install --save-dev @types/express
5878 | ```
5879 | 
5880 | - Використовувати декларації типів, якщо бібліотека написана на JavaScript.
5881 | 
5882 | 6. **Практика і рефакторинг**
5883 | 
5884 | - Писати невеликі модулі на TypeScript.
5885 | 
5886 | - Постійно рефакторити старий JS-код, додаючи типи і generics.
5887 | 
5888 | - Вчитися на open-source проєктах, написаних на TypeScript.
5889 | 
5890 | 7. **Кращі практики**
5891 | 
5892 | - Використовувати строгий режим (`strict: true`).
5893 | 
5894 | - Використовувати `readonly` для незмінних структур.
5895 | 
5896 | - Віддавати перевагу типам над `any`.
5897 | 
5898 | - Використовувати інтерфейси для API контрактів і DTO.
5899 | 
5900 | Основна ідея: почати з базових типів, налаштувати проєкт, поступово типізувати
5901 | існуючий JS-код і застосовувати кращі практики для підтримки стабільності та
5902 | безпеки коду.
5903 | 
5904 | </details>
5905 | 
5906 | <details>
5907 | <summary>101. ???</summary>
5908 | 
5909 | #### TypeScript
5910 | 
5911 | - Coming soon...😎
5912 | 
5913 | </details>
5914 | 


--------------------------------------------------------------------------------