Free React For Beginners

💛 Polyfilling vs Transpiling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Масив є лінійною структурою даних, тобто всі його елементи йдуть послідовно один за одним. Особливістю масивів є те, що його елементи доступні по їх індексах. У більшості мов програмування, індексація масивів починається з 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);

⚛ “Хук” 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

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

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

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

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

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

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

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. Довгий час дебагу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔵 Типи 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

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

🔵 Типи 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 зробить все можливе, щоб об'єднати розширення.

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

Про TypeScript

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

Що він нам дає?

🔵 Робить розробку безпечнішою, перевіряє код на поширені помилки

🔵 Виконує роль документації, робить можливим автокомпліт в IDE

🔵 Полегшує рефакторинг та дебагінг

Всі ці плюшки ми отримуємо за допомогою типізації - тобто використання типів.

Крім того тайпскрипт впливає на “філософію” розробки. Ви починаєте описувати програму на рівні типів, а не на рівні конкретних значень,  а також одразу думаєте про edge cases.

Наразі багато проектів на Реакт використовують тайпскрипт. Я, наприклад, жодного разу не писала комерційний додаток на реакті без TS, і коли я бачу файли зі строкою ts-nocheck, я знаю, що буде боляче 😅

Тому пропоную доєднатися до поглиблення знань TypeScript у наступних постах

Привіт!
Мене звуть Настя Гордєєва, ви можете мене знати по лінкеду🙂
Я буду підтримувати цей телеграм, поки Віталій недоступний

Я - фронтенд розробниця у Wix, у вільний час веду лінкед, пишу дописи.
Будемо розмовляти про фронтенд загалом і зокрема про реакт розробку

Рада з вами познайомитись)

Про #React19

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

Опишу те що побачив з цікавого:

1. Додали новий хук use - який впереше можна викликати умовно і який мав би дозволяти робити асинхронні запити прямо в компоненті без ефектів. Але поки що не склалося, без кешування промісів не працює. Зате ним можна звертатися до контексту.

2. useTransition тепер буде приймати асинхронну функцію в якості аргументу і віддаватиме статус pending поки виконання функції не завершиться. Згодиться для спрощення усіляких запитів для зміни даних.

3. Депрекейтнули forwardRef, тепер ref можна передавати просто пропсом. Зручно.

3. По аналогії з useEffect додали функцію очистки до ref. Якщо функція, передана в ref, поверне іншу функцію, остання буде викликана під час unmount. Має стати зручніше відписуватися від addEventListener.

4. Спростили роботу з сабмітом форми. З'явився хук useActionState та компліментарний йому хук useFormStatus які дають вам можливість трекати pending статус форми автоматично. Теж про зручність.

5. Покращили відображення помилок, в тому числі для серверних компонентів. Сподіваюся hydration error помилки, коли те що відмалював сервер і те що відмалював клієнт відрізняється, стануть більш зрозумілі в прод режимі.

6. Нарешті додали підтримку метатегів в React - meta, title,link тепер працюють нативно без додаткових бібліотек. (просто пройшло 19 версій). Ще додали можливість додавати preload, prefetch, preinit. Для швидкодії буде корисно.

7. Серверні компоненти стали стабільними (але є важливий нюанс для тих хто робить фреймворки та бібліотеки - їх внутрішній АПІ який потрібен бандлерам не буде слідувати семверу, що звучить досить паршиво)

Як бачите - 19а версія не дуже революційна. Я б сказав вона закладає фундамент для 20ої, яка має бути значно цікавіша.

А яка ваша думка?

@reactbeginners

Поки я тут погоджую що можна і що не варто - напишу ще про розробку

Головне правило гарного коду - простота. Написати складно може кожен. Написати просто і очевидно - це те до чого ми маємо прагнути, коли пишемо код.

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

1. Не нехтуйте класами (навіть в #React) вони дають зручний доступ до стану
2. Пишіть маленькі функції які роблять щось одне - їх простіше підтримувати
3. Дробіть компоненти на підкомпоненти - якщо що їх завжди можна об'єднати
4. Мінімізуйте використання глобальних змінних
5. Запобігайте props drilling (моя хвороба) за допомогою стору та контекстів

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

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

@reactbeginners

Я доєднуюся до лав ЗСУ.

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

Був радий, якщо за ці два роки я зміг стати комусь у нагоді.

Але не прощаємося - вірю що скоро побачимося.

Все буде Україна!