🔵 Типи vs Інтерфейси в TypeScript

Щоб описати складні типи, в TS ми можемо використовувати дві сутності: типи або інтерфейси. У цьому дописі ми розглянемо їх відмінності та схожості.

Обидва дозволяють створювати повторно використовувані структури для змінних, параметрів функцій, типів повернення, тощо. Наприклад:

type PersonType = {
age: number;
isFemale: boolean;
name: string;
};

interface PersonInterface {
age: number;
isFemale: boolean;
name: string;
}

У багатьох випадках типи та інтерфейси можна використовувати взаємозамінно. Проте є невеликі відмінності, які важливо враховувати:

🔵 Типи можуть містити примітиви або об'єднані типи. Це неможливо з інтерфейсами, з ними ви можете визначати лише об'єкти.

type A = number;
type B = A | string;


🔵 Декілька інтерфейсів з однаковою назвою і в одній області видимості автоматично об'єднуються. Це називається об'єднанням оголошень (declaration merging). Натомість, типи є імутабульними. Декілька типів з однаковою назвою в одній області видимості викличуть помилку.

interface User {
email: string;
}
interface User {
password: string;
}
// no error
const user: User = {
email: 'email',
password: 'password',
};


type User = {
email: string;
};
//error
type User = {
email: string;
};


🔵 Коли ви розширюєте інтерфейс за допомогою extends, TypeScript переконається, що інтерфейс, який ви розширюєте, можна присвоїти вашому розширенню. Якщо ні - виникне помилка, що дуже корисно. Це не відбувається в разі використання типів: тут TypeScript зробить все можливе, щоб об'єднати розширення.

Що ви в основному використовуєте в своєму проекті: типи чи інтерфейси? Чи є які-небудь конвенції, на які ви погодилися з вашою командою?

🔵 Типи vs Значення у TypeScript

Чи коли-небудь ви задавалися питанням, чому назви типів і змінних для значень не конфліктують у TS? Тобто чому ви можете оголосити тип "Person" та об'єкт "Person" в одній області видимості?

type Person = { age: number; name: string };
const Person: Person = { age: 1, name: 'Anastasiia'};

У TS типи та значення зберігаються в різних неймспейсах. Залежно від того, де ви розмістите свою змінну, вона зарезолвиться як тип або як значення:

if(count > 0) // ts infers a value
let x: count = 5 // ts infers a type 

Проте, у TypeScript є дві особливі сутності, які обробляються і як тип і як значення. Це класи та енами.

enum FRUITS {ORANGE, APPLE};
let meal: FRUITS = FRUITS.APPLE

Як класи, так і енами генерують як тип в нейспейсі типів так і значення в неймспейсі значень.

Ви ж не думали що я так просто від вас відчеплюся :)
Якщо зірки складуться я ще й відео про це зніму 😎

Як я розділяю застосунок на компоненти (про декомпозицію)

Якщо коротко - то за їх функціоналом, так щоб при погляді на код ви могли назвати одну і лише одну задачу яку виконує цей код.

Якщо компонент або клас або функція робить декілька речей одразу - вони кандидати для декомпозиції.

Наприклад нам потрібно відобразити список втрат русні за всі роки. Для цього нам потрібно - завантажити дані, обробити потенційну помилку, зберегти дані в стейт, відмалювати дані, відмалювати помилку, відмалювати індикатор завантаження.

Все це можна покласти в один компонент, але краще розділити код на окремі частини:

1. Код що вантажить дані. Зазвичай це код навколо fetch, він не залежить від #React - його зручно тримати окремо
2. Код який зберігає дані в стейт. Це можна тримати в компоненті, а можна викинути в окремий кастомний хук
3. Компонент що відображає результат. Відображення даних краще відділяти від їх завантаження, так код компонента вьюшки буде простішим
4. Компоненти що відображають помилку та завантаження - вони мінімально залежать від батьківського компоненту і можливо ви їх навіть використаєте повторно.

В результаті ми отримаємо один батьківський компонент, який займається композицією, і декілька дрібних підкомпонентів кожен з який займається однією єдиною задачею:

