Free React For Beginners

Починаємо за 5 хвилин!

Про пет проекти - їх потрібність, як обирати тему і як довести все до кінця - поговоримо вже завтра, 28.01 о 19:00 в прямому ефірі на ютубі

Приходьте, буде цікаво. І завжди вдячний за поширення 😉

П.М. Буду вдячний якщо пошерите в LinkedIn

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

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

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

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

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

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

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

Подкасти повертаються! Уже цього четверга відбудеться запис випуску на тему "Хто такі, курвамать, ті синьйори, як їх відрізнити від нормальних людей і чи варто ломиться в синьйори усім поголовно".

А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.

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

ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)

23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00

.

Анонс прямого ефіру 🤩

Мені дали відпустку, так що якщо нічого не станеться то:

Коли: 28.01.24, о вівторок, о 19:00 (через 10 днів)
Де: Ютуб, не забудьте підписатися
Про що: Пет проекти, як доводити їх до кінця і чи потрібно це взагалі.

Буду вдячний за поширення і всіх чекаю.

П.М. Я ж казав що буде нове відео :)

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

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

logged && <Greetings/>

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

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

logged ? <Greetings/> : null

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

!!logged && <Greetings/>

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

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

SOLID частина 1

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

Перший принцип - SRP (single responsibility principle). За цим принципом, в класа (функціїї, модуля і тп) повинна бути тільки одна зона відповідальності і одна причина для змін.

Розглянемо приклад:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  getUserInfo() {
    return `Name: ${this.name}, Email: ${this.email}`;
  }
}
class NotificationService {
  static sendEmail(email, message) {
    console.log(`Sending email to ${email} with message: "${message}"`);
  }
}

const user = new User('Alice', '[email protected]');
console.log(user.getUserInfo());
NotificationService.sendEmail(user.email, 'Welcome to our platform!');

В коді можемо подивитися невеликий приклад SRP в дії. Ми маємо бізнес задачу - реєструвати юзера і відправлять йому імейли. Початково під час розробки є бажання інкапсулювати цю фічу просто в один клас (функцію). Тобто юзер би і дані юзера записував і імейли відправляв. Але це порушує SRP. По перше, в User більше однієї зони відповідальності (і юзер і імейли). По-друге, в нього більше однієї причини для зміні - щось змінилося в логіці реєстрування юзера або змінилися реквайременти для емейлів. Розділяючи це на два класи, ми дотримуємося SRP. Можна ще створити RegistrationService який би керував процесом реєстрації за допомогою цих двох класів.

Антипатерном принципу Single Responsibility є God Object. Це коли один клас (об’єкт) знає про всю логіку великої фічі/додатку.

Я на свята буду скоріше за все зайнятий, а мені є що сказати - то ж не буду стримуватися.

По-перше. Дякую. Дякую спільноті та особливо тим хто прямо допомагав в цьому складному році - @babich_ss, @fwdays, Skelar, @olenitut та інші. Ви допомогли тоді, коли це було потрібно, а це найбільш цінно. То ж дякую ще раз, вірю що ще зустрінемося за келихом кави, просто трохи пізніше.

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

Для мене початок війни асоціювався з піснею Меч Арея. Сильна пісня про людей що стали на захист своєї сім'ї та країни. Але, нажаль зараз це більше схоже на Sleeping in The Cold Below, - пісню прощання.

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

На цьому у мене все, всіх обнімаю, побачимося потім,
Ваш зампомиш

П.М. Коли буде трохи вільного часу - запишу вам нове відео на ютуб, вже знаю про що.

Пропоную вирішити класичну інтервʼю задачку по тому, як працює контекст в javascript

Ваші відповіді, та (важливо) пояснення чому так працює пишіть в коменти)

HTTP та його версії 🌐

HTTP (Hypertext Transfer Protocol) - це протокол, що є основою передачі даних у WEB. В цьому дописі пропоную трохи розібратися в його еволюції.

🌐 HTTP/0.9

