🤘Ось такого шматочку коду виявилося достатньо для того, щоб "зламати гугол" чотири роки тому.

Маленький шматочок коду, посилання в e-mail і наша маленька Reflected XSS готова робити дива з вашим акаунтом 😎

А ви кажете що фронтенд то просто формошльопство і нічого там складного немає.😉

@reactbeginners

Людина яка виграла квиток на FwDays так і не з'явилась 😢
Тому квиток їде іншій людині, яка задавала не менш цікаві питання)

П.М. Ну не солити ж мені їх 😉

🐈Корисний прийом для EsLint🐈

😤 Якщо вас бісять помилки від EsLint які, не є справжніми помилками JavaSript, але ви все ще хочете ці помилки бачити - можна виставити їм правило warn замість error. Але тут одразу з'являється проблема - тепер ваш білд (локальний, або на сервері) не "впаде" коли побачить ці помилки, що може бути не бажано.

👉 Для того щоб поєднати переваги обох ситуацій можна зробити наступний трюк:

1. Перейменувати .eslintrc.json в .eslintrc.js
2. Змінити JSON на module.exports
3. Переписати бажане правило наступним чином:

'@typescript-eslint/no-unused-vars': [
process.env.NODE_ENV === 'development' ? 'warn' : 'error',
]

🎉 Тепер, коли ви запустите застосунок для локальної розробки, студія це побачить і порушення цього правила будуть все ще виділені, але вже в якості попередження. Це дасть вам можливість візуально відрізнити справжні помилки, на кшталт не оголошеної змінної, від помилок умовних, які не заважають кодові працювати.

А от коли ви, або сервер, запустить білд, NODE_ENV буде змінена, всі порушення стануть помилками і не дадуть поганому коду потрапити в кодову базу. І всі щасливі 😎

Пішов збиратися, побачимося через декілька днів.

@reactbeginners

❗️Якщо ви тільки починаєте, не йдіть у фулстек❗️

Просто - не йдіть. "Фулстек за 3 місяці" це може й не зовсім шахрайство, але так близько до цього як тільки можна.

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

Проблема в тому, що вивчити хоча б фронт-енд за 3 місяці на пристойному для інтерна рівні то адове завдання яке вимагає від вас та від ментора 200% зусиль. І то далеко не факт що вийде.

А тут ви ускладнюєте задачу навіть не вдвічі, а в тричі чи навіть більше. Ще й, скоріше за все ви будете навчатися в групі, тож увага ментора буде розсоредженою. А потім буде "у мене вже голова розривається", "це якась **** собача*, "що це за айті таке" і інші розчарування.

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

FwDays rocks

❤️ От і пройшла моя перша, за довгий, час офлайн конференція ❤️

Було дійсно класно, конференція вийшла одночасно камерною (всього один трек), але цікавою - коли ти вилазиш зі своєї бульбашки і слухаєш інших людей - приходять нові ідеї та натхнення. А за одну з доповідей мене взагалі гордість взяла - які круті речі роблять наші розробники. Тож я дуже задоволений тим як все пройшло, хоча і стомлений. Дякую @FwDays за організацію та зусилля!

А які у вас враження (якщо хтось був?)

П.М. Після конференції вирішив взяти паузу на два тижні трохи перепочити. Тож певний час у нас тут буде тиша. Але не сподівайтеся, я повернуся і продовжу мучити вас Реактом. Хоча, після доповіді Іллі Клімова, вже й не знаю чи саме Реактом :)

📝Нотатки про доповіді 📝

Бабіч, Про інтерв'ю.
Інтерв'ю це великий біль для всіх. Що робити - ставится відповідально та людяно.

Про react-native. Не дивився, але те що його ще не перебив flutter вже добре.

Про бойлерплейт. CTO чудак на літеру м, який диктує командам типи експорту. Кодогенерація - варіант якщо у вас декілька команд на одному стеку.

Про формошльопство
Фронт-енд складний, треба вчити. Ок, буду вчити.

Про мілтех.
40 людей на місце до них. Продукт крутий, цікава архітектура багатошарового фронт-енд з React. Я б подивився.

Клімов, Про React.
Дуже цікаво. Подивитися rescript, solid, signals. Обережно з NextJs.

Про архітектуру фронт-енду

👉 Сьогодні один з членів нашої спільноти - пан Дмитро буде говорити про архітектуру фронтенд додатків, в тому числі і про React.

Запрошую приєднатися

🤓Є цікаві анонси🤓

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

1️⃣ Моя доповідь про формпошльопів має вийти у формі статті, можливо вже на наступному тижні.

2️⃣ Після доповіді Іллі Клімова - зробив тестовий репозиторій з ReScript та статтю про його налаштування з React. Опублікую вже на цьому тижні. Потім ще зроблю мікроогляд.

3️⃣ Хочу ще подивитися на Solid.JS і також зробити на нього огляд. Але це вже пізніше.

😢 Курс по Next.JS поки стоїть, часткове цьому пояснення - граблі по яким доводиться ходити з Next і їх так званий Own Way.

👉 До речі, про цей Own Way вийшла цікава стаття про це (англійською) - раджу почитати (Дякую Ameliance SkyMusic за те що показав), на яку вже навіть є відповідь, яка також досить цікава. Всім кого цікавить Next з точки зору підходів - дуже раджу прочитати обидві.

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

@reactbeginners

Обіцяна інструкція про React та ReScript

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

Тому, у кого буде трохи вільного часу на вихідних:

* Інструкція
* Репозиторій
* Документація
* Пісочниця

А якщо хто не в курсі то ReScript це функціональна мова програмування майже зовсім без any яка компілюється в JS, має гарну систему типів і цікаві можливості.