export function DemoApp() {
  const { casualties } = useCasualtiesData();
  const { status } = casualties;
  return (
    <main>
      <H1>Втрати русні</H1>
      <p>
        {status === "loading" && <LoadingIndicator />}
        {status === "failed" && <LoadingError />}
        {status === "ok" && <CasualtiesView casualties={casualties.data} />}
      </p>
    </main>
  );
}

Підхід рекурсивний, допоки не дійдете до бажаного результату.

Раджу спробувати!

@reactbeginners

🔵 Підтипи і супертипи в TypeScript

У TypeScript може бути визначений зв'язок між типами.

Підтип - це тип, який повністю охоплюється іншим типом. Підтип є більш специфічним, і якщо тип Orange є підтипом Fruit, це означає, що ви можете використовувати Orange будь-де, де очікується Fruit.

Наприклад:
🔹 Array - підтип Object, і ви можете використовувати його там, де очікується Object.
🔹 Кожен тип є підтипом any
🔹 never є підтипом будь-якого іншого типу, і ви можете використовувати його будь-де.

З іншого боку, є супертип - він є більш загальним або ширшим, ніж інший тип. Тобто, Fruit є супертипом Orange.

🔹 Object є супертипом Array.
🔹 Any є супертипом будь-якого іншого типу.

Треба ваша маленька допомога 😜

Накидайте ваш топ книг які варто почитати.

Жанр - фантастика, але можна все що дійсно вважаєте вартим уваги.

Зібрав усі запропоновані книги в один список

Найпопулярнішою книгою вийшла трилогія "Пам'ять про минуле Землі" від Лю Цисіня та Дюна.

Цікаво що ніхто не згадав "Чи мріють андроїди про електричних овець" та Нейроманта

Всім подякував!

Коротко про декомпозицію коду в #React (19:00)

Завтра відбуваю на навчання тож на останок тримайте відео про React та декомпозицію, яке виходить сьогодні о 19:00.

Знімав трохи поспіхом, але наче вийшло. Поставте під відео декілька лайків - буду радий побачити що не просто так робив)

А ви бережіть себе, допомагайте ЗСУ і скоро побачимося!

React Compiler

Компілятор в React - перспективна нова фіча, яка на слуху з початку 2024 року. В інтернеті багато гучних заголовків типу "нові React розробники більше не будуть знати про ручну мемоізацію (useMemo, useCallback, memo), оскільки вона буде виконуватися під капотом".

Перша згадка про React Compiler була в 2021 році з POC від команди React. Тоді він називався React Forget. Однак з POC і до 2024 року про нього не було офіційних згадок.

І от ми в 2024 році, де React Compiler опенсорсний. Ви можете прямо зараз його поклацать (для цього вам знадобиться React 19).

Які проблеми вирішує компілятор:

1. Вибір між DX та UX. Без компілятора розробники повинні були вирішувати, чи вони будуть жертвувати девелопер експіріенсом та якістю коду, щоб забезпечити добре оптимізований UX з мемоізацією, чи жертвувати UX і не турбуватися про мемоізацію зовсім. Тепер всі мемоізації будуть виконуватися під капотом.

2. Брудний код

3. Складне управління залежностями даних. Не кожен розробник достатньо кваліфікований, щоб застосувати ручну мемоізацію і зробити цим краще, а не гірше.

4. Ризики зламати мемоізацію

5. Довгий час дебагу.

Ви вже пробували компілятор? Що думаєте?

Як вирішити проблему швидкого девайса? 💻

Зазвичай, розробники пишуть на приладах, що є набагато більш потужними за прилади середньостатистичного юзера. І мають кращий інтеренет. Тому ми можемо не помічати різноманітні проблеми перформансу, з якими потім зіткнеться кінцевий користувач.

Тому рекомендую активно користуватися вкладкою Performance в DevTools. А саме:

1. Опція CPU Throttling дозволяє нам уповільнити CPU в 4 або 6 раз. 6 я зазвичай не витримую, але 4-ма користуюсь доволі часто.

2. Опція Network throttling дозволяє нам проімітувати більш повільний інтернет (швидкий 3G або повільний 3G), або вимкнути у вкладці конекшон взагалі.

Рекомендую привчити себе користуватися цими опціями. Але не забувайте їх відключати, наприклад, при перезавантаженні сайту. Бо потім можна довго чекати 😅

