Немного размышлений на тему модульного css и проблемы поддержки кода

[JustDont]

Выход «по сути» — это вебкомпоненты, теневой DOM, и частичное его открытие для верхних уровней через ::part и ::theme.
Всё остальное — это попытки натягивания совы на глобус; когда модульность логики (т.е. кода и компонентов) не совпадает с модульностью стилей — это всегда означает, что за тем и другим придётся следить по отдельности, следить за синхронизацией одного с другим — тоже отдельно, а любой рефакторинг с ростом размера проекта будет превращаться в мигрень.

Когда люди хватаются за CSS-in-JS даже несмотря на то, что это нестандарт и тормоза — это говорит только о том, что они уже наелись этого вашего CSS отдельно от всего остального. Даже если этот отдельный CSS постоянно упорядочивать.

Статья-то конечно по делу, но беда в том, что это только первый этап — когда люди смотрят на цсс на 5000 строк и говорят "***, это срочно надо упорядочивать!". Но после упорядочивания всегда еще есть второй этап, когда люди смотрят на свой разобранный по полочкам цсс, и говорят "***, а как теперь следить, чтоб порядок этот не ломался?".

[bgnx]

А есть еще подход CSS-in-HTML (когда пишем стили рядом с тегами: <div style="margin: 10px, padding: 10px; color: red; ....">...</div>) который решает и проблему модульности стилей и проблему синхронизации с компонентами-версткой (удаление куска верстки заодно удалит и стили и т.д) и проблему именования классов

[warmbellycat]

Это называется inline styles. И вроде бы считается не самой лучшей практикой, мягко говоря.

[JustDont]

Все библиотеки CSS-in-JS в конечном счете именно так стили выставляют. Но да, это мягко говоря не лучшая практика, потому что означает отказ практически от всех фич CSS разом.

[Metaller]

Нет, не так. Стили генерируются динамически, но они не вставляются как inline.

[JustDont]

Скажем так, всё остальное — это оптимизация поверх изначальной привязки стилей к элементам 1-1. Так-то да, во имя скорости и уменьшения размера DOM в каждый элемент никто уже инлайново не впихивает стиль, но формирование стилей элементов так или иначе идёт через обход их всех.

[vin2809]

Как бы это не называли, но оно приводит к дублированию кода или необходимости обертывания одинаковых div. А все это приводит к возрастанию размера кода.

[thevrbata]

А где будет выложена документация к подходу?

[kaowebdev]

Документация будет в открытом доступе на github.

[sacharin]

Где содержимое файла _maker.scss?

[kaowebdev]

Это не подробная документация программного продукта или методологии, это всего лишь размышления о том как можно организовать свой css код. Отвечая на вопрос: _maker хранит в себе как стандартные методы, которые общие для всех компонентов так и индивидуальные в зависимости от задач конкретного компонента. Содержимое файла _maker будет уместно рассмотреть в более подробном руководстве. Оно будет немного позже.

[warmbellycat]

Но вы на него ссылаетесь в статье, неплохо было бы листинг хотя бы привести, иначе какая-то недосказанность получается.

[Against-vegetables]

Меньше всего мне хочется разгадывать ребусы из миксинов и функций в SCSS. Хочется найти селектор через ctrl+F и мгновенно поменять в нем стили.

[JustDont]

это конечно же нативные web компоненты с инкапсулированными стилями

Это не стилизуется с верхних уровней. По крайней мере пока что, пока средств раскрытия теневого DOM еще не завезли.
Ну про чистоту веб-компонентов можно очень серьезно дискутировать. Я бы, например, не стал называть «самым чистым» решение, с которым без выполнения JS вёрстки вообще нет.

[Glebkiselev11]

Как по мне sass уже уходить в прошлое, куда проще будет взять и начать пилить наконец свой фронтенд на каком нибудь vue cli — вот тебе и модульность когда в отдельном компоненте по сути и разметка и логика и стили. Помоему лучше ничего еще не придумали, хотя конечно если делаешь лендосы, то наверное использовать для этого вью слишком избыточно хз.