В течение многих лет разработчики React импортировали таблицы стилей в свои файлы .js или .jsx. Достаточно простая и стандартная практика, правда?

Это достаточно простой загружаемый файл App.js, сгенерированный create-react-app. Теоретически проект, который выглядит так, не выглядит таким пугающим для работы. Черт возьми, что плохого в использовании декларативных семантических html-элементов и имен классов для украшения их с помощью CSS в этом сценарии?

Очевидно, что наши приложения никогда не были такими простыми.

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

Локализация стилей компонентов

По мере роста вашего приложения React растет и потребность в таблицах стилей для оформления составляющих его компонентов. Проект с несколькими таблицами стилей можно поддерживать, если вы работаете в одиночку. Тем не менее, в групповой работе несколько таблиц стилей работают.

Но что происходит, когда потребность в таблицах стилей растет и растет?

В итоге мы создаем больше имен классов и составных имен классов, которые используются в сочетании со стилями элементов, условно основанными на состоянии компонента. Иногда мы используем такие библиотеки, как material, и нам нужно переопределить стиль компонента (например, Card).

Мы могли бы указать имя класса материала Card MuiPaper-root и применить стиль поверх, используя !important. Но возникает вопрос… нужен ли нам ненастраиваемый компонент в другом месте? дочерний компонент родительскому компоненту, импортирующему этот измененный стиль, как мы можем убедиться, что получаем исходный компонент, нетронутый нашим собственным CSS?

Мы все в какой-то момент сталкивались со стилями, которые переопределяли друг друга в неправильных местах и ​​в неподходящее время, усугубляя проблему большим количеством имен классов в качестве идентификатора, что еще больше увеличивало наши файлы CSS.

TLDR: нам нужно, чтобы стили наших компонентов были доступны для других разработчиков, были понятны с первого взгляда и локализованы там, где они нам нужны.

В приведенном выше примере, используя styled, мы можем задать стиль целевому атрибуту в компоненте Card и локализовать этот стиль. Первоначальный компонент карты остался без изменений, как и предполагалось.

Вы можете себе представить, если бы мы стилизовали имя класса MuiPaper-root в файле CSS и импортировали его на верхнем уровне?

Обходным решением для использования styled является типичный способ добавления атрибута classname к компоненту Card для его стилизации. Это прекрасно работает, но на самом деле не все компоненты, которые вы можете использовать, позволяют наследовать имена классов. И даже в этом случае вы бы предпочли заполнить свой CSS кучей имен классов для каждого возможного варианта компонента или создать четко определенные компоненты, которые можно повторно использовать с локализованными стилями?

Твой выбор!

Сплоченность компонентов между состоянием и стилем

По мере изменения состояния нашего компонента стили наших компонентов также должны иногда меняться. Примером этого может быть форма регистрации пользователя, в которой, когда длина имени пользователя или пароля составляет менее 3 символов, ввод выделяется красным цветом, в противном случае он выделяется зеленым цветом.

Довольно простое поведение, которое мы хотели бы видеть в любом из наших приложений (настолько же безобразное, как и реализация выше). Чтобы достичь этого, мы могли бы дополнительно применить имя класса к входным данным, поскольку состояние для значения обновляется. Возможно, мы могли бы даже использовать свойство встроенного стиля для ввода и применить к нему этот набор троичных стилей.

Есть ли способ лучше? Я бы предложил следующее, намного чище и с ним проще работать.

Внутри стилизованного компонента мы можем получить доступ к любому реквизиту, переданному компоненту, где бы он ни использовался. Я бы хотел, чтобы вы на мгновение представили сложный (в смысле стиля) компонент, который имеет множество аспектов и должен реагировать на различные переданные ему свойства. Используя стилизованный компонент, мы можем создать четкое разделение стиля компонента и его логики.

TLDR: позвольте экземпляру компонента работать, а стилизованный класс обрабатывает то, что должно происходить стилистически.

Разве это не лучше, чем опциональное применение имен классов или работа непосредственно в свойствах стилей?

Реагировать на родную совместимость

Это довольно короткая причина, чтобы начать использовать styled — его можно использовать и с React Native!

Старую добрую поговорку «Узнай один раз, пиши где угодно» с React и React Native можно распространить и на стилистический аспект ваших приложений, используя стили.

Построено в Sass

Так ты любишь Сасса, да? Хорошие новости, styled поддерживает Sass. Вы, возможно, заметили, что в первом примере, где мы стилизовали компонент Card из материала, я использовал синтаксис Sass, чтобы выбрать имя класса MuiPaper-root в компоненте для непосредственного нацеливания моих стилей.

Идеальный опыт CSS-in-JS уже здесь. Давайте посмотрим на другой пример!

Мы можем воспользоваться всеми крутыми вещами, которые Sass может предложить нам для стилизации. Довольно аккуратно, да?

А как насчет глобальных переменных CSS?

Итак, вы говорите, что мы можем использовать Sass в наших стилизованных компонентах, но как насчет использования старых добрых глобальных переменных? Поскольку стилизация позволяет использовать изолированные компоненты, как насчет этих глобальных многократно используемых цветов, значков, шрифтов и т. д.?

Не бойся. Вопреки тому, во что вас уверяет эта статья, вам не нужно полностью выбрасывать импортированные таблицы стилей.

Давайте отредактируем файл App.css, который у меня есть:

Результатом этого является следующее:

Проверив стилизованный h1 в нашей консоли разработчика, мы можем увидеть успешно примененную переменную CSS.

Сейчас самое время упомянуть, что styled управляет именами классов внутри себя, которые отображаются, чтобы избежать конфликтов имен классов.

В заключении…

Это отличный инструмент для использования в ваших приложениях React, как нативных, так и веб-приложений. Я не стал подробно рассматривать синтаксис здесь, кроме примеров, но я опубликую статью в будущем, чтобы сделать это. А пока вы можете посетить https://styled-components.com/ для обучения!

Удачной укладки, друзья.