Найперша версія HTTP була створена за ініціативи Тіма Бернерс-Лі. Насправді, в неї в той час не було номера, але з часом до неї стали звертатися як до версії 0.9. У HTTP/0.9 не було хедерів, статус кодів, а єдиним можливим форматом файлів для передачі був HTML. Запит складався з однієї строчки, єдиним доступним методом був метод GET. Респонс містив в собі тільки файл, що було запитано.

🌐 HTTP/1.0

1.0 була націлена на усунення лімітацій попередньої версії. Тепер при респонсі ми стали отримувати статус коди, що дозволило браузерам реагувати не них належним чином. З’явилися хедери, що зробило можливим уніфікацію передачі метаданих. Також завдяки появі хедеру ‘content-type’ стало можливим передавати не тільки файли типу HTML.

🌐 HTTP/1.1

Це перша стандартизована версія HTTP протоколу. Крім цього, вона впровадила декілька важливих змін. Ми отримали змогу мати keep-alive connection, pipelining, а також розбиття респонсу на чанки, що знижувало затримку в комунікації. Клієнт і сервер могли домовитися, який вміст обмінювати (мова, кодування, тип). HTTP/1.1 був відносно стабільним протягом 15 років.

🌐 HTTP/2

Основні зміни, впроваджені в рамках цієї версії, були спрямовані на перформанс. Потокол став бінарним, а не текстовим як в HTTP/1.x, що дозволяє впроваджувати вдосконалені методи оптимізації. Завдяки його мультіплексійності, паралельні запити можуть виконуватися через одне з’єднання. Також тепер ми стали стискати заголовки, що усуває дублювання та зменшує обсяг переданих даних.

🌐 HTTP/3

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

Чи потрібно вчити усі ці сортування, структури даних, типові алгоритми? Я ж на роботі не буду писати квік сорт! Краще вивчу Реакт, хіба мені не вистачить?

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

Та це не так:

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

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

По-треті - вони універсальні. Сьогодні ви пишете фронт-енд і вони працюють. Завтра ви пишете бек - вони працюють. Після завтра доведеться програмувати мікроконтролер - і вони теж працюють.

React зміниться на щось інше, а базові речі залишаться на завжди.

Тож відкривайте LeetCode або CodeWars - вперед, вам сподобається)

В житті неважливий сигнал GPS, якщо не один ти рюкзак свій несеш (С) Кузьма Скрябін

Дякую друзям за допомогу нашому підрозділу в ці не легкі часи.

Дякую @fwdays, @babich_ss, Skelar, Itera та всім небайдужим хто допомагає нам зі зборами. Без вас би було набагато важче.

Всіх обіймаю і скоро побачимось)

П.М. Живий, здоровий, задовбаний мультізадачами, але продовжуємо працювати на користь Україні.
П.М.М. Пишу код на ПІТОНІ 🤪

Merge sort (сортування злиттям)


Переходимо до більш просунутих алгоритмів сортування. Merge sort є одним з найшвидших алгоритмів сортування з time complexity O(n log n) - найкраща, що ми маємо наразі для сортування універсальних датасетів (кращу average time complexity можуть мати алгоритми, які працюють тільки з окремими типами даних, найчастіше з числами, але це нам наразі не так цікаво).

Merge sort працює за принципом розділяй та володарюй (divide and conquer). Перше припущення, яке ми тут робимо - датасети(масиви), що мають один або нуль елементів завжди є сортованими. Тобто isSorted([]), isSorted[2], isSorted[‘g’] завжди є true.

Відповідно нашою задачею є розділити великий масив на підмасиви з сортованих елементів і потім рекурсивно змерджити ці масиви в один сортований.

Розділення на масиви має time complexity O(log n). Злиття двох сортованих масивів в один сортований - це луп з O(n). Звідси маємо загальну time complexity mergeSort O(n log n).

Код: https://codepen.io/olenitut/pen/OJKaBYN?editors=0011
Стаття з візуалізацією процесу: https://www.geeksforgeeks.org/merge-sort/

Алгоритми сортування: level easy

Наступні декілька дописів поговоримо про сортування. Конкретно в цьому пропоную зосередитися на найбільш інтуїтивних і легких для розуміння:

