🌳Про структуру проекту - питання для роздумів🌳

🔨 Продовжуємо працювати над відео про структуру React проекту і в зв'язку з цим - пропоную подумати над наступним питанням:

❓Маємо проект, який складається з двох сторінок - main.page.tsx та buy-product.page.tsx. В Main сторінці є:

a) компонент H1 - який відмальовується як заголовок
б) компонент SuccessText - текст зелено-ядучого кольору який показується у випадку успішного сабміту форми зворотнього звя'зку.

Сторінка buy-product імпортує обидва ці компоненти і використовує їх для того щоб:

а) відмалювати заголовок першого рівня
б) відмалювати спеціальну ціну за товар. (приклад на скріншоті)

❓В задачі питається: які помилки я допустив з точки зору структури проекту і як їх виправити?

Відповідь опублікую вже завтра

П.М. Хтось помітив пасхалку? 😀?

@reactbeginners

🌲Відповіді та пояснення. Частина перша.🌲

😎 Сподіваюся що ви добряче поламали вчора голову. Тепер давайте розбиратися. Тексту багато, тому буде дві частини.

Першу помилку ви знайшли досить просто і це дуже добре. Але давайте її все ж таки розберемо для всіх:

Помилка: Прямий імпорт в buy-product.page.tsx. з main.page.tsx., або, якби б я відповідав на співбесіді, порушення принципу low coupling (низької зв'язності)

Проблема: Суть проблеми полягає в тому, що сторінка buy-product починає щось знати про код, до якого він не має жодного стосунку - сторінку main. На практиці, це призводить до того, що коли сторінка main буде перейменована, переміщена, відрефакторена - вам доведеться вносити зміни і у сторінку buy-product. Якщо ви випустите це з уваги - отримаєте баг. Ще одна проблема в тому, що, оскільки H1 належить до main, то розробники будуть думати що вони можуть вільно змінювати H1 відповідно до потреб main. Це означає, що рано чи пізно, заголовок на сторінці buy-product не очікувано зміниться і ми отримаємо ще один баг.

Вирішення: Вирішити цю проблему просто - достатньо винести H1 в окрему теку, яка призначена виключно для коду, який можна використовувати всім, наприклад shared. Цей підхід вирішить одразу дві проблеми. По-перше, ми відв'яжемо buy-product від main, а, по-друге, факт знаходження компоненту в shared буде сигналізувати всім що змінювати цей компонент потрібно з обережністю - він загальнодоступний.

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

Очевидно що зміні на main не мають впливати на інші сторінки, а от зміни в shared - мають.

Друга помилка в наступному пості...

П.М. Так мою пасхалку і не знайшли) Наступного разу зроблю приз за її знаходження)

@reactbeginners

🌴Відповіді та пояснення. Частина друга. 🌴

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

Помилка: Неправильне перевикористання коду, а саме компоненту SuccessText. Або, якщо по-розумному, порушення принципу DRY.

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

Вирішення: Скопіювати компонент SuccessText в теку buy-product і назвати його ProductPrice. Таким чином ми отримаємо незалежний компонент ще й з логічною назвою. Ось так усе просто. 🙂

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

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

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

А ви бережіть себе і скоро побачимось.

@reactbeginners

👥Принцип сильної згуртованості, або High Cohesion👥

Про Low Coupling ми вже поговорили, тепер давайте доб'ємо його пару - принцип згуртованості.

Насправді цей принцип дуже простий і найлегше його пояснити на наступному прикладі:

👉 Уявіть що ви придбали собі комп'ютер з доставкою додому. Приходити ви ввечері, сповнені надії нарешті повноцінно попрацювати з новим фреймворком diablo iv і бачите наступну картину: Монітор стоїть у великій кімнаті. Звідти тягнеться довжелезний шур до ванної де повішена на стіну материнка. Звідти, до кухні, йде шлейф до накопичувача, і лінія живлення яка напряму підключена до щита поза межами вашої квартири.. А коли ви нарешті сіли попрацювати (ну добре, пограти в старий добрий 1.6), то все згасло тому що ваш сусід (свята людина) побачив незнайомий йому шлейф на щиті і відключив його, про всяк випадок, бо чорт його знає що то за шнур і кому він треба.

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

👨‍💻В програмуванні все працює так само. Елементи, які працюють разом мають знаходитись разом - це і є принцип гуртування. Ще, бажано, показувати на ззовні лише те без чого не обійтись, але це вже інкапсуляція, про яку ми поговоримо пізніше.

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

Бережіть себе і скоро побачимось

Питання:
-Так що, виходить що за цим принципом потрібно H1 тримати біля компоненту сторінки - адже вона його використовує, правильно?

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

Ключовий момент тут - приналежність. Елементи, що належать одній системі живуть разом. Все)
:)

#ReactCodeSmells - стор не для локальних даних.

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

Боротися з цим можна і треба:

1️⃣ По-перше, використовуйте глобальний стор лише для тих даних які потрібні буквально по всьому проекту, наприклад дані користувача, або корзина користувача.

2️⃣ По-друге, діліть глобальні стори на логічні шматки. Далеко не завжди вам потрібен єдиний стор для всіх 217 сторінок. Для прикладу зверніть увагу на слайси в Redux-Toolkit. Та й взагалі мати декілька логічно розділених сторів цілком розумна ідея, навіть RTK на моїй стороні.

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

