Free React For Beginners

Apple вимикає нормальну підтримку PWA (progressive web app) застосунків, мотивуючи це неможливістю забезпечити безпеку користувачів у випадку використання не сафарі браузера) От так от легким помахом ноги велитенська купа роботи інших людей іде в смітник. Обожнюю підхід еппл. І це стосується нас усіх, один дуже непоганий варіант зробити кросплатофрмений застосунок на react скоріше за все прикриють(

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

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

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

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

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

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

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

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

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

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

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

Іноді в 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

#анонс Онлайн співбесіда наживо рівня Strong Junior ReactJS з Дмитром Тілугом — переможцем другого випуску нового проєкту "Резюме Ґриль"! Із провідного спеціаліста в авіаційній сфері до frontend розробника. Дмитро вирішив, що це хороша ідея і після успішної 10-ти річної карʼєри кардинально змінив професію. Не боїться казати “не знаю” на співбесідах та займається прибиранням заради задоволення. А як ви раптом втомилися від запитань по самісінькому React, то маю вас втішити — готую нові й цікаві питання, тож нагостріть вушка! *** А таємний експерт цього етеру — з компанії Svitla Systems, глобальної IT-компанії з більш ніж 20-річним досвідом, головний офіс якої знаходиться в Каліфорнії, а операційна діяльність поширюється на більш ніж 10 країн, зокрема США, Канаду, Мексику, Коста-Ріку, Аргентину, Україну і Польшу. Svitla об’єднує понад 1000 спеціалістів з різних технологій. Серед клієнтів як інноваційні стартапи, так і компанії із Fortune 500. *** ⚡️ Strong Junior ReactJS // Співбесіда наживо // Дмитро Тілуг ⏰ 16 лютого, 19:00 📺 Сергій Бабіч та Дивовижний світ веброзробки

Маск, Маском, але чи існують в Next.JS справжні клієнтські компоненти? Не буду спойлерити - просто подивіться це відео)

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

Де рендеряться клієнтські компоненти? Вчора ввечері вийшло наступне відео про види компонентів в Next.JS Відео дуже коротке, присвячено видам компонентів, правилам роботи з ними, перевагам та недолікам кожного з виду. Запрошую до перегляду та поширення) Список опублікованих відео наразі наступний: Відео № 1 - Вступ до курсу Next.JS Відео № 2 - Що таке Next.JS Відео № 3 - Мій перший застосунок Відео №4 - NextJs, компоненти та їх види

Так що, тепер переводимо все на мапи? (3/3) Звичайно що ні. Аде дуже навряд ви будете виводити 1000 ноутбуків на одну сторінку. Скоріше за все у вас буде paging або поступове завантаження. Тому Перший крок: оцінити реальну кількість елементів, з якою ви будете мати справу. Другий крок :порахувати складність алгоритму. Алгоритми зі складністю O(1) (взяти елемент по ключу або індексу) оптимізації не потребують, це й так максимум що можна витиснути. Алгоритми зі складністю O(N) (пошук елементу в масиві) скоріше за все теж можна не чіпати. А от якщо складність зростає до O(N*N), або ще гірше до O(N*N*N) це сигнал що оцінку потрібно продовжувати. Третій крок: оцінити чи буде кількість ваших даних рости і до яких меж. Якщо кількість елементів не обмежена - скоріше за все потрібно оптимізувати. Якщо обмежена - переходимо до наступного кроку. Четвертий крок: якщо кількість ваших даних обмежена - уявіть собі найгірший сценарій і протестуйте* поведінку коду в найгірших умовах. Якщо вас все влаштовує - видихаємо спокійно, якщо код "тормозить" - скоріше за все також потрібна оптимізація. І останній крок: якщо оптимізувати довелося - залишаємо коментар в якому вказуємо навіщо ми це робили. Як бачите - не дуже складно (а якщо щось не зрозуміло - я готовий пояснити це ще раз, просто запитайте у коментарях), і ще й наочно демонструє користь таких начебто теоретичних знань в повсякденній розробці. На цьому у мене все, сподіваюся було корисно. І нагадаю, що користь матеріалу я визначаю по лайках :) * З тестуванням є нюанс - зазвичай ми тестуємо на комп'ютерах розробників, а вони досить потужні. Тому, якщо не "тормозить" у вас, це не гарантія що не буде проблем у користувачів. Використовуйте CPU throttling в Chrome Dev Tools для більш точної оцінки. @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. Якби ноутбуки продавалися з такою знижкою я б купив собі два :) Так що, тепер переводимо все на мапи?

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

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

Якщо вас обманула назва директиви use client; - не засмучуйтеся, не ви перші, не ви останні. Але з цього можна зробити два висновки: 1. Правильні назви дуже важливі. Вони можуть як спростити ваше життя так і суттєво ускладнити. Уявіть собі метод getUserById, який видаляє користувача з БД 😉 2. Вибрати правильну назву складно, навіть досвідченим розробникам. Якщо ви не можете пригадати назву метода, якщо з назви змінної не очевидно що вона робить - перейменуйте, не соромтеся. Ви зробите послугу і собі, і команді. А ось посилання на відео (виходить в понеділок о 19:00) про те, які види компонент існують в Next.JS та чим вони відрізняються. @reactbeginners

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

Знаєте звідки цей код? Це "ідеальний" код до якого має прагнути кожен хто бажав працювати в яндексі на болотах А прикол цього коду не в тому, що він виглядає як поріддя мініфікатора, а в тому, що він містить помилку, яку ніхто не помічав, тому що код написаний не руками, а одним місцем нижче спини. Як ви самі бачите, такий код складно читати, ще складніше розуміти і важко підтримувати. Якщо говорити простими словами - це максимально гівняний код з тих що я бачив. Але як приклад - це дійсно ідеальний код як робити не треба (за умови, звісно, що ваша посада не мініфікатор-обфускатор програмного коду) Тому що, друге правило гарного коду полягає в тому, що ви маєте писати максимально простий код. Такий простий як двері, щоб його міг прочитати і мід і джун і навіть ПМ. І повірте мені - написати такий код набагато складніше ніж те гівно що на цьому прикладі. То ж завжди обирайте простоту. Це має бути вашим прагненням. Якщо ви бачите складний код - скоріше за все щось пішло не так. @reactbeginners

Хвилинка слабкості минула, пихтимо далі. Сьогодні о 19:00 виходить третє відео про Next.JS - Мій перший застосунок В сумі: Відео № 1 - Вступ до курсу Next.JS Відео № 2 - Що таке Next.JS Відео № 3 - Мій перший застосунок Четверте відео буде в понеділок. До речі, як вам формат з таких "мікро" відео? @reactbeginners

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