зачем тогда css-modules?

если приперло написать пару глобальных классов, у тебя никто не отбирает этой возможности

@import "~styles/constants.less"

так еще раз не только константы могут меняться.

styled-components - это детище наркомана-педофила.

@import "~styles/common.less"

так еще раз не только константы могут меняться.

бля лол, самый удобный инструмент если ты привык херачить в отдельном файле — ок, не советуй джунам херню к которой привык

если приперло написать пару глобальных классов, у тебя никто не отбирает этой возможности

В том то и дело что если тебе нужно клепать "темы оформления" (и ты их продаешь) то тебе везде нужно глобальные стили делать (почти везде)

В том то и дело что если тебе нужно клепать "темы оформления" (и ты их продаешь) то тебе везде нужно глобальные стили делать (почти везде)

вообще похуй Не надо так делать (глобально это полный пиздец)

делал темы на jss, styled-components Работает офигительно, не то что переопределение через классы

еще раз, разбиение на модули — это ровно бем только без ебаных префиксов

и глобальные стили и в беме и модулях делаются ОДИНАКОВО

ТОЛЬКО

БЕЗ

ЕБАНЫХ

ПРЕФИКСОВ

ЕБАНЫХ

ставь огонек в ник

вообще похуй Не надо так делать (глобально это полный пиздец)

Извиняюсь, если бизнес на этом основан, продавать один и тот-же продукт с разным оформлением (куча проектов так делают) Пока просто не видел ни 1 примера темы оформления для CSS-modules, CSS-in-JS

и глобальные стили и в беме и модулях делаются ОДИНАКОВО

?

Извиняюсь, если бизнес на этом основан, продавать один и тот-же продукт с разным оформлением (куча проектов так делают) Пока просто не видел ни 1 примера темы оформления для CSS-modules, CSS-in-JS

Я именно это и делаю! У нас 6 сервисов с категорически разными темами Я сделал библиотеку компонентов, которая работает везде, но выглядит по разному

Я именно это и делаю! У нас 6 сервисов с категорически разными темами Я сделал библиотеку компонентов, которая работает везде, но выглядит по разному

Обходишься константами?

И это работает легко в SSR, без хуков для бабеля и без ебаного вебпака

Обходишься константами?

нет Огромный файл темы

так так так

вебпак не трогай

вебпак не трогай

если нет css-modules, вебпак в SSR не имеет смысла

нет Огромный файл темы

Сори тут ты меня потерял. Как в JSS накинуть стили на компоненты глобально? https://github.com/cssinjs/jss-global ?

если нет css-modules, вебпак в SSR не имеет смысла

с этим могу согласиться

Сори тут ты меня потерял. Как в JSS накинуть стили на компоненты глобально? https://github.com/cssinjs/jss-global ?

На компоненты этого делать не нужно ни в коем случае

И это работает легко в SSR, без хуков для бабеля и без ебаного вебпака

а с вебпаком что?

Ок, смотри ситуация простая - кнопка - с CSS-in-JS. Все ок. Она инкапсулированная. Все замечательно работает Теперь нужно для этой кнопки в определенном проекте другие стили.

ты просто импортишь из файла темы нужную тему

и все

а с вебпаком что?

а зачем он на сервере? Если можно бабелем по коду пройтись и всё будет работать

Ок, смотри ситуация простая - кнопка - с CSS-in-JS. Все ок. Она инкапсулированная. Все замечательно работает Теперь нужно для этой кнопки в определенном проекте другие стили.

1. Опиши новую кнопку с новыми стилями/новой функциональностью 2. Напиши в теме проекта стили специально для этой кнопки

аа, SSR это Server Side Rendering?

я тред ваш не читал прост

аа, SSR это Server Side Rendering?

да

if ( env == 'ONE') { theme = require('theme1.js') } else { theme = require('theme2.js') } Button.color = theme.color

или как там в ваших jss проставляются проперти

или как там в ваших jss проставляются проперти

<ThemeProvider theme={themes[projectName]}>

всё

ну или так и из контекста тему забирать

в каждом компоненте просто backgroundColor: theme('colors', 'mainColor')

или background-color: ${theme('colors', 'mainColor')}

1. Опиши новую кнопку с новыми стилями/новой функциональностью 2. Напиши в теме проекта стили специально для этой кнопки

1. Ну вот в этом и проблема. Нельзя как в CSS легко накинуть кастомные стили в отдельном проекте. Нужно отдельную кнопку. Отдельно ее поддерживать. Пока тут минус

1. Ну вот в этом и проблема. Нельзя как в CSS легко накинуть кастомные стили в отдельном проекте. Нужно отдельную кнопку. Отдельно ее поддерживать. Пока тут минус

ТАК ЭТО СПЕЦИАЛЬНО СДЕЛАНО ТАК!

