fullstack-development / react-redux-starter-kit

Modular starter kit for React+Redux+React Router projects.

Home Page:https://demo.fullstack-development.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Удалить 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, которую мы используем для кастомизации материал-компонент