Коротко про декомпозицію коду в #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);

Обкатка БТРом, стрільби з різних положень, чистка зброї, медицина, пересування і все таке інше - десь так проходить зараз моє навчання.

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

Що радує - інструктори розуміють що у нас тут не рембо зібралися і до фізухи та вправ ставляться адекватно, бо вік тут дуже різний, самі розумієте.

А от з менеджереми є нюанси. Я б дорого (дуже дорого) дав би за толкового зубатого менеджера на певну посаду.

На react часу не вистачає але jsweekly поглядаю. А ще пробую писати нотатки на телефоні, може потім опублікую. Так і живемо.

А що ви тут без мене робили?

💛 Polyfilling vs Transpiling

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

Як polyfilling так і transpiling ми використовуємо для того, щоб старіші браузери (environments) могли використовувати нові фічі js, навіть якщо в них вони ще не підтримуються.

У процесі поліфілу ми в коді емулюємо API, ніби вони вже є реалізованими. Наприклад:

if(!Array.prototype.with) {
Array.prototype.with = blah-blah
}

Таким чином ми наче заповнюємо дири нестаючих API прямо в нашому коді.

Транспіляція працює дещо інакше. Транспілятор аналізує “сучасний” код і переписує його таким чином, щоб він відповідав старішим стандартам, які підтримуються більшістю браузерів. Наприклад, вхідний код написаний на ES6+ буде перетворений на ES5 (в цьому може допомогти Babel або інші транспайлери).

Харків - мої співчуття. русня не люди.

Хто бажає підтягнути трохи свій рівень #React раджу подивитися наш плейліст - React Code Smells: https://www.youtube.com/playlist?list=PLx9b8ngesbGG_kYzCcPBg8F96f9mhhN-e

Також до нього є відкритий репозиторій з прикладами.

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

Як код стає поганим🧑‍💻

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

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

Дискдеймер: код (процеси, планінг, etc) ніколи не будуть ідеальними. Будь яка код база з часом стане легасі. Тому ми кажемо про покращення, а не про те, щоб зробити ідеально.

Тож які фактори впливають на погіршення коду:

1. Закладання поганої архітектури на початковому етапі розробки. Для цього може бути багато причин. Ми можемо бігти галопом для того, щоб показати mvp клієнту, або мати мету швидко релізнути стартап до закінчення бюджету. Можливо, ми розраховували на невеличкий проект з мінімум залежностей, а він вже переріс своє. Можливо, розробникам на етапі планування бракувало досвіду, щоб передбачити можливі проблеми та розширення. І тим не менш, маємо що маємо - архітектура не може підтримати проект. Як цього можна запобігти? Впроваджувати гарну архітектуру з перших днів проекту відповідно до вимог і бачення майбутнього. Тут важливо памʼятати про баланс. Overengineering може завдати шкоди продукту так само, як і underengineerin. Ми кажемо про мінімальну архітектуру, яку в подальшому можна буде рефакторити і екстендити.

2. Людина, на якій «тримався» проект, іде з компанії. Умовний Джеймс був єдиним носієм інформації про продуктові рішення, технічні деталі, блокери та костилі на проекті. Коли він іде, поточні та нові розробники просто не можуть тягнути, бо не мають технічного/продуктового розуміння. Через те, що в руках Джеймса концентрувалося так багато «власті», він частенько міг пушити нечитабельний код багфіксів, в нього могли бути magic numbers, і тд. Як цьому запобігти? Уникати концентрування інформації в руках однієї людини. Контролювати стан кодбази командою. Запроваджувати knowledge sharing сесій та підтримувати документацію.

3. Реалізація фічей в рамках дуже щільного дедлайну. На будь якому проекті був(буде) період, коли треба швиденько релізнутися під продуктовий бум (або через інші причини). Тоді ми не маємо час на гарний код, в нас основною метою є економія часу. Для запобігання погіршення коду в таких випадках ми завжди повинні закладати планінг для рефакторингу. Не просто обіцяти собі це зробити, а мати конкретні дедлайни і відповідальну особу.

