Free React For Beginners

Нічого не писав, було дуже багато роботи. Але "наче" основну частину встигли, тож я тут - живий, здоровий, приношу користь) З цікавого - трохи довелося зануритися в код C++ одного опенсорсу. І там таки побачив наступну річ: Код читається легко та приємно (і це С++), видно що хлопці старалися, проблем з цим немає. А от змінювати код досить важко, і ось чому. Висока зв'язність коду. Клас, який мені треба було правити, може працювати в двох основних режимах А/B, а один з режимів має ще й підрежим B1/B2. І все це реалізовано на if конструкціях, які максимально зав'язані на стан класу. В результаті, для того що щось змінити, ти міняєш сам клас, що впливає на інший функціонал (ще й в не дуже очевидних місцях). В результаті маємо баги та витрачаємо купу часу. Цей антипаттерн називається God Object Як з цим боротися: Діліть код на окремі, маленькі, максимально незалежні модулі, кожен з яких виконує одну і лише одну задачу. Наприклад нам треба відобразити перелік користувачів на сторінці. Все це можна зробити прямо в одному компоненті. Але тоді ми будемо ту саму проблему що я описав вище. Замість цього ми розіб'ємо її на: - Код що відповідає за завантаження - Код що зберігає дані - Код що відображає результат (який теж буде розділений на успішний та не успішний результат) Всі ці модулі не знають нічого про один одного, а тому їх можна умовно безпечно міняти, головне не порушувати інтерфейс взаємодії (що модуль приймає і що віддає). Я б зробив би про це відео, але з часом тотальних ахтунг тому питайте прямо тут, якщо потрібно. Всіх обійняв, побіг стригтися під 4, Ваш зампомиш

Нічого не писав, було дуже багато роботи. Але "наче" основну частину встигли, тож я тут - живий, здоровий, приношу користь) З цікавого - трохи довелося зануритися в код C++ одного опенсорсу. І там таки побачив наступну річ: Код читається легко та приємно (і це С++), видно що хлопці старалися, проблем з цим немає. А от змінювати код досить важко, і ось чому. Висока зв'язність коду. Клас, який мені треба було правити, може працювати в двох основних режимах А/B, а один з режимів має ще й підрежим B1/B2. І все це реалізовано на if конструкціях, які максимально зав'язані на стан класу. В результаті, для того що щось змінити, ти міняєш сам клас, що впливає на інший функціонал (ще й в не дуже очевидних місцях). В результаті маємо баги та витрачаємо купу часу. Цей антипаттерн називається God Object Як з цим боротися: Діліть код на окремі, маленькі, максимально незалежні модулі, кожен з яких виконує одну і лише одну задачу. Наприклад нам треба відобразити перелік користувачів на сторінці. Все це можна зробити прямо в одному компоненті. Але тоді ми будемо ту саму проблему що я описав вище. Замість цього ми розіб'ємо її на: - Код що відповідає за завантаження - Код що зберігає дані - Код що відображає результат (який теж буде розділений на успішний та не успішний результат) Всі ці модулі не знають нічого про один одного, а тому їх можна умовно безпечно міняти, головне не порушувати інтерфейс взаємодії (що модуль приймає і що віддає). Я б зробив би про це відео, але з часом тотальних ахтунг тому питайте прямо тут, якщо потрібно. Всіх обійняв, побіг стригтися під 4, Ваш зампомиш

Антипаттерни в #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 продуктів зсунули кнопку купити за межі екрану. Про що не згадав - зображення однієї якості для всіх пристроїв, заборона виділяти текст та користуватися меню правої кнопки, валідаційній повідомлення які зсувають вниз контент і таке інше. Про це напишу наступного разу. Бережіть себе, допомагайте ЗСУ! Ваш зампомиш.

Вітаю з Днем Незалежності! І дуже сподіваюся що ми не втратимо те що здобуваємо з такими втратами. Не пересеремося усі між собою, не розбіжимося по своїх домівках та не заб'ємо один на одного. І будемо триматися разом. Бо це НАША країна і НАМ тут жити. І коли хтось вимагає хабар - він руйнує нашу країну. Коли хтось бере відкат - він краде у нас з вами. І тільки якщо ми це зрозуміємо, приймемо, будемо виконувати та вимагати виконувати це від інших - тільки тоді у нас є шанс прожити в НАШІЙ країні хоча б ще 10 років. Інакше це все немає сенсу. Dixi.

Я тут трохи облажався, але 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. Так, вона старенька, але схоже що ще може дати джазу. Бережіть себе, допомагайте ЗСУ, Ваш Зампомиш

