Комментарии 16
Выход «по сути» — это вебкомпоненты, теневой DOM, и частичное его открытие для верхних уровней через ::part и ::theme.
Всё остальное — это попытки натягивания совы на глобус; когда модульность логики (т.е. кода и компонентов) не совпадает с модульностью стилей — это всегда означает, что за тем и другим придётся следить по отдельности, следить за синхронизацией одного с другим — тоже отдельно, а любой рефакторинг с ростом размера проекта будет превращаться в мигрень.
Когда люди хватаются за CSS-in-JS даже несмотря на то, что это нестандарт и тормоза — это говорит только о том, что они уже наелись этого вашего CSS отдельно от всего остального. Даже если этот отдельный CSS постоянно упорядочивать.
Статья-то конечно по делу, но беда в том, что это только первый этап — когда люди смотрят на цсс на 5000 строк и говорят "***, это срочно надо упорядочивать!". Но после упорядочивания всегда еще есть второй этап, когда люди смотрят на свой разобранный по полочкам цсс, и говорят "***, а как теперь следить, чтоб порядок этот не ломался?".
Всё остальное — это попытки натягивания совы на глобус; когда модульность логики (т.е. кода и компонентов) не совпадает с модульностью стилей — это всегда означает, что за тем и другим придётся следить по отдельности, следить за синхронизацией одного с другим — тоже отдельно, а любой рефакторинг с ростом размера проекта будет превращаться в мигрень.
Когда люди хватаются за CSS-in-JS даже несмотря на то, что это нестандарт и тормоза — это говорит только о том, что они уже наелись этого вашего CSS отдельно от всего остального. Даже если этот отдельный CSS постоянно упорядочивать.
Статья-то конечно по делу, но беда в том, что это только первый этап — когда люди смотрят на цсс на 5000 строк и говорят "***, это срочно надо упорядочивать!". Но после упорядочивания всегда еще есть второй этап, когда люди смотрят на свой разобранный по полочкам цсс, и говорят "***, а как теперь следить, чтоб порядок этот не ломался?".
А есть еще подход CSS-in-HTML (когда пишем стили рядом с тегами: <div style="margin: 10px, padding: 10px; color: red; ....">...</div>) который решает и проблему модульности стилей и проблему синхронизации с компонентами-версткой (удаление куска верстки заодно удалит и стили и т.д) и проблему именования классов
Это называется inline styles. И вроде бы считается не самой лучшей практикой, мягко говоря.
Как бы это не называли, но оно приводит к дублированию кода или необходимости обертывания одинаковых div. А все это приводит к возрастанию размера кода.
А где будет выложена документация к подходу?
Где содержимое файла _maker.scss?
Это не подробная документация программного продукта или методологии, это всего лишь размышления о том как можно организовать свой css код. Отвечая на вопрос: _maker хранит в себе как стандартные методы, которые общие для всех компонентов так и индивидуальные в зависимости от задач конкретного компонента. Содержимое файла _maker будет уместно рассмотреть в более подробном руководстве. Оно будет немного позже.
Меньше всего мне хочется разгадывать ребусы из миксинов и функций в SCSS. Хочется найти селектор через ctrl+F и мгновенно поменять в нем стили.
это конечно же нативные web компоненты с инкапсулированными стилями
Это не стилизуется с верхних уровней. По крайней мере пока что, пока средств раскрытия теневого DOM еще не завезли.
Ну про чистоту веб-компонентов можно очень серьезно дискутировать. Я бы, например, не стал называть «самым чистым» решение, с которым без выполнения JS вёрстки вообще нет.
Как по мне sass уже уходить в прошлое, куда проще будет взять и начать пилить наконец свой фронтенд на каком нибудь vue cli — вот тебе и модульность когда в отдельном компоненте по сути и разметка и логика и стили. Помоему лучше ничего еще не придумали, хотя конечно если делаешь лендосы, то наверное использовать для этого вью слишком избыточно хз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного размышлений на тему модульного css и проблемы поддержки кода