ТАК ЭТО СПЕЦИАЛЬНО СДЕЛАНО ТАК!

Это и не удобно

ЧТОБЫ НИКАКОЙ ХУЙ С ДРУГОГО ПРОЕКТА НЕ ИСПОРТИЛ ОДНИМ ЛИШНИМ КЛАССОМ всю библиотеку

ГЛОБАЛЬНЫЕ ВЕЩИ ЕБАНОЕ ЗЛО

ЭТО И ЕСТЬ ВСЯ ЦЕЛЬ CSSINJS

ЭТО И ЕСТЬ ВСЯ ЦЕЛЬ CSSINJS

В ЭТОМ И МИНУС CSS IN JS

1. Ну вот в этом и проблема. Нельзя как в CSS легко накинуть кастомные стили в отдельном проекте. Нужно отдельную кнопку. Отдельно ее поддерживать. Пока тут минус

++++

В ЭТОМ И МИНУС CSS IN JS

да ты просто не шаришь как проектировать нормально

давайте вообще все переменные глобальные сделаем

Потом уходишь с проекта, а людям поддерживать Проходит год и пиздец в стилях никто разобрать не может

и потом еще научимся в пхп переменные из js использовать

да ты просто не шаришь как проектировать нормально

Увы шарю. Поэтому CSS-in-JS пока для меня остается проблемной областью. Костылять костыли в JSS или мантейнить 40 кнопок от 40 проектов не самая лучшая идея.

Увы шарю. Поэтому CSS-in-JS пока для меня остается проблемной областью. Костылять костыли в JSS или мантейнить 40 кнопок от 40 проектов не самая лучшая идея.

бля

так ты и так это делаешь

только в случае JSS без классических костылей CSS Без страха коллизий

а нормально описываешь одну тему для каждого проекта И не мейнтейнишь компоненты

Увы шарю. Поэтому CSS-in-JS пока для меня остается проблемной областью. Костылять костыли в JSS или мантейнить 40 кнопок от 40 проектов не самая лучшая идея.

если тебе понадобилась необходимость наслаивать стили как торт — ты делаешь что-то не так

Вот в этом и проблема JSS очень эффективно борется с глобальными стилями и коллизиями. Даже там где они нужны и могут облегчить жизнь. Я понимаю можно без Global CSS но легче писать компоненты от этого не становится.

Вот в этом и проблема JSS очень эффективно борется с глобальными стилями и коллизиями. Даже там где они нужны и могут облегчить жизнь. Я понимаю можно без Global CSS но легче писать компоненты от этого не становится.

как раз становится. ты тащишь свои привычки в другую систему и страдаешь от этого

если тебе понадобилась необходимость наслаивать стили как торт — ты делаешь что-то не так

Ты с CSS знаком? Знаешь про Default стили к элементам? Что у тебя уже 2 слоя хочешь ты этого или нет

Ты с CSS знаком? Знаешь про Default стили к элементам? Что у тебя уже 2 слоя хочешь ты этого или нет

что-что? https://github.com/iamstarkov/initize

ERROR: S client not available

как раз становится. ты тащишь свои привычки в другую систему и страдаешь от этого

Да не. Стоп. Простая задача. Есть кнопка. Есть два проекта. В обоих проектах кнопка должна выглядеть по разному. 1) В кнопке поддержать несколько стилей которые переключать каким либо образом (button modifier) 2) Как-то обойтись только определенным набором переменных и передавать их в компонент (theme approach) Есть еще варианты?

Да не. Стоп. Простая задача. Есть кнопка. Есть два проекта. В обоих проектах кнопка должна выглядеть по разному. 1) В кнопке поддержать несколько стилей которые переключать каким либо образом (button modifier) 2) Как-то обойтись только определенным набором переменных и передавать их в компонент (theme approach) Есть еще варианты?

ну и в чем проблема?

JSS и SC решается на раз

с наскока

причем проще чем в vanilla css

проблема с 2 (theme aproach) тебе заранее нужно знать как будет менятся твой компонент, это не всегда удобно. Иногда приходится заводить новые переменные ибо "не думали что это нужно будет менять" проблема с 1 (button modifier) в SRP (single resposibility) и OCP (opend closed) кнопка начинает "знать" о сущестовании всех проектов, добали проект - полезли в кнопку добавлять новые стили для нового проекта.

проблема с 2 (theme aproach) тебе заранее нужно знать как будет менятся твой компонент, это не всегда удобно. Иногда приходится заводить новые переменные ибо "не думали что это нужно будет менять" проблема с 1 (button modifier) в SRP (single resposibility) и OCP (opend closed) кнопка начинает "знать" о сущестовании всех проектов, добали проект - полезли в кнопку добавлять новые стили для нового проекта.