4. Нові розробники пишуть код без розуміння особливостей архітектури. Тут запобіжними методами є knowledge sharing, гарні pr review, а також атмосфера в команді, де людина почуває себе захищеною для питання і визнання помилок.

Які ще фактори погіршення коду спадають вам на думку?

Ні я нікуди не пропав.

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

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

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

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

Ну і скоріше за все скоро буде кілька зборів. Наперед скажу - о 3 ночі, навіть влітку у флісці може бути холодно...

Тримайтеся пані та панове, обов'язково бережіть себе і вірю що скоро почуємося)

Всіх обійняв, ваш зам по мишах!

П.М. Будете йти в ЗСУ - кота не беріть, дійсно видають, перевірено особисто.

💛 Скоуп та його види

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

const x = 1; 
const fn = () => {
const y = 2;
};

if(true) {
const z = 3;
}

На цьому коді зображено три види скоупу в js.

💛 Змінні "x" та "fn" є глобальними, вони оголошені в глобальному скоупі (global scope) і доступні в будь-якому місці програми.

💛 Змінна "y" оголшена в скоупі, який був створений функцією fn (function scope), вона є “локальною” для функції fn і доступна тільки в її контексті.

💛 Змінна "z" доступна тільки в if блоку (block scope).

Якщо ми спробуємо дістатися змінної 'z' (яка оголошена в скоупі if блоку) зовні цього блоку - отримаємо reference error. Якщо ж ми спробуємо дістатися змінної 'x' у функції fn, вона буде доступна, незважаючи на те, що не була оголошена в скоупі функції. Для цього в js є механізм variable lookup.

Const x = 1; 
Const fn = () => console.log(x)

Спочатку js подивиться в скоуп функції fn і намагатиметься знайти 'х' тут. Коли не знайде, js буде дивитися на один скоуп вище (на прикладі це вже глобальний скоуп). Тут він знайде змінну 'х' та виведе її в консоль.
Такий механізм доступу до змінних називається лесичний скоупом (lexical scope). Тобто доступ до змінної визначається місцем її оголошення в тексті програми. Лексичний скоуп визначається на етапі компіляції програми.

Для загального розвитку, є ще альтернатива лексичному скоупу - динамічний скоуп. В ньому доступ до змінної визначається не місцем в коді, а місцем виклику. Динамічний скоуп визначається на етапі виконання програми. В js не реалізовано динамічного скоупу, приклад його реалізації є, наприклад, в мові perl.

Я вам ще не надоїв?

Якщо ні, то як і обіцяв - лінк на канал про моє БЗВП, наразі він публічний, можна репостити. Там є інформація і про підготовку, і про проходження деяких моментів, хоча й не всіх. Читайте, хто планує доєднуватися до ЗСУ буде корисно.

По зборах - поки на паузі, бо у Моно виникли питання до мене в зв'зяку з останнім збором на машину (сюди не постив).

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

Коротше зі зборами не все так просто)

А як у вас справи? Реакт ще не забули?)))

Ваш Зампомиш)

Вибираємо систему керування станами

Крок перший - оцінити чи потрібна нам вона взагалі

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

Але, скоріше за все, вам так не буде (С)

Крок другий - оцінити чи можете ви використати контекст

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

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

Крок третій - вибрати стейт менеджер під задачу.

Якщо ви все таки впевнені що вам потрібна система керування станом, не беріть першу ліпшу про яку почули.

Наприклад redux чудовий якщо вам потрібна можливість відміняти зміни, або у вас вся команда працює саме з ним. MobX, в свою чергу, зручний для тих хто звик до ООП підходу (раджу спробувати). А #tanstackquery (#reactquery) буде корисним якщо у вас багато мережевих запитів.

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

П.М. Спонсор цього посту - мій увал,
Ваш зампомиш)

Про код

