Удалить jss
krashaen opened this issue · comments
Мы вроде решили, что уходим от jss? Но тут он везде остался, предлагаю выпилить)
@Znack @in19farkt @chmnkh @NikitaRzm Что думаете?
Мне сложно что-то конкретное сказать, я только на классике работал. Буду ждать мнения остальных ребят :)
можно конечно выпилить. Но сейчас на стартер ките используется material-ui, он хорош по многим параметрам и многие ребята его уже хорошо знают. Если мы принимаем решение выпилить jss, то придется вместе с ним выпилить material-ui и все форм филды написанные на основе материаловских компонент. Нужно будет найти какую-то достойную замену материалу и чтобы там не было css-in-js.
Мы смотрели в сторону antd, но чето там как-то сыровато, их компонентами не возможно пользоваться с клавиатуры, эломентарно табом по контролам ходить нельзя. Тут мне кажется нужно хорошенько погуглить, может действительно есть что-то очень крутое с классическими стилями.
С другой стороны мы можем оставить jss для material-ui, а самим использовать scss. Они у себя не используют динамические стили, поэтому просадки по производительности не будет. И как минимум кастомизировать mui через jss очень удобно. Но если мы в свою очередь будем пользоваться scss, то у нас не будет доступа к mui-теме, а это значит нам в двух местах придется поддерживать тему, специально для mui и для scss.
material за счет этого становится хуже всего остального, когда начинает диктовать такие крупные движения в бандле и стеке и только по этому можно от него отказаться и от подобных библиотек, когда они несовместимы по стеку. Мы же не тянем компоненты Vue условно для закрытия функционала работая на react.
Если в стеке оставили scss -> pure css, то надо стараться чтоб компоненты не требовали поддержания альтернативных подходов - это либо инкапсуляция css-in-js глубоко под капотом (что довольно сложно, по-моему), либо работали в нескольких режимах, либо предлагали ровно то, что подходит стеку.
Так что считаю, что вопрос плавно перетекает в замену ui-kit'а стартеркита :)
А давайте еще с такой стороны посмотрим, представим что у нас есть ui-kit библиотека с pure css. Что нам это даст:
- первый рендер немного быстрее, т.к. нет сборки и инжекта в хед jss-стилей. Почему немного, потому что инжектятся только стили юи кита, а их не так много и они не содержат динамические стили.
- ушли jss зависимости в бандле, примерно 15.7kB gzip. Выпилился весь код инициализации jss и подключения его к реакту, а значит проект стал немного проще.
- пришли стили нового юи кита, сокрее всего довольно жирные, т.к. уже пропущены через препроцессоры и содержат префиксы, чтобы охватывать максимальное кол-во бравзеров
- стили юи кита скорее всего будут поставляться одним большим куском, поэтому используя одну кнопку и инпут мы затащим стили всего юи кита (но возможно найдутся библиотеки с модульными стилями)
- css для всех один, поэтому стили юи кита смешаются с нашими, нужно тщательно выбирать библиотеку, которая поминимуму наговняет в глобальных стилях и желательно будет написана по бэмчику, чтобы этот фактор еще уменьшить.
На что нужно обратить внимание при выборе юи кита:
- модульность, в том числе в стилях, чтобы была возможность затянуть только то, что действительно нужно и используется.
- стили по бэм и минимально захламляют глобальные.
- возможность без костылей кастомизировать компоненты.
- дотсупность, возможность управлять компонентами с клавиатуры
- желательно большое комьюнити и живой репозиторий.
- богатая библиотека компонентов
- темы приветствуются
Это так, на вскидку, что пришло в голову. Возможно у кого-нибудь есть чем дополнить :)
Генерализую немного критерии в отрыве от css-tech:
- отсутствие требований масштабного изменения стека или поддержки альтернативных подходов сборки, наличия библиотек, css-сборки и т.д (если требуется подключить less-loader - приемлемо, если надо подключить babel-loader и еще транспилить код библиотеки - уже неприемлемо);
- приемлемый уровень модульности (и стили и js код) - что есть приемлемый нужно смотреть с опытными людьми;
- системно структурированный css с понятным поведением стилей - ожидаемое нехаотичное и логичное каскадирование как-минимум (как настраивается стиль при разных модификаторах - дело второе, и очень сложно ждать чего-то вменяемого от большинства юи-китов, но большой плюс если будет и такой механизм);
- В идеале еще возможность не супер-гибкой кастомизации, но расширения (open-closed и Single Resp), но такое тоже космос для большинства стартер-китов, но хорошо, если будет возможность такие механизмы использовать;
- богатость комопнентами - без изменений;
- темы как плюс, но не жирный, этим можно жертвовать спокойно и решать отдельно на более поздних стадиях проекта.
Думаю можно эту ишу закрывать
- выпилили jss и react-jss из зависимостей
- пока что оставили material-ui с их кастомной реализацийе css-in-js, которую мы используем для кастомизации материал-компонент