Ранок видався відверто паршивим. Сподіваюся усі цілі (

В скарбничку багів та дитячих хвороб Next.JS на page* роутері

Маємо дуже простий React код:

const { query } = useRouter();
return <>
  {query.id ? 'HELLO': 'ERROR'}
</>

Звичайними словами - якщо в URL є id з якимось значенням - виведи HELLO, якщо немає - виведи ERROR

Тепер питання, що буде виведено на екран протягом наступної секунди, якщо ваш користувач зайде на URL:
/?id=test

Спочатку дайте відповідь собі і напишіть у коментарях, а потім заглядайте:

Спочатку виведеться ERROR
Потім екран оновиться і виведеться HELLO

Це відбувається тому, що в Next.JS router має ще один прапорець - isReady, який потрібно перевіряти перед тим як звертатися до роутера. Поки він не ready - там може не бути тих значень на які ви очікуєте. І це відбувається незважаючи на те, що URL та всі дані в ньому вже існують під час обробки запиту на сервері.

* На щастя, в новому app роутері цю проблему вже вирішили. Для цього знадобилося усього 13 мажорних релізів :)

Вибачайте що контент став трохи сухуватим, просто зараз емоційно все це вивозити досить складно.

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

Вірю що все буде добре, треба просто дотягнути.

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

Я не Сергій, цьомік у лобіка то не моє, але обійняти б обійняв.

Бережіть себе!

Хвилинка слабкості минула, пихтимо далі.

Сьогодні о 19:00 виходить третє відео про Next.JS - Мій перший застосунок

В сумі:

Відео № 1 - Вступ до курсу Next.JS
Відео № 2 - Що таке Next.JS
Відео № 3 - Мій перший застосунок

Четверте відео буде в понеділок.

До речі, як вам формат з таких "мікро" відео?

@reactbeginners

Знаєте звідки цей код?

Це "ідеальний" код до якого має прагнути кожен хто бажав працювати в яндексі на болотах

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

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

Але як приклад - це дійсно ідеальний код як робити не треба (за умови, звісно, що ваша посада не мініфікатор-обфускатор)

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

І повірте мені - написати простий код набагато складніше ніж те гівно що на цьому прикладі.

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

@reactbeginners

Знову удар по Харкову 😢. Нажаль, можу висловити лише свої співчуття та підримку. Чи стане від цього комусь легше - я не знаю. Але ви не самі, це точно.

Якщо вас обманула назва директиви use client; - не засмучуйтеся, не ви перші, не ви останні.

Але з цього можна зробити два висновки:

1. Правильні назви дуже важливі. Вони можуть як спростити ваше життя так і суттєво ускладнити. Уявіть собі метод getUserById, який видаляє користувача з БД 😉

2. Вибрати правильну назву складно, навіть досвідченим розробникам. Якщо ви не можете пригадати назву метода, якщо з назви змінної не очевидно що вона робить - перейменуйте, не соромтеся. Ви зробите послугу і собі, і команді.

А ось посилання на відео (виходить в понеділок о 19:00) про те, які види компонент існують в Next.JS та чим вони відрізняються.
@reactbeginners

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

Мене звати Віталій Рубан, я працюю в компанії Ітера на посади front-end tech lead. До цього працював керівником front-end департаменту (не сподобалося) та full-stack розробником. Працював з react, angular, angular.js. Знаю JavaScript, TypeScript, C#, SQL, трохи F# (але давно нічого на ньому не писав). З хмарних технологій - досить багато працював з Azure. Загалом маю десь дев'ять років комерційного досвіду - не можу сказати що це багато, але вже й не так і мало.

Люблю писати технічні статті, виступати на конференціях (коли є на натхнення). Цікавлюся швидкодією, маю тут невеличкий, але цілком практичний досвід. Декілька років співвикладав для НАУ (привіт НАУ). Декілька років був у програмному комітеті JsFest, шкода що він більше не проводиться.

З цікавих моментів - я світчер (юрист у минулому), тому більш-менш розумію тих кому складно змінювати професію. Мені свого часу декілька разів пощастило, але навіть за цих умов перехід зайняв півтора роки частину з яких, щоправда, я програв в Dota2 😅

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

Цей канал було створено на початку повномасштабної війни для підтримки тих хто не довчився або вирішив змінити роботу. Зазвичай я викладаю тут матеріал про React, Front-End та розробку в цілому. Іноді викладаю особисті міркування, бо я все ж таки жива людина і мене хвилює що відбувається навколо. З цієї самої причини тут бувають і збори - ми робимо маленький але теж важливий вклад у нашу Перемогу. Разом з вами ми збирали на грілки, пічки, дрони, авто та ліки і будемо продовжувати далі, відпочинимо після перемоги.