Розуміти чужий код - це навичка, яка є такою ж важливою (або ще й важливішою) ніж навичка писати свій.

Чому це важливо:

1. У більшості випадків, ви не будете писати код з нуля. Скоріш за все ви прийдете на вже початий проект, де треба буде багато розбиратися в коді.

2. Скоріш за все, ви не будете працювати єдиним розробником в команді. Так чи інакше, вам прийдеться мати взаємодію з кодом іншої людини.

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

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

Ця навичка ніколи не втратить своєї актуальності і стане в нагоді на будь-якій інженерній посаді.

І знову на ті ж граблі

Пані та панове, ну будь-ласка, будь-будь-будь-ласочка 🙏

Якщо ви пишете на веб сторінці телефон - ну не пишіть його текстом, або через click(). Завжди застосовуйте tel і дублюйте номер в тексті a:

<a href="tel:+380661488111">+380661488111</a>

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

Детальніше про це, а також про інші протоколи (mailto, sms та кастомні) можна почитати тут

П.М. У мене все умовно добре, можливо на наступному тижні буде збір, сьогодні побачимо.

Минуло два цікавих тижні.

Було трохи #React, ASP.NET, #MsSQL, все це в #docker і на локальний сервак - це був вже наш перший реліз кандидат). Доречі, взяли #Zustand для керування станами, поки політ нормальний.

Окрім цього був С++, cmake, linux і procmon бо дехто readme писати не вміє від слова зовсім. Коли я казав що я full-stack я не зовсім це мав на увазі але що вже поробиш. Шкода що все писати не можна, але скажу так - у нас два 3D принтера)))

Паралельно я захворів (температура, горло і всяка така штука) і поклав собі нову підлогу)

П.М. Після перемоги я в резюме додам рядок:

Писав про React в Збройних Силах України

А ви тут як?

Я тут трохи облажався, але cordova схоже мене спасе, та давайте спочатку (багато тексту)

UPD: Переїхали на capacitor

Зробили ми нещодавно апку (react, vite, react-router-dom) одна з основних фіч якої була у максимально простій доставці до кінцевого користувача. Буквально: скинув ОДИН файл і все працює з коробки, без танців з бубнами - відкрив в Chrome і маєш щастя. А HTML, ну начебто, як раз саме про це, то ж в теорії ідея була зашибісь)

То ж ми зробили, протестили під віндою і наче все супер. Залили на android - а там білий екран... Як так? Почали копати, виявилося що react-router-dom не дуже любить коли його запускають на чомусь що не схоже не справжній URL, наприклад content://com.google.android і просто тупо кидає exception, що обвалює весь застосунок на корені.

Але ми то не пальцем роблені, то ж за дві години зробили патч в react-router-dom (може доречі його викласти?) і воно ожило Але тут друга халепа - зображення. Зображення тупо не працюють хоч ти трісни.

Чотири години шаманізму, кави, коли, матюків і ні... Не працюють. Що робити?

Вирішили пакувати в APK. Першою ідеєю було взяти #reactnative. Тут #React і там React - все наче сходиться. Але ж ні, у react-native розмітка йде власними компонентами, а у мене оці всякі div, span, article і прости нас main з nav...

І тут приходить Cordova яка каже - а давай мені свій HTML а я вже далі якось сама... І ви знаєте - полетіло. Так прийшлось помучитися з установкою android, раз 20 перезавантажити ноут бо на вінді ж PATH не оновлюється одразу, але вчора я залив на телефон APK який працює))

Так там теж є складнощі з підписом, з тим що ЗАСТОСУНОК НЕ ПЕРЕВІРЕНИЙ КИНЬ КАКУ ВІДПРАВ ГУГЛУ НЕ ЧІПАЙ СТРАШНО, але в цілому схоже що це наш варіант.

То ж кому потрібно портувати react в andoid - подивіться в сторону #cordova. Так, вона старенька, але схоже що ще може дати джазу.

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