Минуло два цікавих тижні. Було трохи #React, ASP.NET, #MsSQL, все це в #docker і на локальний сервак - це був вже наш перший реліз кандидат). Доречі, взяли #Zustand для керування станами, поки політ нормальний. Окрім цього був С++, cmake, linux і procmon бо дехто readme писати не вміє від слова зовсім. Коли я казав що я full-stack я не зовсім це мав на увазі але що вже поробиш. Шкода що все писати не можна, але скажу так - у нас два 3D принтера))) Паралельно я захворів (температура, горло і всяка така штука) і поклав собі нову підлогу) П.М. Після перемоги я в резюме додам рядок:

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

А ви тут як?

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

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

А якщо ви думаєте що цей пост писав капітан очевидність, то ні, просто подивіться на картинку цілком адекватного магазину... Скільки у них людей не подзвонило тому що це просто тупо не зручно я навіть не знаю. Якщо хтось знає менеджмент звідти - передайте від мене привіт. Детальніше про це, а також про інші протоколи (mailto, sms та кастомні) можна почитати тут П.М. У мене все умовно добре, можливо на наступному тижні буде збір, сьогодні побачимо.

Про код Розуміти чужий код - це навичка, яка є такою ж важливою (або ще й важливішою) ніж навичка писати свій. Чому це важливо: 1. У більшості випадків, ви не будете писати код з нуля. Скоріш за все ви прийдете на вже початий проект, де треба буде багато розбиратися в коді. 2. Скоріш за все, ви не будете працювати єдиним розробником в команді. Так чи інакше, вам прийдеться мати взаємодію з кодом іншої людини. 3. Якщо ви все ж таки потрапили в ситуацію, де ви єдиний розробник у стартапі з нуля, вам все одно треба буде розбиратися в іншому коді. Наприклад, в сорсах ліби. Або в прикладах на stack overflow. Або читати і розуміти говнокод, що вам видав чат жпт. Тому раджу розвивати навичку читання і розуміння чужого кода: завжди беріть участь в код ревью (навіть якщо вас не звали), читайте код вашої кодбази, розбирайтеся в опенсорсних проектах, які вам цікаві. Ця навичка ніколи не втратить своєї актуальності і стане в нагоді на будь-якій інженерній посаді.

Вибираємо систему керування станами Крок перший - оцінити чи потрібна нам вона взагалі Деяким застосункам система керування станом може бути взагалі не потрібна. Якщо в застосунку не велика глибина, немає значної взаємодії між користувачем та апкою, стан локальний (не потрібен в усьому застосунку одразу) цілком можна обійтися без системи керування станом, а використовувати звичайний стейт. Але, скоріше за все, вам так не буде (С) Крок другий - оцінити чи можете ви використати контекст #react потрібен лише тоді коли у нас є багата взаємодія з користувачем (не робіть лендінги на react, навіть якщо вас просять). Тому скоріше за все дані у вас будуть, і їх треба буде зручно отримувати та змінювати. Але чи потрібна при цьому система керування станом? Якщо дані змінюються не часто, зміни не є особливо складними - можливо вам влаштує звичайний контекст. Так, контекст не є системою для керування станом, а скоріше шиною передачі, але і для роботи зі станом він може стати в нагоді. Подумайте про те, чи варті фічі нової бібліотеки тої складності яку ви додаєте в проект. Крок третій - вибрати стейт менеджер під задачу. Якщо ви все таки впевнені що вам потрібна система керування станом, не беріть першу ліпшу про яку почули. Наприклад redux чудовий якщо вам потрібна можливість відміняти зміни, або у вас вся команда працює саме з ним. MobX, в свою чергу, зручний для тих хто звик до ООП підходу (раджу спробувати). А #tanstackquery (#reactquery) буде корисним якщо у вас багато мережевих запитів. Якщо це все підсумувати - завжди намагайтеся зрозуміти навіщо ви робите той чи інший крок і все у вас буде добре) П.М. Спонсор цього посту - мій увал, Ваш зампомиш)

Я вам ще не надоїв? Якщо ні, то як і обіцяв - лінк на канал про моє БЗВП, наразі він публічний, можна репостити. Там є інформація і про підготовку, і про проходження деяких моментів, хоча й не всіх. Читайте, хто планує доєднуватися до ЗСУ буде корисно. По зборах - поки на паузі, бо у Моно виникли питання до мене в зв'зяку з останнім збором на машину (сюди не постив). Як розберемося - буду відкривати на деякі потреби. При чому є нюанс що не всю номенклатуру речей я можу відкривати, тому буду щось думати. Не знаю навіть. Коротше зі зборами не все так просто) А як у вас справи? Реакт ще не забули?))) Ваш Зампомиш)