Зібрав відео з курсу #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 є супертипом будь-якого іншого типу.

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

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

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

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

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

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

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