Удалить jss

[krashaen]

Мы вроде решили, что уходим от jss? Но тут он везде остался, предлагаю выпилить) @Znack @in19farkt @chmnkh @NikitaRzm Что думаете?

[Znack]

Мне сложно что-то конкретное сказать, я только на классике работал. Буду ждать мнения остальных ребят :)

[in19farkt]

можно конечно выпилить. Но сейчас на стартер ките используется material-ui, он хорош по многим параметрам и многие ребята его уже хорошо знают. Если мы принимаем решение выпилить jss, то придется вместе с ним выпилить material-ui и все форм филды написанные на основе материаловских компонент. Нужно будет найти какую-то достойную замену материалу и чтобы там не было css-in-js.

Мы смотрели в сторону antd, но чето там как-то сыровато, их компонентами не возможно пользоваться с клавиатуры, эломентарно табом по контролам ходить нельзя. Тут мне кажется нужно хорошенько погуглить, может действительно есть что-то очень крутое с классическими стилями.

С другой стороны мы можем оставить jss для material-ui, а самим использовать scss. Они у себя не используют динамические стили, поэтому просадки по производительности не будет. И как минимум кастомизировать mui через jss очень удобно. Но если мы в свою очередь будем пользоваться scss, то у нас не будет доступа к mui-теме, а это значит нам в двух местах придется поддерживать тему, специально для mui и для scss.

[NikitaRzm]

material за счет этого становится хуже всего остального, когда начинает диктовать такие крупные движения в бандле и стеке и только по этому можно от него отказаться и от подобных библиотек, когда они несовместимы по стеку. Мы же не тянем компоненты Vue условно для закрытия функционала работая на react.

Если в стеке оставили scss -> pure css, то надо стараться чтоб компоненты не требовали поддержания альтернативных подходов - это либо инкапсуляция css-in-js  глубоко под капотом (что довольно сложно, по-моему), либо работали в нескольких режимах, либо предлагали ровно то, что подходит стеку.

Так что считаю, что вопрос плавно перетекает в замену ui-kit'а стартеркита :)

[in19farkt]

А давайте еще с такой стороны посмотрим, представим что у нас есть ui-kit библиотека с pure css. Что нам это даст:

• первый рендер немного быстрее, т.к. нет сборки и инжекта в хед jss-стилей. Почему немного, потому что инжектятся только стили юи кита, а их не так много и они не содержат динамические стили.
• ушли jss зависимости в бандле, примерно 15.7kB gzip. Выпилился весь код инициализации jss и подключения его к реакту, а значит проект стал немного проще.
• пришли стили нового юи кита, сокрее всего довольно жирные, т.к. уже пропущены через препроцессоры и содержат префиксы, чтобы охватывать максимальное кол-во бравзеров
• стили юи кита скорее всего будут поставляться одним большим куском, поэтому используя одну кнопку и инпут мы затащим стили всего юи кита (но возможно найдутся библиотеки с модульными стилями)
• css для всех один, поэтому стили юи кита смешаются с нашими, нужно тщательно выбирать библиотеку, которая поминимуму наговняет в глобальных стилях и желательно будет написана по бэмчику, чтобы этот фактор еще уменьшить.

На что нужно обратить внимание при выборе юи кита:

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

Это так, на вскидку, что пришло в голову. Возможно у кого-нибудь есть чем дополнить :)

[NikitaRzm]

Генерализую немного критерии в отрыве от css-tech:

• отсутствие требований масштабного изменения стека или поддержки альтернативных подходов сборки, наличия библиотек, css-сборки и т.д (если требуется подключить less-loader - приемлемо, если надо подключить babel-loader и еще транспилить код библиотеки - уже неприемлемо);
• приемлемый уровень модульности (и стили и js код) - что есть приемлемый нужно смотреть с опытными людьми;
• системно структурированный css с понятным поведением стилей - ожидаемое нехаотичное и логичное каскадирование как-минимум (как настраивается стиль при разных модификаторах - дело второе, и очень сложно ждать чего-то вменяемого от большинства юи-китов, но большой плюс если будет и такой механизм);
• В идеале еще возможность не супер-гибкой кастомизации, но расширения (open-closed и Single Resp), но такое тоже космос для большинства стартер-китов, но хорошо, если будет возможность такие механизмы использовать;
• богатость комопнентами - без изменений;
• темы как плюс, но не жирный, этим можно жертвовать спокойно и решать отдельно на более поздних стадиях проекта.

[in19farkt]

Думаю можно эту ишу закрывать

• выпилили jss и react-jss из зависимостей
• пока что оставили material-ui с их кастомной реализацийе css-in-js, которую мы используем для кастомизации материал-компонент