Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

09.01.2023

Дискриміновані союзи у TypeScript як засіб розширення додатків

Продовжуючи тему Сінтри, з “Цілями та заощадженнями” зʼявляється новий різновид витрати — витрата з переводом на заощадження. До неї застосовується особлива логіка, наприклад — замість категорії відображатиметься заощадження. Логічно.

Коли до готової нетипізованої схеми даних додається нова форма, то буде складно відстежити всі місця, де треба врахувати її. На моєму досвіді це зведеться до ручного пошуку помилок, та, якщо пощастило з проєктом — оновленням відповідних тестів. Так буде і на JavaScript, і на Ruby.

В типізованій мові могло б бути так же. Наприклад, якщо в TypeScript до типу Expense я додам нове поле goalID, то так само доведеться шукати всі місця використання цього типу. Але у TypeScript є краще рішення на таку ситуацію — дискриміновані союзи. Це спосіб, фактично, сказати, що у витрати є дві різних форми — або з полем categoryID, або полем goalID. Тепер весь код, що очікує бачити витрати з категоріями, стане помилковим, оскільки не враховує всі можливі варіанти типу. Щоб виправити його, потрібно додати до коду перевірку на тип витрати. Так автоматична перевірка типів замінить нам ручне тестування.

При цьому, що важливо, інформація про тип дискримінованого союзу береться з самого обʼєкту — зі значення або наявності поля-“дискримінанта”. Тож з боку JavaScript та, головне, з боку бази даних цей тип залишається звичайнісіньким обʼєктом JSON.