Comments 30
Спасибо за статью, мои 5 центов:
1) styled-components хорошо поддерживают темы. То есть, в будущем можно будет легко использовать библиотеки компонентов на базе styled-components без необходимость лезть дальше документации, чтобы адаптировать их внешний вид согласно общему стилю сайта
2) Поддержка SSR сейчас не идеальна
3) На текущий момент стили считаются в runtime, что очевидно плохо, но ведется разработка babel-плагина, чтобы перенести это из runtime в сборку
Больше всего удручает, что разработчиков таких либ не заботит Autoprefixer.
Они в 2017ом опять предлагают писать руками такое:
background: #1e5799; /* Old browsers */
background: -moz-linear-gradient(top, #1e5799 0%, #7db9e8 100%); /* FF3.6-15 */
background: -webkit-linear-gradient(top, #1e5799 0%,#7db9e8 100%); /* Chrome10-25,Safari5.1-6 */
background: linear-gradient(to bottom, #1e5799 0%,#7db9e8 100%); /* W3C, IE10+, FF16+, Chrome26+, Opera12+, Safari7+ */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */Замечу, что Autoprefixer тяжелый, в браузер его не стоит тащить. Он должен работать на этапе Compile Time
https://geektimes.ru/post/271056/
Откуда дровишки?
https://github.com/styled-components/styled-components/#basic
(The CSS rules are automatically vendor prefixed, so you don't have to think about it!)
https://github.com/styled-components/styled-components/pull/286
Мне думается, что гонять вот это https://github.com/rofrischmann/inline-style-prefixer на каждое обновление props, еще хуже чем, то, что я предположил сначала.
Этого вообще не должно быть в клиентском коде. Разработчики просто препроцессинг еще не осили
Честное название — Styled React Components.
Библиотека работает поверх React и без него не запустится
Хм. Читая уже которую статью по данному направлению, я всё никак не пойму ряд вещей:
- Ребята вообще задумываются о предварительной компиляции всего этого добра? Мне кажется на production не должно уходить ни строчки runtime-parse кода. А если задумываются, то какого лешего там делают props-методы? Как это потом вообще можно будет скомпилировать? Почему не строго декларативный подход? Судя по примерам из документации там целые сборные солянки из разных переменных. Бррр.
- CSS это каскадные таблицы стилей. Мне кажется, или на каскад забыли от слова "совсем"? Как из вышестоящего компонента повлиять на стили нижестоящих? Только модификаторами? Мне кажется это далеко не всегда верный подход.
- Более насущный вопрос ― а что насчёт пере-использования кода? Вроде как хотели убежать от того, что с течением времени, во всех проектах, копится мусорный CSS. Не получается ли здесь, что весь CSS мусорный, из-за тонн копипасты?
- Ни в одном примере не увидел листинга реального компонента больше 3-5 строк. Чтобы были разные теги, модификаторы внутренние всякие. Не оборачивать же каждый тег в отдельный компонент. В общем непонятно. Хорошо бы пример дельный.
Ок, попробую объяснить
- Ребята пишут babel-плагин, который будет брать статические значения props (например из тем) и собирать css в процессе сборки, а не runtime
- Основная идея styled-components — разорвать связь между компонентом и его стилем/тегом. Влиять можно несколькими путями, в том числе импортом child и & + >.
- Реиспользуйте одни и те же компоненты. К слову те, которые называются по разному, но внутри одинаковые, будут компилиться в одно и тоже будут иметь одно и тоже имя (имя класса — это хеш от его свойств)
- Можно оборачивать, можно не оборачивать. Делайте как вам удобнее
Ребята очень активно отвечают, если им написать. Вообще styled-components сначала вызывает ощущение WTF?! Но при ближайшем рассмотрении там все уже неплохо, а должно стать и вовсе отлично.
Вообще styled-components сначала вызывает ощущение WTF?! Но при ближайшем рассмотрении там все уже неплохо
Правда? Ну вот после ваших ответов я начинаю понимать, что всё ещё хуже, чем я думал. Нет, правда. Особенно впечатляет пункт 1-ый. Вместо того, чтобы изначально выстроить правильную архитектуру, возможность то имеется, ребята предпочитают городить какие-то костыли в будущем.
Если честно, у меня заняло некоторое время, чтобы придумать корректный ответ.
Вот ваш github:
https://github.com/faiwer
Вот автора styled-components:
https://github.com/mxstbr
Так как же выстраивать правильную архитектуру, и чем отличается в плане возможностей OpenSource разработчик Max Stoiber от, скажем, вас? Возможно ваши непубличные разработки имеют отличную архитектуру и идеальный код, но сообществу пользы это не приносит.
"Ваши ожидания — это ваши проблемы". Мне кажется очень точное высказывание для Open Source, ведь всегда есть пачка альтернатив для любого package, да и Pull Requests и форки никто не отменял.
styled-components как и многие OpenSource проекты начались с простой идеи, которая постепенно развивается, обрастает фичами и эволюционирует. Недостатки я осветил выше, а так же и то, что скоро они уйдут в прошлое, ведь проект бурно развивается. Использовать или нет — решать вам.
Костылей там нет, это больше на progressive по духу похоже.
Не ожидал на хабре увидеть аргументы в стиле "сперва добейтесь". Юрий, не занимайтесь глупостями. Более того, в разговорах о технологиях, нужно говорить о фактах, о подходах, о преимуществах и недостатках. А не скатываться в личные выпады. У нас же ту не детский сад. Надеюсь.
Отдельно отмечу, что технологии приходят и уходят. И лишь некоторые из них задерживаются, спустя множество модификаций изначальной идеи. Поэтому тем более нельзя так относиться к критике. Тем более не вашего то проекта.
Критики в сторону CSS в JS, весьма обоснованной, было уже довольно много. С другой стороны и самих подходов вырисовалось уже несколько, насколько я знаю. В данном подходе, на мой взгляд, самым больным местом является то, что от декларативного подхода в стилях отказались. В пользу сиюминутных удобств. И сразу видно, что это создаст проблемы в будущем при предварительной компиляции. Придётся многое менять, возможно сами стили в рабочем коде, возможно весь подход в целом. Это уже сильно настораживает. Да и по остальным пунктам всё не так просто.
В общем, на мой взгляд, ничего там в "прошлое не уходит", и не уйдёт, пока не будет каких-либо серьёзных изменений. Пока в документации я вижу методы в коде, пока сами стили слепливаются в template строках, это всё выглядит весьма проблемным.
Резюмируя. Если вас не интересуют такие диалоги ― просто отключайте комментарии к вашим статьям. Если статья не ваша ― не участвуйте в чужих. Если же ваша цель собрать единомышленников или просто сопереживающих вашим взглядам людей, то вы явно делаете, что-то не так и не там. Это открытая площадка.
В частности, вместо этого вашего комментария-наезда, я ожидал увидеть, внятное описание того, что произвольная логика при построении стилей не помешает предварительной компиляции в виду того, что планируется, что… положим, такие конструкции будут оформлены понятным babel-плагину образом, с явным указанием всех возможных зависимостей… и пр. Однако в ответ пошли какие-то войны гитхабов и значимости личностей. Бррр.
Ок, вероятно я погорячился и во многом вы правы. Спасибо за столь развернутый ответ. Я все же уклонюсь от дискуссии о критике и наездах. Я полностью согласен с вами, что "нужно говорить о фактах, о подходах, о преимуществах и недостатках", и именно поэтому расстроился, когда увидел весьма спорное, но категоричное личное впечатление, основанное далеко не на фактах, а также то, что кто-то там что-то с какой-то стати должен. С другой стороны, вы правы, Хабр свободная площадка и каждый пишет то, что считает нужным.
В styled-components by design другой подход к стилям. Многим он может показаться непривычным, особенно если вы много лет делали что-то вроде BEM'а и потому вызывает отторжение. JSS, aphrodite и еще пачка CSS-IN-JS библиотек говорит, что для реакте в целом старые подходы работают не очень, но новые сложиться еще не успели, что и говорит о массе реализаций и идей, которые сейчас эволюционируют. Мой опыт подтверждает, что идея, лежащая в основе styled-components годная.
Возвращаясь к вашим вопросам:
1) known issue, работа ведется
2) в styled-components другая философия, которая может существенно отличаться от того, что вам привычно. Это не хорошо и не плохо само по себе, только время покажет, какой подход лучше. Делать вывод, что оно неверно, потому что непривычно можно, но чаще всего контрпродуктивно. Для реакт-приложений оно оказывается крайне удобным
3) ответил
4) best practices еще не сложились, но найти примеры можно, а еще лучше сходить в gitter и собрать объективный feedback https://gitter.im/styled-components/styled-components. Я использую в своем основном проекте, полет отличный, выложил бы сорсы в качестве примера, но NDA не позволяет
P.s. статья не моя, однако автора библиотеки знаю лично. Я не имею ничего против объективной критики, но меня расстраивает, когда люди пишут откровенную ересь (это не про ваши вопросы, если что)
Спс за ссылку. Вижу, что люди:
- всё-таки используют собственные классы (руками задают
className) и привычные каскады стилей (& > .someClass) - используют имена тегов в каскадах
& > P - сборные солянки из строк, содержащих куски
css-кода, опираясь на произвольную логику - используют какие-то композиции методов даже на уровне template-string handler-ов
Что остаётся в сухом остатке? Судить сложно. Плюсы пока под вопросом (точнее их вес), а вот эти минусы сильно уж бьют:
- Определённо будут проблемы с предварительной компиляцией. Решаться явно будут неким ручным указанием всех вариантов всех допустимых props-ов. Хорошо бы без комбинаторного взрыва обойтись. Ух.
- Переусложнённой схемой в любом не тривиальном случае. Ребята УЖЕ дошли до композиции template-string handler-ов. Видимо иначе очень тесно. Что будет дальше, даже представить боюсь. Т.е. мы взяли сравнительно простой и, главное, декларативный язык CSS, сделали его императивным, отказались от части его плюшек, но зато поместили в тот же файл, что и JS-реализацию контрола.
Не буду утверждать, что это путь в никуда. Но выглядит он как-минимум не привлекательно. В конце концов, опять же, на мой взгляд, если так хочется держать стили поближе к глазам, то достаточно просто чего-то в таком духе:
injectCss(`stylus-scss-...-code`);Причём без использования интерполяции, конкатенации и пр. штук. Вся магия должна происходить на уровень реализации injectCss. Должно избавить от ряда проблем. И отлично прекомпилироваться.
Вообще говоря, странные вещи творятся. С одной стороны мы едем в сторону haskel, с его монадами, чистыми функциями, да и вообще функциональным подходом. А с другой стороны изначально декларативные вещи превращаем если уж не в императивные, то явно перенасыщенные логикой и абстракциями. Какой-то лебедь-рак-щука получается.
Я использую в своем основном проекте
Т.е. у вас "на живую" стили парсятся? Прямо в runtime в production-е? Проект видимо не очень прихотливый. Или стилей мало? А ведь это дело даже не кешируется.
Воооот. Теперь это похоже на конструктивный диалог.
Часть про "вижу, что люди" я не стану комментировать. Стрелять себе в ногу можно всегда, но это же не повод отказаться от пистолета или ноги. Вместо этого готов обсуждать конкретные юз-кейсы.
По двум минусам я отпишусь ближе к конце недели, так как это хорошие и глубокие вопросы, которые требуют развернутого ответа. Пока лишь скажу, что очевидно не все возможно компилировать на фазе сборки.
Не получится, если мы вызываем компонент Title и передаем в color переменную
const Title = styled.h1`
font-size: 1.5em;
color: ${props => props.color};
`;Получится, так как статический анализ даст нам все варианты
const Title = styled.h1`
font-size: 1.5em;
color: ${props => props.theme[`header${capitalize(props.type)}`] || 'someDefaultColor'};
`;
const theme = {
headerPrimary: 'blue',
headerSuccess: 'green',
...
}Но в этом нет проблемы. Пишите определенным образом — получайте Performance, хотите больше гибкости — ок, но придется чем-то пожертвовать. В реакте комбинируют классы и inline-стили и ничего — полет нормальный.
Performance сейчас очевидно хуже, чем при чистом CSS, JSS, etc. Но проблем это мне не создает. Вообще обсуждать performance без цифр достаточно тяжело. Допускаю, что для ряда проектов на текущем этапе styled-components не подойдут и это нормально.
Сколько над вашим проектом работает фронтенд-разработчиков? А сколько верстальщиков? Есть ли у вас архитектор с хотя бы 5 летним стажем разработки? Сколько лет вашему проекту?
Без ответа на все эти вопросы сложно судить о "нормальности" полёта. Пока что я вижу большие сложности с поддержкой этой лапши. Что, впрочем, свойственно реактовому стеку.
Пример абсолютно не удачный, и мне жалко тех, кто так пишет:
const Title = styled.h1`
font-size: 1.5em;
color: ${props => props.primary ? 'blue' : 'purple'};
`;Просто потому, что это его максимум. Он не расширяеться никак. Вот нам нужны ещё стейты danger, success, как нам условие переписать?
Немогли бы вы привести пример который хорошо и удобно масштабируется?
Это точно :) Можно вот так
const Title = styled.h1`
font-size: 1.5em;
color: ${props => props.theme[`header${capitalize(props.type)}`] || 'someDefaultColor'};
`;theme.js
const theme = {
headerPrimary: 'blue',
headerSuccess: 'green',
...
}Usage:
<Title type="success">Hello World</Title>Еще очень здорово все это во Flow обернуть, тогда можно определить тип для prop Type
type TitleType = "primary" | "success";Теперь, если мы напишем, например, "suces" вместо "success", то IDE сразу же сообщит об ошибке
Ясно, спасибо. Немного подправлю и этот пример, потому что — интерполяция в интерполяции, а там ещё и трансформация?! :) Кхэ кхэ ...
styled.h1`
font-size: 1.5em;
color: ${props => props.theme.colors[props.type] || 'someDefaultColor'};
`;И вижу, что мы всё же работаем с каждым конкретным свойством. Если и font size зависит от type, выносите это тоже в тему? Не раздуваются ли темы тогда, что в них слишком много стейтов для разных компонент? Можно как-то именно расширять стили? Пример из вакуума:
const Title = styled.h1`
font-size: 1.5em;
color: someDefaultColor;
`;
Title = when(props.primary, Title)`
color: ${ theme.colors.green }
font-weight: bold;
font-size: 1.7em;
`;Ну, если будем последовательными props => props.theme.headers.h1.colors[props.type], но да, такой вариант мне тоже нравится.
Можно как-то именно расширять стили?
Да, можно через import
https://github.com/styled-components/styled-components#overriding-component-styles
Эта организационная работа была предоставлена таким методологиям как BEM, которые – хоть и полезны в этом отношении – все же не являются обязательными и не могут быть внедрены более универсально, на уровне языка или инструментов.
Могут. Получается весьма удобно. Другое дело, что к реакту с его кривой архитектурой прикрутить автоматическую генерацию бем-токенов сложновато.
Знакомство с Styled components