#статья дня
Что самое опасное может сказать фронтенд-разработчик, верстающий макет или готовящий ui-kit?
Опустим сейчас (несуществующее) разделение на настоящий и ненастоящий фронтенд.
Вот это:
— Я умею нормально называть классы, они у меня всегда уникальные!
Окей, дай мне гарантию, что ты не ошибёшься на десятке страниц, нескольких десятках комбинаций компонентов и все твои коллеги такие же смышлёные. Ещё скажи, в композицию умеешь и специфичность на лету посчитаешь.
Ребят, штуки вроде пространств имён, БЭМ, OOCSS, CSS-in-JS, CSS modules появились не потому что их разработчики глупы или ленивы. Они появились потому что все мы люди и толпа может быть как умнее одного человека, так и бесконечно глупее. Ок, если не глупее, то, как минимум невнимательнее.
Ведь подобная ситуация она везде, не только в вёрстке.
Ну вот давайте возьмём для примера Next.js. За базу там взяты CSS-модули, поэтому уже один только этот факт делает вопрос: «А css-модули уже устарели, да?», — некорректным.
Да, «гладить» фреймворк против шерсти не стоит. Да, создать глобальный класс для компонента способом, не предусмотренным документацией (созданием отдельного глобального скоупа) будет проблемой (То же самое касается и css-in-js).
Но зато насколько легче решаются остальные 99% задач!
Короче, чтобы вам сегодня сделать своё понимание кода и его сборки чуть лучше и заодно понять сопутствующие проблемы CSS-модулей горячо рекомендую эту статью: https://habr.com/ru/post/688844/
Как включить их в сборку, как типизировать. Зачем вообще типизировать и как экспорты по умолчанию всё портят.
Прекрасно и максимально понятно написано. Заодно скилл вебпака подтянете :)
#css #cssmodules #webpack
Что самое опасное может сказать фронтенд-разработчик, верстающий макет или готовящий ui-kit?
Опустим сейчас (несуществующее) разделение на настоящий и ненастоящий фронтенд.
Вот это:
— Я умею нормально называть классы, они у меня всегда уникальные!
Окей, дай мне гарантию, что ты не ошибёшься на десятке страниц, нескольких десятках комбинаций компонентов и все твои коллеги такие же смышлёные. Ещё скажи, в композицию умеешь и специфичность на лету посчитаешь.
Ребят, штуки вроде пространств имён, БЭМ, OOCSS, CSS-in-JS, CSS modules появились не потому что их разработчики глупы или ленивы. Они появились потому что все мы люди и толпа может быть как умнее одного человека, так и бесконечно глупее. Ок, если не глупее, то, как минимум невнимательнее.
Ведь подобная ситуация она везде, не только в вёрстке.
Ну вот давайте возьмём для примера Next.js. За базу там взяты CSS-модули, поэтому уже один только этот факт делает вопрос: «А css-модули уже устарели, да?», — некорректным.
Да, «гладить» фреймворк против шерсти не стоит. Да, создать глобальный класс для компонента способом, не предусмотренным документацией (созданием отдельного глобального скоупа) будет проблемой (То же самое касается и css-in-js).
Но зато насколько легче решаются остальные 99% задач!
Короче, чтобы вам сегодня сделать своё понимание кода и его сборки чуть лучше и заодно понять сопутствующие проблемы CSS-модулей горячо рекомендую эту статью: https://habr.com/ru/post/688844/
Как включить их в сборку, как типизировать. Зачем вообще типизировать и как экспорты по умолчанию всё портят.
Прекрасно и максимально понятно написано. Заодно скилл вебпака подтянете :)
#css #cssmodules #webpack
Хабр
Webpack + CSS Modules + TS = Love
Я считаю, что CSS Модули — это монументальный проект. С его помощью можно решить одну из худших проблем CSS — коллизию имен классов. Давайте рассмотрим простой пример, чтобы было понятно, о чем...
👍13👎2😁1
#статья дня
Что самое опасное может сказать фронтенд-разработчик, верстающий макет или готовящий ui-kit?
Опустим сейчас (несуществующее) разделение на настоящий и ненастоящий фронтенд.
Вот это:
— Я умею нормально называть классы, они у меня всегда уникальные!
Окей, дай мне гарантию, что ты не ошибёшься на десятке страниц, нескольких десятках комбинаций компонентов и все твои коллеги такие же смышлёные. Ещё скажи, в композицию умеешь и специфичность на лету посчитаешь.
Ребят, штуки вроде пространств имён, БЭМ, OOCSS, CSS-in-JS, CSS modules появились не потому что их разработчики глупы или ленивы. Они появились потому что все мы люди и толпа может быть как умнее одного человека, так и бесконечно глупее. Ок, если не глупее, то, как минимум невнимательнее.
Ведь подобная ситуация она везде, не только в вёрстке.
Ну вот давайте возьмём для примера Next.js. За базу там взяты CSS-модули, поэтому уже один только этот факт делает вопрос: «А css-модули уже устарели, да?», — некорректным.
Да, «гладить» фреймворк против шерсти не стоит. Да, создать глобальный класс для компонента способом, не предусмотренным документацией (созданием отдельного глобального скоупа) будет проблемой (То же самое касается и css-in-js).
Но зато насколько легче решаются остальные 99% задач!
Короче, чтобы вам сегодня сделать своё понимание кода и его сборки чуть лучше и заодно понять сопутствующие проблемы CSS-модулей горячо рекомендую эту статью: https://habr.com/ru/post/688844/
Как включить их в сборку, как типизировать. Зачем вообще типизировать и как экспорты по умолчанию всё портят.
Прекрасно и максимально понятно написано. Заодно скилл вебпака подтянете :)
#css #cssmodules #webpack #бородач
Что самое опасное может сказать фронтенд-разработчик, верстающий макет или готовящий ui-kit?
Опустим сейчас (несуществующее) разделение на настоящий и ненастоящий фронтенд.
Вот это:
— Я умею нормально называть классы, они у меня всегда уникальные!
Окей, дай мне гарантию, что ты не ошибёшься на десятке страниц, нескольких десятках комбинаций компонентов и все твои коллеги такие же смышлёные. Ещё скажи, в композицию умеешь и специфичность на лету посчитаешь.
Ребят, штуки вроде пространств имён, БЭМ, OOCSS, CSS-in-JS, CSS modules появились не потому что их разработчики глупы или ленивы. Они появились потому что все мы люди и толпа может быть как умнее одного человека, так и бесконечно глупее. Ок, если не глупее, то, как минимум невнимательнее.
Ведь подобная ситуация она везде, не только в вёрстке.
Ну вот давайте возьмём для примера Next.js. За базу там взяты CSS-модули, поэтому уже один только этот факт делает вопрос: «А css-модули уже устарели, да?», — некорректным.
Да, «гладить» фреймворк против шерсти не стоит. Да, создать глобальный класс для компонента способом, не предусмотренным документацией (созданием отдельного глобального скоупа) будет проблемой (То же самое касается и css-in-js).
Но зато насколько легче решаются остальные 99% задач!
Короче, чтобы вам сегодня сделать своё понимание кода и его сборки чуть лучше и заодно понять сопутствующие проблемы CSS-модулей горячо рекомендую эту статью: https://habr.com/ru/post/688844/
Как включить их в сборку, как типизировать. Зачем вообще типизировать и как экспорты по умолчанию всё портят.
Прекрасно и максимально понятно написано. Заодно скилл вебпака подтянете :)
#css #cssmodules #webpack #бородач
👍10❤1🥰1💩1