Коротко про декомпозицію коду в #React (19:00)

Завтра відбуваю на навчання тож на останок тримайте відео про React та декомпозицію, яке виходить сьогодні о 19:00.

Знімав трохи поспіхом, але наче вийшло. Поставте під відео декілька лайків - буду радий побачити що не просто так робив)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Було трохи #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. Так, вона старенька, але схоже що ще може дати джазу.

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

Антипаттерни в #UX для #web розробників

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

- Ігнорувати label та атрибут for
Якщо ми вже заговорили про форму - не забувайте використовувати label та атрибут for або htmlFor в #React. Це дає можливість тицьнути на лейбу і одразу почати взаємодію з інпутом. Для маленьких чекбоксів та радіобаттонів на телефоні - просто must have. Доречі, ще один спосіб зробити життя користувача телефону краще - використовувати атрибут inputMode - дуже гарна штука.

- Span/div замість справжніх кнопок та посилань
Посилання це завжди тег а. Хоча б тому що на ньому можна клікнути середньою кнопкою щоб відкрити у новому вікні. А ще вони обидва мають додаткову поведінку, правильну роль та табаються. Бонусом SEO та доступніть.

- Відсутність префікса tel: в лінках з телефонами
Я про це вже писав але повторю ще раз: дайте людям можливість подзвонити з телефону, а не копіювати цей клятий номер по одній цифрі. Просто зробіть це.

- Автоматичне закриття нотифікацій критичною помилкою

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

- Відсутність індикації тривалих процесів
Ще один антипаттерн який я часто зустрічаю. Користувач натискає на кнопку зберегти і ... нічого не відбувається. Чи пішло збереження, чи сторінка не працює - ніхто не знає. І лише секунд через 20 з'являється черговий тост що все пройшло успішно. А за ці 20 секунд користувач ще раз 10 тицьнув цю кнопочку... В результаті злий користувач і 10 зайвих запитів на сервер.

- Ховати скрол, бо "у користувача стрибає лайаут"
Якщо так робити, то рано чи пізно, на маленьких екранах контент стане не доступним,а користувач нещасливим і, або буде редагувати HTML вручну, як я, або тупо піде з вашої сторінки (ситуація не вигадана). На щастя у нас є css властивість scrollbar-gutter, яка може з цим допомогти. На горе - Safari поки її не підтримує, тому треба городити костилі. Але навіть костилі краще ніж замовник який не зміг нічого придбати, бо його 30 продуктів зсунули кнопку купити за межі екрану.

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

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

Логічний оператор && в #react

Часто* бачу використання логічного && в React для виведення на екран якогось контенту з умовою. Наприклад десь так:

logged && <Greetings/>

І, зазвичай все йде добре, а поки в нашу умову не потрапляє 0. І тоді замість "нічого" ми побачимо 0

Що робити? Або використовувати тернарний оператор разом з null

logged ? <Greetings/> : null

Або, просто перетворити logged на true/false за допомогою !!

!!logged && <Greetings/>

Так і код буде коротшим, і проблем не буде.

П.М. Так, я повернувся з відрядження)
П.П.М. * Ну зараз не часто, але раніше було, це правда 😃

Питання зі світу #React і, якщо дуже не пощастить, співбесіди:

Коли ви не можете використати <></>, а змушені використовувати <Fragment>?

Коротка відповідь:
Тоді, коли нам потрібно використати властивість key, яка не існує в <></>

Довга відповідь:
У React компоненті, може бути лише один нащадок нащадок першого рівня. Але, іноді, нам потрібно їх декілька, і раніше нам доводилося створювати зайвий елемент, просто для групування. Це призводить до засмічення коду та появи зайвих елементів в DOM.

Для того щоб із цим боротися з'явився компонент <Fragment>, який потім спростили до конструкцію <></>. Але ця конструкція не може мати атрибутів, в тому числі key який потрібен під час генерації списків. І ось тут то і може стати в нагоді старий <Fragment:

[].map((user, i) => <Fragment key={i}>{user}</Fragment>);

І тут постає ще одне питання - чому ж не винести це в окремий компонент, на якому ми зможемо використати свій key? Як ви думаєте?

Повернемося до #React. В #reactrouter є цікава можливість - винесення завантаження даних на рівень роута

Це може спростити ваш код оскільки тепер за обробку помилок а також за обробку стану завантаження буде відповідати код роутера.

Якщо виникне помика - буде показаний errorElement
Поки код буде вантажитися - буде показаний hydrateFallbackElement

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

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

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

Початкові налаштування нового #react проекту

Видаліть все зайве - зайвий код, зображення, іконки, тощо.

Передивіться вже встановлені залежності коду і перенесіть в секцію dev ті залежності, що призначені для розробки (eslint, prettier, jest). Це буде корисно коли/якщо ви будете налаштовувати npm audit --omit=dev`

Налаштуйте форматування за допомогою prettier

та одразу застосуйте його з прапором --write. Досить сперечатися про крапки з комами.

Встановіть і налаштуйте лінтер - eslint під себе, або за правилами команди. Наприклад для не використаних змінних я ставлю warning замість error, не так сіпається око.

Встановіть та налаштуйте систему хуків для git - husky. Так ви зможете виконувати будь-які додаткові дії перед/після коміту/пушу. Наприклад ви зможете налаштувати husky автоматично запускати форматування staged коду. Тепер код у всіх і завжди буде виглядати одноманітно і без зусиль.

Напишіть readme - Два речення про що проект, як встановити залежності (навіть якщо це тривіальний npm install бо може бути і yarn install), як запустити dev збірку, та які правила ви налаштували (а в ідеалі ще й чому)

Все, можна плисти далі.

Але якщо хочеться більшого то... це буде в наступному пості :)

П.М. Амеліансе, я пам'ятаю що ти не фанат прітієра, та поки краще не зустрічав)

Отже про конфу.

Тема звісно #React, 18 жовтня, Київ.

Виступати будуть як мінімум Ілля Климов та Сергій Бабіч. Чи я буду - не знаю точно останнім часом було багато роботи, підготуватися просто не встигаю. Можливо буде альтернативний формат, побачимо.

Хто хоче прийти: Промо-код на 10%: FRFB2510
Хто хоче виступити (тех комітет там чудовий) тиць сюди

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

Ваш зампомиш.