⚛ “Хук” use в React

А ви вже чули про use? Коли він тільки з’явився в canary, блогери користувалися гучними заголовками типу “новий хук use ламає всі правила хуків в реакті”. Навіть під моїм дописом про хуки на доу, де я розповідала, що хуки не можна використовувати умовно (в if стейтментах, наприклад), були коментарі типу “ти що, забила забула про use”.

Так от, react тіма мабуть теж отримувала подобні коментарі, і тому вони перестали називать use хуком, а стали іменувать його use api.

Що може use API:

⚛ Використовувати значення промісів.

const users = use(usersPromise);

⚛ Використовувати значення контексту (як заміна useContext):

const theme = use(themeContext);

На відміну від хуків, use можна використовувати в умовах та лупах. Але він має і лімітації, що присутні хукам, адже його можна використовувати тільки всередині компонентів або інших хуків.
https://react.dev/reference/react/use

💛 Що ми знаємо про масиви?

Мисиви - структура даних, з якою ми стикаємося, без перебільшення, кожен день. То пропоную повторити теорію.

Масив є лінійною структурою даних, тобто всі його елементи йдуть послідовно один за одним. Особливістю масивів є те, що його елементи доступні по їх індексах. У більшості мов програмування, індексація масивів починається з 0.

Доступ до елементів масиву є довільним, тобто виконується за постійний час та не залежить від розмірів масиву. Використовуючи терміни нотації big O, складність за часом становить O(1).

В JavaScript масиви динамічними (умовно не мають фіксованого розміру) та можуть містити суміш різних типів даних (наприклад стрінги та числа).

Є два синтаксиса створення масивів:
💛 [] (literal notation)

const arr = [1, 2, 3]

💛 конструктор Array()

const arr = new Array(1, 2, 3)

В js масив є reference type, тобто у змінній, якій ми присваюємо масив, зберігається посилання(reference) на нього в memory heap. Тому, навіть якщо ми оголосимо масив як const, js все одно дає нам його мутувати, головне щоб не змінювалося посилання (тобто не переоголошувати в цю змінну новий масив, наприклад).

Але цьому можна запобігти використовуючи Object.freeze (т.я. Масиви в js також є об’єктами, цей метод можна використовувати з масивами).




const arr = [2];

Object.freeze(arr);

arr.push(5);

Обкатка БТРом, стрільби з різних положень, чистка зброї, медицина, пересування і все таке інше - десь так проходить зараз моє навчання.

Звичайно не все так гладко - наряди задовбують, тривоги заважають спати, броніки сцуко важкі. Але ми потроху рухаємося вперед.

Що радує - інструктори розуміють що у нас тут не рембо зібралися і до фізухи та вправ ставляться адекватно, бо вік тут дуже різний, самі розумієте.

А от з менеджереми є нюанси. Я б дорого (дуже дорого) дав би за толкового зубатого менеджера на певну посаду.

На react часу не вистачає але jsweekly поглядаю. А ще пробую писати нотатки на телефоні, може потім опублікую. Так і живемо.

А що ви тут без мене робили?

💛 Polyfilling vs Transpiling

Ми часто чуємо ці терміни, але не завжди розуміємо, що вони роблять і в чому різниця. Тому в цьому дописі спробуємо скласти поверхневу картину.

Як polyfilling так і transpiling ми використовуємо для того, щоб старіші браузери (environments) могли використовувати нові фічі js, навіть якщо в них вони ще не підтримуються.

У процесі поліфілу ми в коді емулюємо API, ніби вони вже є реалізованими. Наприклад:

if(!Array.prototype.with) {
Array.prototype.with = blah-blah
}

Таким чином ми наче заповнюємо дири нестаючих API прямо в нашому коді.

Транспіляція працює дещо інакше. Транспілятор аналізує “сучасний” код і переписує його таким чином, щоб він відповідав старішим стандартам, які підтримуються більшістю браузерів. Наприклад, вхідний код написаний на ES6+ буде перетворений на ES5 (в цьому може допомогти Babel або інші транспайлери).

Харків - мої співчуття. русня не люди.

Хто бажає підтягнути трохи свій рівень #React раджу подивитися наш плейліст - React Code Smells: https://www.youtube.com/playlist?list=PLx9b8ngesbGG_kYzCcPBg8F96f9mhhN-e

