Comments 28
Вообще, конечно, странная штука – глобальные переменные испокон веков считались анти паттерном, но redux, который по сути является глобальным объектом, обрел такую популярность и повсеместное использование.
Ничего удивительного. Redux, как и React, поднялись на хайпе. Абрамов, по сути, не изобрёл ничего нового, а написал простую реализацию машины состояний по мотивам Flux и, возможно, Elm. И, как любое глобальное состояние, Redux хорошо работает на маленьких проектах, а это позволило быстрее «продать» его новичкам-хелловорлдщикам.
А в чем проблема, спросите вы, redux прекрасный инструмент, зачем от него отказываться?
Так то все адекватные люди ещё в 2017 году от него отказались в пользу MobX(по сей день ничего лучше для react нету), а более прошареные в 2016.
Даже мысль о том, чтобы назвать redux прекрасным инструментом это уже что-то за рамки вон выходящее.
глобальные переменные испокон веков считались анти паттерном
В контексте модульности (import { myState } from './state';) это не глобальная переменная, строго говоря это даже не переменная)
import { myState } from './state';
// Ничего не выйдет, в плане вы ее переопределите для тех
// кто в других местах ее импортирует
myState = 123; А вот если нам понадобиться такое поведение, то выход такой:
import { myState } from './state';
myState.value = 123;
//где myState изначально
export const myState = {
value: null // или что угодно
}Но и это не является глобальной переменной, это просто объект, свойства которого мы уже можем переопределять.
мигрировать который на что-то иное вряд ли получится за адекватное время одновременно с написанием новых фич
Для этого делается параллельно версия 2.0, в которой уже не будет таких фатальных архитектурных просчетов как использование redux. Потом просто происходит переключение на нее.
Главное при этом не добавить новых фатальных просчетов, например занести tailwindcss или styled-components и в этом духе.
Помимо этого, мы реанимируем наш продукт, переписывая его с использованием FSD
А вот и очередной фатальный просчет.
Расскажите пожалуйста почему tailwind или styled component - фатальные просчеты?не спора ради, интересно..
styled-components - жирный рантайм
tailwindcss просто не нужен
Styled components более не поддерживается.
Tailwind — решение уровня «написал и забыл». Сложный проект, особенно поддерживаемый несколькими параллельными командами, с ним превращается в кашу.
1) styled-components
Писать CSS в JS'e ну такое себе мягко говоря.
Компоненты не отделяются от верстки, все написаны с заглавной буквы, отсюда каша и в итоге говнокод.
Ну и вообще любое CSS-in-JS это противоестественно. Это как пить чай из двигателя внутреннего сгорания.
2) Tailwind
Тут всё просто, вместо тысячи слов
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>Думаю не надо объяснять почему это write only once нечто, всё что угодно, но точно не код и не верстка.
10 лет назад была придумана идеальная связка, это CSS Modules + SCSS.
По сей день, альтернатив ей нет.
Такие длинные классы только выглядят непривычно, но на практике работу ускоряют очень прилично (ссылок на пабмед не будет, это личный опыт). Если одинаковую вёрстку нужно использовать в нескольких местах, её можно обернуть в компонент, но вы это и так понимаете, просто вредничаете:
export const Content = ({ children }: PropsWithChildren<{}>) => {
return (
<div className="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
<div className="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">
{children}
</div>
</div>
);
};
Для меня лично самый большой плюс Tailwind'а -- это отсутствие головной боли от придумывания бесконечного количества имён для классов. Пусть лучше будет bg-green-100 text-green-900 text-sm, чем name-wrapper, user-wrapper-container и прочие абсолютно искусственные наименования, которые никак не помогаю понимать и быстро менять код
Ускорить работу они могут только если у вас нет дизайна. Если он есть, готовьтесь снова придумывать классы на случай, когда тейлвинда не хватает.
И вжух, у вас теперь и простой CSS, и тейлвинд в одном проекте. Хотя мог бы быть только CSS. Поздравляю.
Для меня лично самый большой плюс Tailwind'а -- это отсутствие головной боли от придумывания бесконечного количества имён для классов
Когда появился CSS modules (10 лет назад), уже этой проблемы не было. У меня в проектах 100500 .item или .title и т.п. Именно с таким названиями. И никто ни с кем не конфликтует, ибо CSS modules + SCSS.
Плюс на уровне вложенности это решается и решалось вообще со времен динозавров
.my_cart_container {
.item { /* ... */}
.title { /* ... */}
}
.my_other_block {
.item { /* ... */} // Никак не связан с .item выше
.title { /* ... */} // Никак не связан с .title выше
}Никаких конфликтов, никаких выдумываний уникальных синонимов для item'ов, title'ов и т.п.
Получается самый большой плюс на самом деле не актуален с момента создания tailwind, за много много лет до него уже был не актуальным)
Такие длинные классы только выглядят непривычно
Если бы непривычно, хотя бы. Но выглядит скажем так значительно хуже) Чрезмерная, абсолютно лишняя когнитивная нагрузка, не разборчивость в inline мешанине и т.п. Это кстати тоже самое как окунуться в далекое прошлое и поверстать письма, там как раз в inline всё было, вот это я понимаю боль и страдания. А теперь, почти тоже самое, только назвали это tailwind. В традиционном подходе всё супер понятно, div в котором className={styles.title} сразу дает тебе понять что тут какой-то заголовок ну и так далее. Про то, что сама по себе верстка в разы компактнее при традиционном подходе я вообще молчу)
но на практике работу ускоряют очень прилично
Никогда не поверю. В розовом мире максимум не сильно отставать будет от традиционного подхода. В реальном, будет отставать значительно, например заходим в фигму, ctrl+c ctrl+v и всё. Плюс в SCSS абсолютно никаких ограничений на стили, там тебе и переменные и функции и условия и т.д. и т.п. Опять же, в той же фигме при условии если дизайнер адекват, есть тот же ui kit, например для типографии у них какой нибудь Subheader 2, ты просто берешь нажимаешь на него, его название тебе копируется в буфер обмена и далее
@include typography('Subheader 2');и всё, которое проератится в допустим
font-size: 18px;
line-height: 20px;
font-weight: 500;Потом через пол года гайд лайны не много изменятся и Subheader 2 теперь будет font-weight: 500;, просто в 1 месте это заменил и всё, сразу же это применилось везде.
Ну что это, если не максимально возможно большая скорость и блаженство?
Про всякие супер удобные хэлперы я тоже молчу, аля
// На мобильных устройствах hover нам может вредить
@include respond-to-desktop-only {
&:hover {
// Цвет из дизайн системы
background-color: color('Purple_3');
}
}
@include respond-to-mobile {
display: flex;
width: 100%;
padding: 0 20px;
// Набор стилей для текста из дизайн системы
@include typography('Text Thin_14');
}
И т.д. и т.п.Я понимаю вас, тоже писал на модулях и SCSS, но они в моём личном рейтинге стоят на втором месте. Всё, что вы написали, справедливо, но лично мне гораздо удобнее и быстрее работать с Tailwind.
Это удобство сложно объяснить, это что-то на уровне того, как вы (и я в личных беседах) пытаетесь объяснить удобство Mobx людям, которые его никогда не пробовали. У них всегда в запасе есть какие-то теоретические возражения, которые на практике при работе с Mobx даже и не встречаются. С Tailwind, на мой вкус, такая же история.
Честно говоря, когда впервые увидел что вам Tailwind не нравится, то сильно удивился, потому что по всем остальным глобальным вопросам во фронтенде мы, кажется, сходимся :)
Ну я вот работал на проекте с тейлвиндом. Ничего хорошего в этом не было.
На каждую технологию найдется свой проект, в котором ничего хорошего не было :)
Ну вы там выше писали, что проект был большой, и над ним работало несколько команд параллельно. Я в таких условиях Tailwind не использовал. Вполне допускаю, что при росте команды он будет вставлять палки в колеса. В больших командах использовал только CSS модули. Tailwind использовал в команде из трёх человек максимум.
Но это не отменяет личных предпочтений :) Если мне нужно написать что-то для себя, то я возьму Svelte и Tailwind и напишу фронтенд почти с закрытыми глазами. Но ни Svelte, ни Tailwind не популярны на "рынке труда"
На каждую технологию найдется свой проект, в котором ничего хорошего не было :)
Ну вы там выше писали, что проект был большой, и над ним работало несколько команд параллельно. Я в таких условиях Tailwind не использовал. Вполне допускаю, что при росте команды он будет вставлять палки в колеса. В больших командах использовал только CSS модули. Tailwind использовал в команде из трёх человек максимум.
Но это не отменяет личных предпочтений :) Если мне нужно написать что-то для себя, то я возьму Svelte и Tailwind и напишу фронтенд почти с закрытыми глазами. Но ни Svelte, ни Tailwind не популярны на "рынке труда"
Ну а я работаю в 9 крупных проектах Которые живут в айфреме и все на тейлвинде. Удобно, быстро, легко и никаких проблем не испытываю.
Удобно, быстро, легко и никаких проблем не испытываю.
Если всё действительно так, то для вас не составит труда и времени как для меня сделать тоже самое, только с tailwind. Нужно всего на всего отстилизовать кнопку, разумеется адаптивно, и для простоты всего 2 варианта, десктоп и мобайл, без планшета:
.button {
height: 40px;
padding: 0 40px;
display: inline-flex;
align-items: center;
justify-content: center;
border-radius: 5px;
cursor: pointer;
transition: all .3s ease;
outline: none;
border: none;
// Набор стилей для текста из дизайн системы
@include typography('Text Regular_16', '#afceff');
// Через props можен сказать чтобы кнопка тянулась на всю ширину
&[data-full-width="true"] {
display: flex;
width: 100%;
}
// Через props можен сказать что кнопка закругленная
&[data-rounded="true"] {
border-radius: 18px;
}
// Через props можен сказать что кнопка заблокирована
&[data-disabled="true"] {
opacity: .5;
pointer-events: none;
}
// На мобильных устройствах hover нам может вредить
@include respond-to-desktop-only {
&:hover {
// Цвет из дизайн системы
background-color: color('Purple_3');
}
}
&:active {
// Цвет из дизайн системы
background-color: color('Purple_2');
}
@include respond-to-mobile {
display: flex;
width: 100%;
padding: 0 20px;
// Набор стилей для текста из дизайн системы
@include typography('Text Thin_14');
}
}Просто повторите аналогичный стиль для кнопки, где
@include typography('Text Thin_14');
пусть будет
font-size: 14px;
font-weight: 300;
line-height: 14px;
letter-spacing: 0.02em;
font-family: lalala;@include typography('Text Regular_16', '#afceff');
пусть будет
font-size: 16px;
font-weight: 400;
line-height: 16px;
letter-spacing: 0.02em;
font-family: lalala2222;
color: #afceff;Ну и сама кнопка -
<button
className={styles.button}
data-full-width={props.fullWidth}
data-rounded={props.rounded}
data-disabled={props.disabled}
>
{children}
</button>
И сравним результат. @Telichkin присоединяйтесь тоже
export const Button = (props) => {
return (
<button
data-full-width={props.fullWidth}
data-rounded={props.rounded}
data-disabled={props.disabled}
className='h-10 px-5 sm:px-10 rounded-md w-full sm:w-auto
cursor-pointer outline-none border-none
flex sm:inline-flex items-center justify-center
transition-all ease-linear duration-300
text-thin-14 sm:text-regular-16
data-[full-width]:flex data-[full-width]:w-full
data-[rounded]:rounded-xl
data-[disabled]:opacity-50 data-[disabled]:pointer-events-none
sm:hover:bg-purple-3 active:bg-purple-2'>
{props.children}
</button>
)
}
/* main.css */
@import "tailwindcss";
@layer components {
.text-thin-14 {
font-size: 14px;
font-weight: 300;
line-height: 14px;
letter-spacing: 0.02em;
font-family: lalala;
}
.text-regular-16 {
font-size: 16px;
font-weight: 400;
line-height: 16px;
letter-spacing: 0.02em;
font-family: lalala2222;
color: #afceff;
}
}
но на практике работу ускоряют очень прилично
Ну и как именно ускоряется работа?
Как можно обогнать ctrl+c / ctrl-v из фигмы?
Это ж ппц, это же прям дичь
Максимум что может быть. это не сильно отстать от SCSS. Получается в итоге преимуществ нет, но при этом приходится платить такую цену:
Проигрыш по скорости (в розовом мире небольшое отставание)
Жесткое месиво в разметке, что опять же крайне негативно виляет на скорость, т.к. надо ещё раздуплить что это вообще за блок такой
h-10 px-5 sm:px-10 rounded-md w-full sm:w-auto cursor-pointer outline-none border-none flex sm:inline-flex items-center justify-center transition-all ease-linear duration-300 text-thin-14 sm:text-regular-16 data-[full-width]:flex data-[full-width]:w-full data-[rounded]:rounded-xl data-[disabled]:opacity-50 data-[disabled]:pointer-events-none sm:hover:bg-purple-3 active:bg-purple-2ибо в tailwind нет логических подсказок в разметке аля.button/.title/.containerКрайне затруднен сам по себе поиск файла и места с кодом куда внести правку, в CSS modules + scss все супер просто, ты видишь где проблемное место, нажимаешь правой кнопкой, показать код и вуаля, видишь класс
src-pages-main-components-ArticlesList-components-ArticleListMobileView-___styles-module__card_content___SVA-Iв котором сразу видно где именно лежит проблемный компонент и его класс, открываешь этот файл, далее ctrl+f по названию класса и ты сразу стоишь в нужном месте в коде, это настолько быстро, просто и приятно, что тут даже близко никакой конкуренции и аналогов нет.
На выходе, tailwind только замедляет разработку, срёт в разметке и мешает дебагу/фиксу багов/навигации по коду. Всё это негативно сказывается на скорости разработки, что в свою очередь сказывается на трате нашего времени впустую, а время это ресурс который нельзя вернуть, нельзя купить за деньги. И платя эту цену, ты по ничего не обретаешь.
Например когда мы используем Node.js на бэкенде для REST API, вместо С++, мы платим цену в виде уменьшения производительности, но в замен получаем очень сильное ускорение разработки, и очень сильное улучшение самого удобства разработки. Производительность падает не так страшно, как то, насколько сильно повышается скорость и удобство разработки. Вот это я понимаю справедливое и оправданное применение Node.js.
Ну и на закуску, например открываем тот же сайт tailwind'a и видим
Это же ппц просто) Если просмотреть разметку, получается полезной разметки там 10% от всех символов, остальные 90% это месиво от tailwind классов. Получается сайты с SSR каждый раз по сети гоняют дополнительную тонну мусора, хотя могли бы и не гонять)
rounded-xl будет перекрывать rounded-md? А наоборот?
потому что по всем остальным глобальным вопросам во фронтенде мы, кажется, сходимся :)
Значит мышление должно быть схожее) И отсюда зеркальное удивление от того, как tailwind может реально нравится)
но лично мне гораздо удобнее и быстрее работать с Tailwind.
Может быть, но всё равно не могу понять как такое возможно)
Прошёл все виды вёрстки от pug / CSS , CSS in JS , bem, postcss , для себя решил что tailwind хорош во всем кроме специфичных селекторов из за которых классы превращаются действительно в кашу
Если бы вы прошли все виды верстrи, то как минимум с 2015-2016 года вы бы использовали SCSS, а не CSS. Между ними небо и земля. А SCSS видимо вы не использовали, что супер странно. В любом случае просто сделайте полноценный аналог комменту выше и все будет видно наглядно.
Если компоненты правильно структурированы и свёрстаны, то и проблем с именованием классов практически не будет. Иногда названия блоков можно подсмотреть в дизайн-макете. В любом случае это всё равно что говорить: я не хочу разбивать функцию в 1000+ строк на подфункции, потому что голова болит придумывать им имена, пусть лучше простыня будет.
Помимо этого, мы реанимируем наш продукт, переписывая его с использованием FSD
Если до этого команда не писала на FSD, то видимо вы решили окончательно угробить проект)
Нет, решили именно возродить. Именно это и происходит.
Нет, решили именно возродить. Именно это и происходит.
Ага, смешно)) Это такое же "возрождение" как использовать redux, styled-components, tailwind и прочую дичь.
FSD === угробить проект, даже это уже всем давно известно, хотя это было и изначально понятно, когда это мертворожденное нечто заявило о себе.
Настало время открыть глаза, например, есть такая штука - MobX.
Ещё один пример, есть такая штука как классическая(традиционная) архитектура фронтенд приложений которой уже лет 10:
Учитывая ваши предпочтения, не удивительно что вы стремитесь к максимально плохому коду и максимально плохой архитектуре.
Ну и тем более до сих пор боретесь с элементарными вещами, с которыми уже никто не борется 10 лет, ибо решение давным давно существует, всё что нужно это просто открыть глаза и посмотреть по сторонам.
Redux: Реанимируем легаси проект