Comments 25
Если овладеть инструментами и фреймворками заранее, то настройка будет быстрой. Именно для этого и публикуются статьи, чтобы обратить внимание на новые технологии, чтобы люди их попробовали, повертели.
Разумеется, бросаться делать проект с жесткими сроками на незнакомом фреймоворке не нужно. Но и сидеть на любимом ламповом решении тоже не стоит, потому что рано или поздно его обгонят более современные альтернативы.
Не понимаю я этого переноса стилей в js-код. Ну понятно, что мол простые компоненты таким образом оказываются более цельными. Может оказаться, что со временем будет меньше мусора в стилях. Хотя с текущими темпами развития/изменения этого всего, стили едва ли успеют сильно "испортиться", прежде чем народ побежит всё переписывать на %newSuperWebTechnology%.
Но ведь есть всевозможные :hover, :link/:visited, media queries, разные там переменные, общие стили и прочее. Оно ведь довольно плохо (во всяком случае на первый взгляд) с этим дружит. А с этим приходится сталкиваться в больших приложениях. И что в итоге? Превращаем наши js-файлы в большие трудно-читаемые мусорки? Или держим часть стилей в js, а часть в scss/stylus/css/less/etc?
Одной из уникальных особенностей мира React является крупнейшее и очень активное сообщество опенсорс-разработчиков вокруг него.
Одной из уникальных особенностей мира Реакт является то, что Фейсбук имеет возможность вбухивать огромные денььги в раскрутку и пиар и таким образом задавать и контролировать вектор развития веб-разработки.
Скорее как будет развиваться веб решают те, кто решает, что использовать как на бекенде, так и на фронтенде. У меня, например, это rails + reactjs/webpack, на дружественых проектах это perl/python + angular и ember.
Не не не, спасибо, пусть программируют где-то в более других коворкингах под эти хипстерские смузи.
Я считаю, что для нового проекта автор(ы) имеют прав выбирать любой стек, но здравого смысла "вот это совсем свежак, может через месяц загнуться, так что лучше остановиться на проверенном реакте/эмбере/ангуляре", это не отменяет. А так — на переправе коней не меняют.
styled-components — новый прекрасный способ стилизовать React-компоненты…
Передовые методики...
Серьёзно?
Для начала, самое вкусное. В двух словах, библиотека генерит некий случайный класс, добавляет его к элементу, формирует style-тэг и добавляет в него контент вида .%имякласса% { тут из template-строки }. Идея не новая, но реализация…
Так как стили описываются в виде строк в js-файлах, то можно использовать интерполяцию и другие фишки. Вот к чему это приводит: http://www.webpackbin.com/E1Ow20nZM
В файле HelloWorld.js я объявляю 2 компонента, один из которых имеет кривые стили. Такое вполне может случиться с каждым, и такие кривые стили не применятся к этому компоненту, и мы, наверное, сможем найти где проблема?
Теперь смотрим в инспектор:
Круто! Косяк стилей в одном компоненте сломал стили другого.
Представьте, что у вас большое приложение и в одном компоненте строки-стили формируются динамически. И при одном состоянии приложения всё работает нормально, а при другом стили одного компонента где-то поломались, и часть компонентов (чьи стили будут ниже или сразу за поломанным) тоже сломаются, но другая их часть будет отображаться нормально.
Про source-map для стилей наверное даже спрашивать не стоит… Так что счастливого дебага! Искать какому из компонентов какой случайный класс соответствует будет увлекательно, особенно если компонентов за сотню.
Использовать эту либу с обычными готовыми компонентами тоже не так просто: если компонент не был создан через эту либу, в него нужно прокинуть класс (className={this.props.className}). Если простого доступа к исходнику компонента нет (например, импортим из библиотеки), придётся писать обёртку.
Ещё пример костылей прямо в документации: https://github.com/styled-components/styled-components/blob/master/docs/existing-css.md
Библиотека добавляет стили в конец head, так что если вы используете внешние стили и там в качестве селектора используется один класс, то скорее всего библиотека перебьёт правила из css (т.к. скорее всего её тэг будет ниже чем стили из css-файла). Выход? Автор предлагает просто продублировать селектор в css-файле:
/* my-component.css */
.red-bg.red-bg {
background-color: red;
}Вот они, передовые методики! Особенно это удобно, если вы подключаете внешнюю css-либу и править стили там лучше не стоит. Но самый интересный вопрос: вес селектора .cls не очень большой, перебить его извне достаточно просто. Но как с помощью styled-components перебить вышеуказанный селектор я так и не понял.
Ну и ещё по-мелочи. Библиотека использует простые имена классов, без префикса. Если у вас много внешних стилей, то вероятность, что styled-components сгенерит класс, имя которого уже есть в какой-то библиотеки далеко не нулевой. Забавно будет, если раз в год или месяц приложение будет спонтанно ломаться, так как имя класса совпало с селектором извне.
Для сравнения: в ангуляре стиль каждого компонента находится в отдельном style-тэге (один компонент не сломает стили других), по-умолчанию уникальные имена имеют префикс ng и используются в качестве атрибутов (у них вес больше, так что в случае необходимости перебить внешние стили намного легче). Однако, при необходимости это поведение можно изменить как для отдельного компонента, так и для всех разом.
Отличный комментарий, жаль Max Stoiber его не увидит потому что Хабр не читает.
Почему бы вам не завести issue в их репозиторий? Протекающие стили из одного компонента в другой — это значительная проблема, если на нее обратить внимание, то, может быть, и исправят.
Вот то как это сделано в реакте, мне очень понравилось, поломать стили сильно сложнее
Вот то как это сделано в реакте
А там как? Насколько я знаю там Inline-стили. И судя по количеству вопросов на эту тему в сети, это устраивает далеко не всех. Библиотека, упомянутая в статье, ещё одно тому подтверждение.
вот же описание, т.е там генерится свой особый хешик к названию класса и стилю для связки, чтобы как раз не поломать остальное — получается что если я правильно понимаю, компонент имеет свой кусок своего стиля и никак не должен мешать остальным, но варианта сломать все, это, конечно не отменяет. https://habrahabr.ru/company/jugru/blog/315772/#comment_9923636
Я что-то вас не понял. Вам нравится реализация стилей в реакте или в библиотеке styled-components?
Если первое, то поломать инлайн-стили сложно, но и писать их не очень удобно. Да и правильность подхода под вопросом.
Если второе, то поломать стили в styled-components очень легко, о чём я и написал. В ангуляре при похожем подходе гораздо сложнее.
Насколько я понимаю, это third-party library, а вовсе не React. В React же для стилей из своего только объекты в style-аттрибуте, как краткий синтаксис к domEl.style.
Стоит ли использовать MobX?
Так стоит или нет?
React.js State of the art (интервью с Max Stoiber)