Ще у цього каналу є декілька друзів - Сергій Бабіч, ItJuniors, FwDays, BeerJS Zhytomyr - дякую вам за підтримку!

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

N*M (1/3), або дайте мені 1000 ноутбуків

Сьогодні трохи поговоримо про оптимізацію та складність алгоритму на прикладі магазину з ноутбуками.

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

type NoteBook = {id: number};
type PriceHistory = {entityId: number};

Завдання дуже просте: відобразити ноутбуки разом з історією цін.

Ми можемо зробити це в лоб:

function getNotebooksWithPrice(
    notes: NoteBook[], 
    prices: PriceHistory[]
) {
  return notes.map((notebook) => ({
    ...notebook,
    price: prices
        .filter((x) => x.entityId === notebook.id),
  }));
}

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

Для того, що зібрати усі ноутбуки з цінами нам потрібно зробити наступні кроки:

1. Пройтися по всьому списку ноутбуків (зробити N операцій де N довжина масиву ноутбуків)
2. Для кожного елементу масиву пройтися по всьому списку цін (зробити M операцій для кожного з ноутбуків, де M довжина масиву цін)

Тобто, для виконання цієї красивої функції нам потрібно N*M операцій. (вітаю, ви тільки що оцінили складність алгоритму 😊, яка склала O(N*M))

З практичної точки зору це означає наступне:

Уявімо собі, що наших ноутбуків 100 штук, а історій цін хоча б втричі більше, тобто 300. Отже, нам потрібно для кожного ноутбуку (100 разів) пройтися по всій історії цін (300 разів) що в сумі дає 30_000 операцій, що може й не так і багато, але вже й не дуже мало. А, якщо ще врахувати, що #React, за своєю природою, дуже часто рендерить компоненти заново, то невдало розмістивши цей код ви будете його виконувати постійно, що, звісно ж буде впливати як на швидкодію вашого застосунку, так і на батареї телефонів наших користувачів.

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

Сьогодні у вас в магазині 20 ноутбуків, завтра 120, після завтра 1200 (разом з тими що виведені з асортименту). І функція, яка чудово справлялася зі 120 ноутами, на 1200 почне суттєво "тормозити" ваш UI. А на 2000, коли операцій стане 2_000 * 6_000 = 12 _000_000 на кожен рендер, наша сторінка просто стане колом 😢

Як цьому запобігти?

@reactbeginners

Як цьому запобігти? (2/3)

Для того щоб запобігти такій ситуації існує старий і прекрасний лайфхак - купити кращий комп'ютер - використати Map.

Тобто трансформувати масив сутностей по якому у нас ведеться пошук у словник. Для того щоб знайти елемент у масиві, в гіршому випадку потрібно прочесати весь масив (N операцйі де N довжина масиву). А для словника це умовно одна операція, тобто складність змінюється з N на 1. Що, на попередньому прикладі дає нам 2000 операцій замість 120 мільйонів. Не так і погано?

Реалізувати це дуже просто:

// Перетворимо масив цін на словник цін
// Де ключем буде id ноутбуку
const pricesMap = prices.reduce((acc, price) => {
  const { entityId } = price;
  acc.has(entityId)
    ? acc.get(entityId)?.push(price)
    : acc.set(price.entityId, [price]);

  return acc;
}, new Map<number, PriceHistory[]>());

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

return notes.map((notebook) => ({
  ...notebook,
  prices: pricesMap.get(notebook.id),
}));

Як бачите - не складно. Але розмови, коли ми говоримо про швидкодію, нічого не варті - завжди треба міряти. Тому я зібрав цей код, протестував його на JsBench і вийшло, що перша реалізація на 98% повільніша ніж версія з Map. Якби ноутбуки продавалися з такою знижкою я б купив собі два :)

Так що, тепер переводимо все на мапи?

@reactbeginners

Так що, тепер переводимо все на мапи? (3/3)

Звичайно що ні. Аде дуже навряд ви будете виводити 1000 ноутбуків на одну сторінку. Скоріше за все у вас буде paging або поступове завантаження.

ТОМУ:

Перший крок: оцінити реальну кількість елементів, з якою ви будете мати справу.

Другий крок: порахувати складність алгоритму. Алгоритми зі складністю O(1) (взяти елемент по ключу або індексу) оптимізації не потребують, це й так максимум що можна витиснути. Алгоритми зі складністю O(N) (пошук елементу в масиві) скоріше за все теж можна не чіпати. А от якщо складність зростає до O(N*N), або ще гірше до O(N*N*N) це сигнал що оцінку потрібно продовжувати.

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

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

І останній крок: якщо оптимізувати довелося - залишаємо коментар в якому вказуємо навіщо ми це робили.

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

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

