LINUX.ORG.RU

История изменений

Исправление Nervous, (текущая версия) :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов в одном компоненте.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules или тейлвинд с префиксом.

Исправление Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов в одном компоненте.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.

Исправление Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов в одном компоненте.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.

Исправление Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.

Исправление Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.

Исправление Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.

Исходная версия Nervous, :

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

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

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules.