Важливо. TH-cam видаляє усі підозрілі або довгі коментарі. Переконайтеся що ваш коментар додано і збережено. Особливо це стосується авторів проєктів, які описують що і чому так зробили. Дуже прикро втрачати цю інформацію, адже на ній інші навчаються. Також у мене тепер є особистий сайт - www.rudnyi.dev де буде зібрана уся корисна інформація. Курс по якості коду, над яким активно зараз працюю також можна знайти там в розділі Курси або за посиланням www.rudnyi.dev/courses/code-quality
Велике дякую за огляд мого проєкту, для себе почув багато корисних порад. Хочу додати, що проєкт був написаний досить давно за мірками мого розвитку, адже я швидко навчаюсь, пробую багато рішень і підходів. Від багатьох із них я вже відмовився, а після цього відео перегляну ще деякі моменти. Стосовно SCSS - для мене він зручний. Щодо БЕМ, згоден, що для React він не дуже підходить, оскільки виникає багато питань, як краще писати, щоб було зручніше. Але для кожного рішення є свої мінуси, тому від БЕМу буду відмовлятися. З приводу React - деякі рішення були невдалими, і я розумів це ще на стадії написання коду. Від деяких рішень я вже відмовився, почав більш чітко відокремлювати логіку та писати більш чисті компоненти. Також буду вдячний за додаткові коментарі та поради від підписників твого каналу - всі читаю, всім дякую! Структуру папок поки не можу знайти ідеальну, навіть не для себе, а для конкретного проєкту. Коли проєкт невеликий, не дуже хочеться створювати велику кількість папок. Щодо патернів - було цікаво, тому вирішив використати їх у проєкті, щоб спробувати й повчитися. За зауваження щодо case sensitive дякую - якось не задумувався. Теми в стилях зазвичай відокремлюю, але тут вирішив зробити так, хоча розумію, що це незручно, якщо виникне потреба змінювати. Загалом багато речей я переосмислив і почав робити по-іншому. Дякую за поради й увагу! :)
Дякую що поділився кодом. Було приємно та корисно розбирати цей проєкт. Радий що поради та зауваження виявились корисними. Сподіваюсь зміг допомогти з професійним розвитком. Буду вдячний за позитивний відгук в LinkedIn. Це допоможе нам обом збільшити аудиторію та додати нові професійні зв'язки.
Ну насправді це не проблема BEM'у, а проблема реалізації) В BEM блоки так само діляться по компонентах і оцих проблем немає бути. Проте, маючи як альтернативу CSS модулі необхідність в BEM дуже сумнівна
основна фішка БЕМ було те що в стилях сайту не було ніяких вкладень це напряму впливало на час відмальовки сторінки браузером, що було досить сутьєво в ті часи, ну і реалізація такого собі скоупа в стилях - будь-який елемент мав просто прямий клас, посуті компонентний підхід в сss. Тоді навіть були в яндекса зборщікі БЕМ які вміли хтмл+css файлики збирати в сторінки по конфігу. в Реакті таке реалізувати можна легко на іменах компонентів, оскільки компонент має кастомний неймінг що не повторюється і повністю підходить для генерації класів в стилях по методології БЕM. Хоча я теж люблю писати стилі в scss і БЕМ, це більш для мене кросфреймворково)), але стилі складаю біля кожного компоненту окремо, щоб простіше було орієнтуватись по стилям і це теж більш кросфреймворково)
мені здається ви плутаєте БЕМ для ксс, та то, як це зроблено у автора. Автор заюзав БЕМ ще із scss та заюзав для внутрішніх компонентів той самий неймінг, в чому і є Велика Помилка (або ні, якщо цей код не буде апдейтися і сапортитися) і Як раз у БЕМ плюсами є (тільки частку привів) + ізольованість модулів і відсутність тяжких каскадів селекторів + зрозуміла структура для всіх + зниження ризиків колізій із класами + ксс можно повторно юзати. і всі ці 4 пункта Автор "поломав" своіми діями.
Важливо. TH-cam видаляє усі підозрілі або довгі коментарі. Переконайтеся що ваш коментар додано і збережено. Особливо це стосується авторів проєктів, які описують що і чому так зробили. Дуже прикро втрачати цю інформацію, адже на ній інші навчаються.
Також у мене тепер є особистий сайт - www.rudnyi.dev де буде зібрана уся корисна інформація. Курс по якості коду, над яким активно зараз працюю також можна знайти там в розділі Курси або за посиланням www.rudnyi.dev/courses/code-quality
Велике дякую за огляд мого проєкту, для себе почув багато корисних порад. Хочу додати, що проєкт був написаний досить давно за мірками мого розвитку, адже я швидко навчаюсь, пробую багато рішень і підходів. Від багатьох із них я вже відмовився, а після цього відео перегляну ще деякі моменти. Стосовно SCSS - для мене він зручний. Щодо БЕМ, згоден, що для React він не дуже підходить, оскільки виникає багато питань, як краще писати, щоб було зручніше. Але для кожного рішення є свої мінуси, тому від БЕМу буду відмовлятися.
З приводу React - деякі рішення були невдалими, і я розумів це ще на стадії написання коду. Від деяких рішень я вже відмовився, почав більш чітко відокремлювати логіку та писати більш чисті компоненти. Також буду вдячний за додаткові коментарі та поради від підписників твого каналу - всі читаю, всім дякую!
Структуру папок поки не можу знайти ідеальну, навіть не для себе, а для конкретного проєкту. Коли проєкт невеликий, не дуже хочеться створювати велику кількість папок. Щодо патернів - було цікаво, тому вирішив використати їх у проєкті, щоб спробувати й повчитися.
За зауваження щодо case sensitive дякую - якось не задумувався. Теми в стилях зазвичай відокремлюю, але тут вирішив зробити так, хоча розумію, що це незручно, якщо виникне потреба змінювати. Загалом багато речей я переосмислив і почав робити по-іншому. Дякую за поради й увагу! :)
Дякую що поділився кодом. Було приємно та корисно розбирати цей проєкт. Радий що поради та зауваження виявились корисними. Сподіваюсь зміг допомогти з професійним розвитком.
Буду вдячний за позитивний відгук в LinkedIn. Це допоможе нам обом збільшити аудиторію та додати нові професійні зв'язки.
Ну насправді це не проблема BEM'у, а проблема реалізації) В BEM блоки так само діляться по компонентах і оцих проблем немає бути. Проте, маючи як альтернативу CSS модулі необхідність в BEM дуже сумнівна
Та я також погоджуюсь. BEM норм методологія, але для реакту є кращі та ефективніші альтернативи.
основна фішка БЕМ було те що в стилях сайту не було ніяких вкладень це напряму впливало на час відмальовки сторінки браузером, що було досить сутьєво в ті часи, ну і реалізація такого собі скоупа в стилях - будь-який елемент мав просто прямий клас, посуті компонентний підхід в сss. Тоді навіть були в яндекса зборщікі БЕМ які вміли хтмл+css файлики збирати в сторінки по конфігу.
в Реакті таке реалізувати можна легко на іменах компонентів, оскільки компонент має кастомний неймінг що не повторюється і повністю підходить для генерації класів в стилях по методології БЕM. Хоча я теж люблю писати стилі в scss і БЕМ, це більш для мене кросфреймворково)), але стилі складаю біля кожного компоненту окремо, щоб простіше було орієнтуватись по стилям і це теж більш кросфреймворково)
В BEM є свої плюси, яле як самі і кажете , в React це робиться простіше і по іншому.
мені здається ви плутаєте БЕМ для ксс, та то, як це зроблено у автора.
Автор заюзав БЕМ ще із scss та заюзав для внутрішніх компонентів той самий неймінг, в чому і є Велика Помилка (або ні, якщо цей код не буде апдейтися і сапортитися)
і Як раз у БЕМ плюсами є (тільки частку привів)
+ ізольованість модулів і відсутність тяжких каскадів селекторів
+ зрозуміла структура для всіх
+ зниження ризиків колізій із класами
+ ксс можно повторно юзати.
і всі ці 4 пункта Автор "поломав" своіми діями.
Так, в BEM є ці плюси і вони хороші. Але в React переваги бема нівелюються
для вестки норм