* З тестуванням є нюанс - зазвичай ми тестуємо на комп'ютерах розробників, а вони досить потужні. Тому, якщо не "тормозить" у вас, це не гарантія що не буде проблем у користувачів. Використовуйте CPU throttling в Chrome Dev Tools для більш точної оцінки.

@reactbeginners

Де рендеряться клієнтські компоненти?

Вчора ввечері вийшло наступне відео про види компонентів в Next.JS Відео дуже коротке, присвячено видам компонентів, правилам роботи з ними, перевагам та недолікам кожного з виду.

Запрошую до перегляду та поширення)

Список опублікованих відео наразі наступний:

Відео № 1 - Вступ до курсу Next.JS
Відео № 2 - Що таке Next.JS
Відео № 3 - Мій перший застосунок
Відео № 4 - NextJs, компоненти та їх види

Мій акаунт в twitter закривається:

Сьогодні Елон Маск закликав своїх прибічників звертатися до Сенату США щоб зупинити допомогу Україні. Це настільки мерзенно, що у мене майже немає слів.
Тому я закриваю свій акаунт в Твітері і зроблю все щоб жодна з компаній де я буду працювати, ніколи не мала з ним справу.

Вибачайте за політику, це вже занадто.

https://twitter.com/drag137/status/1757348056943525948

Маск, Маском, але чи існують в Next.JS справжні клієнтські компоненти?

Не буду спойлерити - просто подивіться це відео)

#анонс
Онлайн співбесіда наживо рівня Strong Junior ReactJS з Дмитром Тілугом — переможцем другого випуску нового проєкту "Резюме Ґриль"!

Із провідного спеціаліста в авіаційній сфері до frontend розробника. Дмитро вирішив, що це хороша ідея і після успішної 10-ти річної карʼєри кардинально змінив професію. Не боїться казати “не знаю” на співбесідах та займається прибиранням заради задоволення.

А як ви раптом втомилися від запитань по самісінькому React, то маю вас втішити — готую нові й цікаві питання, тож нагостріть вушка!

***
А таємний експерт цього етеру — з компанії Svitla Systems, глобальної IT-компанії з більш ніж 20-річним досвідом, головний офіс якої знаходиться в Каліфорнії, а операційна діяльність поширюється на більш ніж 10 країн, зокрема США, Канаду, Мексику, Коста-Ріку, Аргентину, Україну і Польшу.

Svitla об’єднує понад 1000 спеціалістів з різних технологій. Серед клієнтів як інноваційні стартапи, так і компанії із Fortune 500.

***
⚡️ Strong Junior ReactJS // Співбесіда наживо // Дмитро Тілуг
⏰ 16 лютого, 19:00
📺 Сергій Бабіч та Дивовижний світ веброзробки

Іноді в Next.JS буває потрібно виконати якийсь код лише на клієнті. Як це зробити?

Перший варіант: застосувати справжні клієнтські компоненти за допомогою прапорця SSR:false та use client; Але це крайній варіант, тому що весь компонент буде виключений із первинного рендеру на сервері.

Другий варіант: виконати цей код в середині useEffect. За загальним правилом, ефекти виконуються виключно на клієнті і ви можете безпечно звертатися до, наприклад, об'єкту window або document. Але цей варіант не спрацює, якщо вам потрібно виконати код до ініціалізації React застосунку.

Тому існує третій варіант:

if (typeof window !== 'undefined') {
  console.log(`HELLO CLIENT`);
}

В середині цього if ви також можете безпечено працювати з DOM API.

А от перевірка накшталт if (window?.addEventListener) вже не спрацює, ви отримаєте помилку ReferenceError: window is not defined

Майте це на увазі.

@reactbeginners

Опублікував я вчора на LinkedIn пост про ноутбуки і зустрів два цікавих коментаря на цю тему

Перший:

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

Другий (мовою оригіналу, вибачайте) про книгу "Грокаємо Алгоритми":

Книжечка конечно красивая, показывает причастность читателя к миру айти и достойна лайка, ну а серьезно, как часто эти алгоритмы нужны в реальной жизни, а не на собеседовании, когда все уже заложено в библиотеках и фреймворках?

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

Так от що я хочу сказати - це дуже далеко від істини.

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

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

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

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

@reactbeginners

Тут один із наших підписників декілька місяців тому зробив свій телеграм канал про JavaScript.

Реклами у нас немає, але порекомендувати дружній канал з корисним тематичним контентом про JS/HTML/CSS думаю буде не гріх. Тим паче це ще й "найкращий" канал, ну як тут втриматися 😅

То ж запрошую до ознайомлення, можливо вам буде корисно)