1 абзац это нормально. Это даже более чем нормально. Все привыкли к свободе CSS, делаю что хочу. А в обычной нормальной разработке как раз и происходит так как должно. Либо ты проектируешь компонент сходу гибким, либо пилишь сверху ещё один более подходящий для конкретно твоего кейса. если для кнопки нормально быть в разных состояниях и это переиспользуется, то так и должно быть. Если у тебя кнопка начинает быть переключателем (toggle) то это другой компонент, который композирует кнопку и это опять вопрос размещения В том же WinAPI, есть Button, а есть ToggleButton

просмотри как люди разрабатывают интерфейсы для Android, macOS, Windows, iOS. Везде один и тот же принцип, компонент предоставляет API и пользователи API мирятся с этим. Это правильно, поэтому именно к этому стремятся JSS и SC

Одна из причин по которой мне нравится @atomicdesign. Каждый компонент имеет свою зону ответственности и свою сложность, и ты это не меняешь. И вместо усложнения компонента Кнопка -> Кнопка со спиннером, ты описываешь SpinnerButton который только добавляет нужную функциональность не изменяя Button.

А если ты можешь написать строчку кода в своем проекте и сломать библиотеку компонентов, то это грубейший антипаттерн. Начинается куча говна в сторону разработчиков библиотеки, мол у нас здесь не работает а едет, исправить не можем, проблема не у нас, мы просто вставили кнопку в кнопку и добавили стили, а оно не работает. ПОЧЕМУ??!?!?! И ты сидишь и даже не знаешь что ответить, потому НЕВОЗМОЖНО написать CSS так, чтобы он работал при ЛЮБОМ кейсе использования.

Ну под Windows (WPF) есть что-то на подобие "глобальных стилей" (которые не во всех ситуация работаю но всеже. Про остальные увы не скажу. Но скажем так, я не понимаю подход №1 - когда кнопка хранит в себе стили всех проктов. Для меня это полный пипец нарущающий 2 solid принципа. Но подоход №2 (theme aproach) звучит неплохо вот с этим https://github.com/nathanmarks/jss-theme-reactor Попробую на днях. Посмотрим что получится. Хотя опять же - переменные :/

BEM - решает те проблемы CSS о которых ты гворишь

Ну под Windows (WPF) есть что-то на подобие "глобальных стилей" (которые не во всех ситуация работаю но всеже. Про остальные увы не скажу. Но скажем так, я не понимаю подход №1 - когда кнопка хранит в себе стили всех проктов. Для меня это полный пипец нарущающий 2 solid принципа. Но подоход №2 (theme aproach) звучит неплохо вот с этим https://github.com/nathanmarks/jss-theme-reactor Попробую на днях. Посмотрим что получится. Хотя опять же - переменные :/

2 абзац: Не хранит все стили. Она знает обо всех состояних в которых ей положено быть И в нужном состоянии вытягивает стили из темы. Ты в своей теме описываешь то, как каждое состояние выглядит

BEM - решает те проблемы CSS о которых ты гворишь

не решает А ставит костыль в виде префиксов, но я все равно могу написать стиль который всё сломает

не решает А ставит костыль в виде префиксов, но я все равно могу написать стиль который всё сломает

Я в JSS могу напистать плохой код который все сломает. Это слабый аргумент

Я в JSS могу напистать плохой код который все сломает. Это слабый аргумент

вот это уже будет в разы сложнее Особенно если юзаешь initize

очень сильно сложнее будет

Да и префиксы херачить не надо Не надо юзать отдельные файлы все в одном месте

Настрой stylelint и также с бэмом не сможешь нахерячить говна)

Настрой stylelint и также с бэмом не сможешь нахерячить говна)

stylelint все не поймает - к примеру опечатался в название модификатора в теме оформления - все у тебя дубет 2 модификатора вместо 1

Хотелось бы хеш

зачем? главная суть в том, что это производительнее и, главное, детерменировано, что важно для тестов (снепшотов), например

зачем? главная суть в том, что это производительнее и, главное, детерменировано, что важно для тестов (снепшотов), например

Чем хеш менее детерменирован? И что будет если два приложения в одном контексте начнут работать?

В одном доме я имел ввиду

потому что генерит не рандомный хэш слишком трудоемко

а рандомный не детерменирован

Не совсем понимаю, как это вредит тестированию?

если у тебя на каждый рендер класса новый хэш, как ты организуешь снэпшотинг стилей?

Хеш берётся от имени класса

Хеш берётся от имени класса

зачем вообще тебе хэш?

и как он решит проблему двух приложений?

Хеш берётся от имени класса

какой в нем тогда смысл?)

и как он решит проблему двух приложений?

Ну я бы хотел настраиваемую строку