👉 І наостанок хочу додати - запорука проекту, який росте без особливих проблем - інкапсуляція. Будь-який шматок коду або даних має відкриватися лише за потреби. Будь-який компонент, для своєї роботи, має вимагати лише ті дані з якими працює. Це робить кодову базу простіше для читання та менш вразливою.

Бережіть себе, скоро побачимось.

@reactbeginners

Яке я вам відео готую - аж мені подобається.

👉 Робоча назва: ReactCodeSmells та Redux - поширені помилки під час використання глобального стору.

З прикладами, з мікрозастосунком, з кодом на GitHub. І все це менше ніж за 15 хвилин (ну я сподіваюся).

Як вам таке?

П.М. давно я таку либу не давив)))

Сиджу я значить в укритті (і ви сидіть!), слухаю наше ППО і роблю вам матеріали до наступного React Code Smells про Redux.

Якщо все буде добре, орієнтовно у середу відео вже буде на каналі :)

Бережіть себе, буде й на нашій вулиці свято!

Трирівнева архітектура під час повітряної тривоги

Отакий от вийшов у нас спонтанний, без відео, стрім.

Дивитись не обов'язково, (просто немає на що), а на фоні послухати можна.

Бережіть себе)

❤️Сьогодні у Сергія Бабіча (я думаю всі його знають) день народження, і свій подарунок він вирішив передати на ЗСУ

Давайте йому в цьому допоможемо!

Ну і прийми мої щирі вітання, друже. Час у нас зараз не простий, але ми прорвемося.
Все буде Україна!

https://t.me/toisamyibabich/1183

🛄 React, Redux та поширені помилки під час використання глобального стору 🛄

👉 Відео відзняте, змонтоване і буде готовим до вашого перегляду сьогодні, 15.08 о 19:00

👂Вийшло приблизно 16 хвилин, пройшовся по помилкам під час проектування, читання та запису в глобальний стор. Загалом вісім (а для уважних десять) код смелів. Приклади на Redux + Redux Toolkit.

❤️ Буду радий за коментарі, відгуки та поширення!

П.М. А ще у нас нова прев'ю для відео, як вам?

👉 Відео вже готове до перегляду - ТИЦЬ

✍️ Відгуки, коментарі та розповсюдження тільки вітаються!

Збір від 🍺BeerJS та Романа Савицького на антидронову рушницю.

❤️ Багато хто його знає, дехто навіть бував у нього на BeerJS в Житомирі.

👉 Давайте допоможемо, залишилось менше 14_000 гривень зі 100_000

#standswithukraine

❤️Ми знову в офлайні - Itera Open Day for Juniors❤️

UPD: Реєстрація закрита, місця скінчилися.

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

Тож я щасливий що ми можемо провести ще одну офлайн подію - Itera Open Day for Juniors

Програма:

1️⃣ Кар'єрний шлях розробника - Олександр Стороха, керівник Itera Ukraine та Itera Poland
2️⃣ Low/NoCode підхід для розробки - Олександр Скачков, керівник відділу розробки Itera Ukraine
3️⃣ Як писати гарний код - Віталій Рубан - (ну це, власне, я)

І, звичайно, піцца та нові корисні знайомства!

Деталі:

Дата: 30 серпня 2023
Час: 10:30 – 14:00
Де: Київ, вул. Ярославська, 58

👉 Реєструватися тут

😂Я подивився DemolitionRanch і що я хочу сказати😂

1️⃣ Вони круті і особливо крутий у них підхід до відео, - хлопці просто кайфують від того що роблять. Це дуже надихає.

2️⃣ Я таки надихнувся і завтра планую зробити ефір #React_Ranch. Cпробуємо навантажити рендер реакту і подивитись скільки і чого він зможе витримати )

👉 Так що чекаю вас завтра (22.08) на прямому ефірі о 19:00. Лінка теж буде вже завтра.

Бережіть себе, скоро побачимось)

П.М. Хто не прийшов - той не побачив ;)

Будемо експерементувати з React в прямому ефірі

В програмі:

👉1000 звичайний каунтерів
👉 Типу екран в екрані
👉 (Голосом диктора в боксі) - Гіііііпееееркуууб!

Побачимо хто здасться раніше, React чи Chrome 😆

Ставте нагадування щоб не пропустити!

😅 Все таки вийшло трохи важкувато😅

Сама ідея мені відверто сподобалася, ось так пробувати і дивитися на результат дуже цікаво. 10_000 батонів я до цього на сторінку ще не ставив).

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

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

Дякую за відгуки!

Тримайте лайфак

Ми, на проекті, зараз переходимо на strict mode в TypeScript і в мене зараз в консолі більше 500 попереджень. Власне їх так багато, що я навіть не можу їх всі прочитати щоб виправити. Але є простий лайфак - спрямувати вивід з консолі у файл:

npm run type-check > ts.txt

Ключовий момент тут оператор виводу > і назва файлу куди піде запис. Так само можна робити з лінтером, тестами і будь-чим що виводить дані у консоль.

Спробуйте самі:

echo 'hello world' > file.txt

Працює з cmd, powershell на Windows!

П.М. Лайфак № 2 - використовуйте striсt mode з самого початку, щоб не страждати як я 😃

@reactbeginners