Також до нього є відкритий репозиторій з прикладами.

Бережіть себе, допомагайте ЗСУ і скоро побачимось!

Як код стає поганим🧑‍💻

Не буває такого, що ми з початку проекта такі зібрались з дев командою і вирішили - будемо писати фіговий код. Ну я сподіваюсь, що такого не буває😅 І тим не менш, через якісь проміжок часу код база стає все менш і менш читабельною, її все складніше і складніше підтримувати.

В цьому дописі спробуємо проаналізувати події, які зазвичай призводять до погіршення коду, а також спробуємо мінімізувати їх наслідки.

Дискдеймер: код (процеси, планінг, etc) ніколи не будуть ідеальними. Будь яка код база з часом стане легасі. Тому ми кажемо про покращення, а не про те, щоб зробити ідеально.

Тож які фактори впливають на погіршення коду:

1. Закладання поганої архітектури на початковому етапі розробки. Для цього може бути багато причин. Ми можемо бігти галопом для того, щоб показати mvp клієнту, або мати мету швидко релізнути стартап до закінчення бюджету. Можливо, ми розраховували на невеличкий проект з мінімум залежностей, а він вже переріс своє. Можливо, розробникам на етапі планування бракувало досвіду, щоб передбачити можливі проблеми та розширення. І тим не менш, маємо що маємо - архітектура не може підтримати проект. Як цього можна запобігти? Впроваджувати гарну архітектуру з перших днів проекту відповідно до вимог і бачення майбутнього. Тут важливо памʼятати про баланс. Overengineering може завдати шкоди продукту так само, як і underengineerin. Ми кажемо про мінімальну архітектуру, яку в подальшому можна буде рефакторити і екстендити.

2. Людина, на якій «тримався» проект, іде з компанії. Умовний Джеймс був єдиним носієм інформації про продуктові рішення, технічні деталі, блокери та костилі на проекті. Коли він іде, поточні та нові розробники просто не можуть тягнути, бо не мають технічного/продуктового розуміння. Через те, що в руках Джеймса концентрувалося так багато «власті», він частенько міг пушити нечитабельний код багфіксів, в нього могли бути magic numbers, і тд. Як цьому запобігти? Уникати концентрування інформації в руках однієї людини. Контролювати стан кодбази командою. Запроваджувати knowledge sharing сесій та підтримувати документацію.

3. Реалізація фічей в рамках дуже щільного дедлайну. На будь якому проекті був(буде) період, коли треба швиденько релізнутися під продуктовий бум (або через інші причини). Тоді ми не маємо час на гарний код, в нас основною метою є економія часу. Для запобігання погіршення коду в таких випадках ми завжди повинні закладати планінг для рефакторингу. Не просто обіцяти собі це зробити, а мати конкретні дедлайни і відповідальну особу.

4. Нові розробники пишуть код без розуміння особливостей архітектури. Тут запобіжними методами є knowledge sharing, гарні pr review, а також атмосфера в команді, де людина почуває себе захищеною для питання і визнання помилок.

Які ще фактори погіршення коду спадають вам на думку?

Ні я нікуди не пропав.

Насправді я закінчив курс навчання (35 днів), приїхав до частини за відношенням (так відношення спрацювало) і вже зробив перший невеличкий виїзд в поля (тільки повернувся).

Як бачите - живий здоровий, хіба спати хочу, але цю проблему я вирішу.

Єдиний мінус - це вчорашній обстріл - тут слів немає русня просто не люди та й усе. Якщо це прийняти - все стає трохи зрозуміліше. Ну а хто може допомогти - долучайтеся.

По службі багато розповісти не можу - все таки це паблік. Єдине що - думаю скоро відкрию доступ до своїх заміток з учєбки для всіх, має бути корисно.

Ну і скоріше за все скоро буде кілька зборів. Наперед скажу - о 3 ночі, навіть влітку у флісці може бути холодно...

Тримайтеся пані та панове, обов'язково бережіть себе і вірю що скоро почуємося)

Всіх обійняв, ваш зам по мишах!

П.М. Будете йти в ЗСУ - кота не беріть, дійсно видають, перевірено особисто.