Зібрав відео з курсу #NextJS (відео манюні, можна дивитися за кавою)

1. Next.JS - що це таке і чим відрізняється від React
2. NextJs - створюємо свій перший застосунок [Практика]
3. NextJs, компоненти та їх види
4. NextJs, компоненти та їх види (Практика)
5. NextJS та справжні клієнтські компоненти
6. NextJs та стилізація - CSS, CSS Modules, SCSS, CSS in JS
7. Next.JS та Клієнтський роутинг
8. NextJS - клієнтська частина від А до Я прямий ефір, велике відео
9. NextJs та API
10. Next.JS, API, та Monobank прямий ефір, велике відео

Весь плейліст

@reactbeginners

Чернігів, мої співчуття. Просто немає слів 😢

Що таке CORS?

Якщо коротко - це запобіжний механізм браузера, який не дозволяє вам отримати відповідь (а іноді і зробити запит) з іншого домену. Розшифровується CORS як: Cross Origin Resource Sharing

Простий приклад як працює CORS

* Я зробив веб сторінку та виклав її в інтернет, наприклад https://drag13.io
* З цієї сторінки я роблю GET запит на сторінку https://stackoverflow.com
* Запит проходить успішно і сервер повертає браузеру відповідь.
* Браузер бачить, що домени різні і перевіряє відповідь серверу на наявність спеціального заголовку: Access-Control-Allow-Origin. Якщо його немає, або його значення не дорівнює домену клієнта, браузер кидає вам абстрактну помилку Failed to fetch

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

Для того щоб зробити запит на інший домен, вам потрібно аби сервер повертав спеціальні HTTP заголовки::

Access-Control-Allow-Origin - для ідентифікації дозволених доменів
Access-Control-Allow-Methods - для ідентифікації дозволених HTTP методів
Access-Control-Allow-Headers - для ідентифікації дозволених заголовків
Access-Control-Max-Age - для того аби знати скільки часу не турбувати сервер повторно.

Для простих запитів - наприклад GET, POST, HEAD без додаткових заголовків достатньо повернути Access-Control-Allow-Origin зі значенням дозволених доменів через кому, або з * (але * використовувати не варто)

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

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

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

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

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

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

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

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

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

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

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

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

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

@reactbeginners

Про #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

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

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

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

Про TypeScript

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

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

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

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

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

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

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

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

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

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