1. Selection sort. Алгоритм простий: ми знаходимо найменший елемент в масиві і вставляємо його на поточний в ітерації індекс. Big O: time complexity - O(n2), space complexity - O(1);
Код: https://codepen.io/olenitut/pen/qBeQPxJ?editors=0011


2. Bubble sort. При кожній ітерації порівнюємо два сусідні елементи масиву, якщо вони не сортовані між собою - міняємо їх місцями. Це гарантує, що при першій же ітерації “максимальний” елемент масиву буде в правильному місці (звідси назва - він ніби спливає). Відповідно в наступних ітераціях “сплиті” елементи не треба перевіряти. Також, гарною оптимізацією для бабл сорта є вихід з нього, якщо при попередній ітерації не був змінений жодний елемент. Big O: time complexity - O(n2), space complexity - O(1);
Код: https://codepen.io/olenitut/pen/eYqQGLV?editors=0011

3. Insertion sort. Тут ми тримаємо ліву частину масиву сортованою. При першій ітерації ми вважаємо, що перший елемент масива вже відсортований. І тепер нам треба просто в правильне місце вставити (звідси назва алгоритму - insertion) другий елемент. Як наслідок в нас ліва частина масиву з 2-х елементів є відсортованою, і нам треба вставити на правильне місце третій елемент. І так до кінця масиву. Big O: time complexity - O(n2), space complexity - O(1);
Код: https://codepen.io/olenitut/pen/ZEgmXmv?editors=0011


Візуалізовану версію можна знайти у цій статті: https://medium.com/@nisfari/sorting-algorithm-bubble-sort-selection-sort-insertion-sort-fd6dadea3d1e

Побував сьогодні на DevChallange, де мене навіть виперли на сцену з промовою.

Згадав старі часи, зрозумів що сумую за конференціями та виступами. Ну та нічого, думаю буде у мене ще можливість для вас виступити з гарною доповіддю.

До-речі, якби раптом таке диво сталося в не далекому майбутньому - про що вам би було цікаво послухати?

Ваш ЗамПоМиш)

Що трапляється, коли ми клікаємо на лінку?

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

Спробувала максимально розкрито і водночас компактно відповіcти на це запитання в доці. Що б ви ще добавили?

Ледь не забув - там @babich_ss зробив стрім про CSS Grid на якому збирав для нас трохи грошей.

А поки у нього зараз афтепаті після конфи (мені то ще не по чину 🤣) зроблю йому маленьку рекламу :)

А хто бажає - може долучитися до збору, потроху збираємо інструменти та комплектуху на корисну справу і не дивуйтеся опису, життя воно таке, не очікуване)

Був радий трохи повернутися в часи конференцій) Вірю, це не остання. Правда, @FwDays?

П.М. Миші м'яке зло :)

Ну я таки доїхав)

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


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

А так трохи покатався, трохи політав, трохи прочудив (не буду так більше)

Ну і з цікавого, буду пробувати потрапити на конфу React FW Days 19 жовтня. Вони ще й промокод дали. Кому цікаво, програма тут. Доречі вони будуть відкривати збір для мене на наступній конфі. Буде змога приєднуйтесь, бо на своїй зп та премії далеко не їдеш. (дві останні закупки мінус 24 тисячи, і це я ще нічого не купив)

Десь так, десь так.

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

Всіх обійняв, до зустрічі рано чи пізно,

Ваш Зампомиш

Нічого не писав, було дуже багато роботи. Але "наче" основну частину встигли, тож я тут - живий, здоровий, приношу користь)

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

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

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

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

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

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

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

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

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

Про код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♾Ми шукаємо талановитого фронтенд розробника з досвідом від 3 років, який ненавидить окупантів і мріє про нашу перемогу.

Необхідні навички та досвід:
✅Впевнене знання HTML та SCSS
✅Досвід роботи з Figma
✅Навички адаптивної верстки сторінок
✅Бажано мати досвід з React.js

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

🍎Якщо ви готові долучитися до нашої команди, кидайте ваш лінкедін/біханс/ватевер https://t.me/volnov

Долучайтесь до ДрукАрмії та допомагайте захищати нашу країну! 🌟

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

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

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

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