Гарних вихідних, бережіть себе і допомагайте ЗСУ.

П.М. Статтю на основі доповіді сподіваюся віддати вже на наступних вихідних

🥹 Не забувайте перевіряти статус код у відповіді сервера 🥹

Давайте подивимось на цей приклад:

fetch("").then(r=>r.json()).catch(console.log)

Що відбудеться, якщо сервер поверне нам відповідь з кодом, наприклад, 500?

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

❗️Але fetch працює не так, тому що в then передається будь-який response, як успішний так і ні. Все інше, в том числі перевірки на успішність відповіді, покладаються на розробника.

✍️Зробити це можна або використавши властивість response.ok яка буде позитивною, якщо статус код серверу буде в проміжку 200 - 299, або перевірити властивість response.status для більш гранулярної обробки відповіді.

Якщо ж на це просто забити, то рано чи пізно ви отримаєте щось накшталт такого:

Unexpected token '<', "<!DOCTYPE "... is not valid JSON

А щоб fetch працював більш прогнозовано, над ним можна зробити обгортку (або використати axios чи інші інструменти де це вже працює):

fetch("/").then((response) => {
  if (!response.ok) {
    throw new Error(response.status.toString(), { cause: response });
  }
  return response;
});

Тепер, якщо сервер поверне вам щось відмінне від 2ХХ - спрацює catch в якому буде код помилки та весь response якщо він вам таки треба.

❓До-речі, як ви думаєте, чому я повертаю саме response, а не response.json()?

@reactbeginners

Чи завищені вимоги до початківців? Якщо так, то чому, а якщо ні то див. п.1.

😎 Запрошую вас на цю середу на живий ефір о 19:00 зі мною та Сергієм Бабічем де ми будемо говорити про складність сучасного фронтенду, та про вимоги, що зараз ставляться початківцям.

Приходьте, буде цікаво, а ще Сергій приготував подарунки та важливий збір!

😍 Дякую всім хто долучився.
❤️ Дякую всім хто донатив (знаю навіть одного переможця з нашого каналу)

Як вам ефір? Які враження?

🔥 Next.JS 14.0🔥

🎉 26 жовтня вийшов мажорний реліз Next.JS v.14. І я вже навіть зібрався зробити на нього відео огляд, але після ознайомлення і деяких експериментів весь огляд можна звести до 🤷‍♂️

Ні, в теорії нові можливості виглядають цікаво:

=> Прискорення на 54% запуску локального серверу та прискорення HMR на 94% (але все ще за прапорцем --turbo)

=> Серверні дії: код який ви можете позначити як такий, що має виконуватися на сервері і оминути процес створення API.

Але на практиці... Прискорення звісно приємна річ, але не критична. А серверні дії ще більше ускладнюють модель застосунку, виглядають як чорна магія та надто обмежені (як на мене)

👉 Єдине що радує це нові навчальні матеріали.

😕 Ось такий вийшов новий мажорний реліз next14, відео огляд якого міг би зайняти 30 секунд.

Всім гарного дня, бережіть себе і допомагайте ЗСУ

@reactbeginners

Уже розпочалася премʼєра 😉 Єслі шо, то це покращена та перемонтована версія стриму, що відбувався цієї середи. А просто зараз триває премʼєра відео, бавлюся з функціями ютуба 😉

Приємного перегляду!

https://youtu.be/02PwesoqG-A

Таки так - подався з нашим каналом #React для Початківців на Першу Премію DOU.

UPD: спочатку треба потрапити в шорт ліст, підтримка вже потім ❤️

Навряд чи зможу виграти, бо конкуренція ну дуууууже важка але точно буде цікаво 🙂

Дякую всім хто приймав та приймає участь!

Принципи побудови структури проекту

👉 Спробував коротко викласти, свій алгоритм побудови структури (не архітектури) проекту (наступний пост)

🤔Можливо вийшло занадто складно і потрібно зробити якесь відео з наочним прикладом.

Тому, якщо вам все зрозуміло - ставте 👍, якщо потрібне додаткове відео - 🤯, а якщо не згодні або є запитання - прошу до коментарів.

ПОСТ НИЖЧЕ
⬇️⬇️⬇️⬇️⬇️

Принципи побудови структури проекту

=> Кожна сторінка знаходиться в окремій теці і рахується окремим незалежним модулем
=> => Якщо компонент використовується виключно на одній сторінці, він лежить в теці цієї сторінки
=> => Інакше компонент лежить в теці яка призначена для загальних компонентів
=> Модулі можуть залежати лише від загальних модулів. Залежність від специфічних модулів не допускається
=> За замовчуванням, компоненти групуються за приналежністю, а не за типом
=> => Якщо компонент потрібен лише для navbar, він знаходиться в теці navbar
=> => Інакше він знаходиться в теці яка призначена для загальних компонентів (проекту або модулю)
=> Групування за типом допускається виключно в загальних модулях
=> Якщо в модулі один компонент використовується в декількох місцях, модуль може мати власний модуль загальних компонентів
=> Загальні компоненти мають якомого менше залежностей і ніколи не залежать від специфічних модулів
=> Для складних проектів, допускається два модулі загальних компонентів - одна для компонентів що не містять бізнес-логіку, інша для тих що містять, але використовуються по всьому проекту
=> Дані правила рекурсивні

➕Під компонентами розуміються будь-які елементи системи - React компоненти, сервіси, класи, тощо.

➕Правила можуть бути спрощені, наприклад, специфічні під модулі можуть імпортувати компоненти з інших підмодулів якщо:

а) Вони обидва належать одному й тому самому модулю ТА
б) Такі імпорти не створюють циклічну залежність, коли А залежить від Б, а Б, свою чергу від А.

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

@reactbeginners