React патерни: Compound та Namespace Components на прикладі проєкту на Vite.

У цьому відео я роблю код ревю проєкту початківця на React і Vite. Особливу увагу приділяю двом популярним патернам у React: Compound Components та Namespace Components. Пояснюю, як їх правильно використовувати, та показую реальні приклади з коду. Якщо ви хочете глибше зрозуміти ці патерни та покращити свій код, це відео саме для вас!
Курс по якості коду зі знижкою - www.rudnyi.dev...
Безкоштовний курс по React - www.rudnyi.dev...
Стати учасником проєкту - dou.ua/forums/...
Посилання на код - github.com/and...
Стати спонсором каналу:
/ @maksymrudnyi
Буду вдячний за підтримку каналу:
Patreon - / rudnyi
BuyMeACoffee - www.buymeacoff...
Mono Bank - send.monobank....
або так - 5375 4114 0505 7287
Приват банк - 4627 0551 1331 6110
Давайте дружити:
Telegram ↣ t.me/maksymrudnyi
Telegram чат ↣ t.me/joinchat/...
INSTAGRAM ↣ / maksym_rudnyi
TWITTER ↣ / maksymrudnyi
FACEBOOK ↣ / travelscode
WEB-SITE ↣ travelscode.com/
GITHUB ↣ github.com/Mak...
Другий TH-cam канал ↣ / travelscode

[@MaksymRudnyi]

Важливо. TH-cam видаляє усі підозрілі або довгі коментарі. Переконайтеся що ваш коментар додано і збережено. Особливо це стосується авторів проєктів, які описують що і чому так зробили. Дуже прикро втрачати цю інформацію, адже на ній інші навчаються.
Також у мене тепер є особистий сайт - www.rudnyi.dev де буде зібрана уся корисна інформація. Курс по якості коду, над яким активно зараз працюю також можна знайти там в розділі Курси або за посиланням www.rudnyi.dev/courses/code-quality

[@and10tech]

Велике дякую за огляд мого проєкту, для себе почув багато корисних порад. Хочу додати, що проєкт був написаний досить давно за мірками мого розвитку, адже я швидко навчаюсь, пробую багато рішень і підходів. Від багатьох із них я вже відмовився, а після цього відео перегляну ще деякі моменти. Стосовно SCSS - для мене він зручний. Щодо БЕМ, згоден, що для React він не дуже підходить, оскільки виникає багато питань, як краще писати, щоб було зручніше. Але для кожного рішення є свої мінуси, тому від БЕМу буду відмовлятися.
З приводу React - деякі рішення були невдалими, і я розумів це ще на стадії написання коду. Від деяких рішень я вже відмовився, почав більш чітко відокремлювати логіку та писати більш чисті компоненти. Також буду вдячний за додаткові коментарі та поради від підписників твого каналу - всі читаю, всім дякую!
Структуру папок поки не можу знайти ідеальну, навіть не для себе, а для конкретного проєкту. Коли проєкт невеликий, не дуже хочеться створювати велику кількість папок. Щодо патернів - було цікаво, тому вирішив використати їх у проєкті, щоб спробувати й повчитися.
За зауваження щодо case sensitive дякую - якось не задумувався. Теми в стилях зазвичай відокремлюю, але тут вирішив зробити так, хоча розумію, що це незручно, якщо виникне потреба змінювати. Загалом багато речей я переосмислив і почав робити по-іншому. Дякую за поради й увагу! :)

[@MaksymRudnyi]

Дякую що поділився кодом. Було приємно та корисно розбирати цей проєкт. Радий що поради та зауваження виявились корисними. Сподіваюсь зміг допомогти з професійним розвитком.
Буду вдячний за позитивний відгук в LinkedIn. Це допоможе нам обом збільшити аудиторію та додати нові професійні зв'язки.

[@d4st1n]

Ну насправді це не проблема BEM'у, а проблема реалізації) В BEM блоки так само діляться по компонентах і оцих проблем немає бути. Проте, маючи як альтернативу CSS модулі необхідність в BEM дуже сумнівна

[@MaksymRudnyi]

Та я також погоджуюсь. BEM норм методологія, але для реакту є кращі та ефективніші альтернативи.

[@skif_lviv]

основна фішка БЕМ було те що в стилях сайту не було ніяких вкладень це напряму впливало на час відмальовки сторінки браузером, що було досить сутьєво в ті часи, ну і реалізація такого собі скоупа в стилях - будь-який елемент мав просто прямий клас, посуті компонентний підхід в сss. Тоді навіть були в яндекса зборщікі БЕМ які вміли хтмл+css файлики збирати в сторінки по конфігу.
в Реакті таке реалізувати можна легко на іменах компонентів, оскільки компонент має кастомний неймінг що не повторюється і повністю підходить для генерації класів в стилях по методології БЕM. Хоча я теж люблю писати стилі в scss і БЕМ, це більш для мене кросфреймворково)), але стилі складаю біля кожного компоненту окремо, щоб простіше було орієнтуватись по стилям і це теж більш кросфреймворково)

[@MaksymRudnyi]

В BEM є свої плюси, яле як самі і кажете , в React це робиться простіше і по іншому.

[@StallerEternal]

мені здається ви плутаєте БЕМ для ксс, та то, як це зроблено у автора.
Автор заюзав БЕМ ще із scss та заюзав для внутрішніх компонентів той самий неймінг, в чому і є Велика Помилка (або ні, якщо цей код не буде апдейтися і сапортитися)
і Як раз у БЕМ плюсами є (тільки частку привів)
+ ізольованість модулів і відсутність тяжких каскадів селекторів
+ зрозуміла структура для всіх
+ зниження ризиків колізій із класами
+ ксс можно повторно юзати.
і всі ці 4 пункта Автор "поломав" своіми діями.

[@MaksymRudnyi]

Так, в BEM є ці плюси і вони хороші. Але в React переваги бема нівелюються

[@ops_rv]

для вестки норм