• 9 минут чтения

• Кодирование, JavaScript, веб-компоненты

• Поделись Твиттер, Линкедин

После этого сдвига мышления в сторону создания пользовательских интерфейсов на основе компонентов мы сейчас находимся в том, что мы любим называть «век компонентов». Рост фреймворков JavaScript, таких как React, Ember и недавно Angular 2, усилия W3C по стандартизации системы собственных веб-компонентов, библиотеки шаблонов и руководства по стилю, которые считаются «правильным способом» для создания веб-приложений, и многое другое. осветили эту революцию.

Лучшие практики в компонентных системах

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

Дальнейшее чтение на SmashingMag:

• Стилизация веб-компонентов с использованием общей таблицы стилей
• Взгляд в будущее с React Native для Интернета
• Наконец, CSS в JavaScript! Познакомьтесь с CSSX

Build-Small Components

Вместо того, чтобы полагаться на классы для композиции, используйте компоненты в своих интересах и компонуйте их вместе. Например, представьте себе Button компонент, который рендерит <button class=“btn”> в ДОМ. Можно также отобразить большую и более важную кнопку. Сделать большую кнопку было бы так же просто, как прикрепить btn–primary класс в DOM: <button class=“btn btn–primary”>.

Вместо того, чтобы заставлять пользователей компонента знать, какой конкретный класс следует присоединить, Button компонент должен иметь primary имущество. Сделать основную кнопку было бы так же просто, как <Button primary />! Вот как мы могли бы это реализовать:

// Button.js

function Button(props) {
  const className = `btn${props.primary ? ' btn—-primary' : ''}`
  return (
    <button className={className}>{props.children}</button>
  );
}

Теперь пользователям больше не нужно знать, к какому конкретному классу он относится; они просто отображают основную кнопку. Что происходит, когда primary свойство установлено деталь реализации компонента. Изменение стиля, классов или поведения кнопки теперь требует редактирования только одного файла, в котором создается компонент, вместо сотен файлов, в которых он используется.

Разделить контейнер и презентационные компоненты

С React некоторые из ваших компонентов могут иметь связанное с ними состояние. Попробуйте отделить компоненты, которые обрабатывают данные и/или логику (например, форматирование данных), от компонентов, которые обрабатывают стили. Разделив эти две проблемы, будет намного проще рассуждать об изменениях в базе кода.

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

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

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

Иметь одноразовые имена классов

Возвращаясь к нашему Button компонент, он имеет .btn класс. Изменение стилей этого класса не должно влиять ни на что, кроме Button. Если изменить background-color в моем .btn класс портит макет шапки и дает футеру две колонки вместо трех, значит что-то не так. Это нарушает всю предпосылку наличия независимых компонентов.

По сути, это сводится к использованию каждого класса в вашем CSS только один раз (за исключением «примесей», таких как .clearfix). Таким образом, ошибки, подобные приведенной выше, никогда не возникнут.

Проблема, как всегда, в нас, людях. Вы когда-нибудь сталкивались с ошибкой в ​​программе? Он был там только потому, что его туда положил человек. Если бы программы могли существовать без людей, то ошибок не было бы. Человеческая ошибка объясняет каждую ошибку, которую вы когда-либо находили и устраняли.

Eсть известная шутка в мире фронтенд-разработки:

Два свойства CSS входят в панель. Барный стул в совершенно другом баре падает.

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

Имея в виду это и некоторые другие вещи, Глен Мэддерн и я сел и начал думать о стиле в этой новой эре. Мы не хотели заново изобретать или избавляться от CSS; это язык, созданный для стилей и изначально поддерживаемый браузерами. Вместо этого давайте возьмем лучшие части CSS и сделаем практически невозможной человеческую ошибку в компонентных системах.

Применение лучших практик

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

В стандартном CSS это будет имя класса (или, может быть, идентификатор). Со стилями в библиотеках JavaScript в React это либо установка класса из переменной, либо передача объекта JavaScript в style имущество.

Поскольку мы хотим использовать каждый класс только один раз, что, если мы просто удалим это сопоставление?

Как оказалось, таким образом мы также усиливаем разделение между контейнерными и презентационными компонентами и гарантируем, что разработчики смогут создавать только небольшие и специализированные компоненты.

Еще одна интересная особенность стилизованных компонентов заключается в том, что они позволяют вам писать фактический CSS в вашем JavaScript (а не только в объектах CSS-as-JavaScript). Он использует редко используемую функцию ECMAScript 2015 (новая версия стандарта JavaScript), называемую помеченными литералами шаблонов, чтобы сделать эту работу приятной для разработчика.

Основы

Теперь вам может быть интересно, как это выглядит. Что ж, давайте посмотрим!

const Title = styled.h1`
  color: palevioletred;
  font-size: 1.5em;
  text-align: center;
`;

Теперь вы можете использовать этот компонент React, как и любой другой:

<Wrapper>
  <Title>Hello World, this is my first styled component!</Title>
</Wrapper>

Здесь происходит довольно много вещей, поэтому давайте разберем этот фрагмент кода.

styled.h1 это функция, которая при вызове возвращает компонент React, отображающий <h1> в ДОМ. Если вам интересно: «Где мы вызываем эту функцию? Я вижу только обратные кавычки, без скобок!» именно здесь в игру вступают функции ECMAScript 2015.

То, что вы видите выше, является помеченный литерал шаблона, что является новой функцией языка JavaScript. (Для использования стилизованных компонентов не требуется специальных инструментов.) Вы можете вызывать функции с обратными кавычками (например, styled.h1``), и они получат строку, переданную в качестве первого аргумента. По ходу дела вы увидите, чем это отличается от обычного вызова функций с помощью круглых скобок, но пока остановимся на этом.

Итак, это styled.h1 вызов возвращает компонент React. К этому компоненту React прикреплен класс, который автоматически генерирует и уникализирует стилизованные компоненты. Это имя класса имеет связанные с ним стили, которые вы передаете в литерал шаблона.

Подводя итог, это означает, что styled.h1 call возвращает компонент React, к которому применены стили, которые вы передаете литералу шаблона.

Полная поддержка CSS

Поскольку styled-components — это просто CSS, он прекрасно поддерживает все CSS. Медиа-запросы, псевдоселекторы, даже вложенность просто работают. Мы генерируем имя класса и внедряем CSS в DOM; Итак, все, что работает в CSS, работает и со стилизованными компонентами.

const Input = styled.input`
  font-size: 1.25em;
  border: none;
  background: papayawhip;
  /* ...more styles here... */

  &:hover {
    box-shadow: inset 1px 1px 2px rgba(0,0,0,0.1);
  }

  @media (min-width: 650px) {
    font-size: 1.5em;
  }
`;

Этот Input компонент теперь будет иметь приятные стили при наведении и будет изменять свой размер, чтобы быть немного больше на больших экранах. Давайте посмотрим, как выглядит один из этих входных данных с заполнителем и без него:

Как видите, создать контейнерный компонент со стилем или презентационный компонент с логикой невозможно. Мы также создаем множество небольших компонентов и объединяем их в более крупные контейнеры, а поскольку видимых классов нет, мы не можем использовать их более одного раза.

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

Подведение итогов

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

Вот несколько различных ссылок, связанных со стилями в JavaScript, которые не являются специфическими для стилизованных компонентов, но которые говорят о теме в более общем плане:

• «Компоненты стиля React JS» (видео), Майкл Чан, Full Stack Talks Потрясающий доклад об использовании компонентов в качестве конструкции стиля. Если вы используете React и еще не слышали это выступление, прекратите то, что вы делаете, и посмотрите его прямо сейчас.
• «Магия позади? styled-components», Макс Штойбер. Эта статья, написанная вами, глубоко погружается в теговые литералы шаблонов, как они работают и почему они очень полезны, на примере styled-components.
• «Будущее многократно используемого CSS» (видео), Глен Мэддерн, ColdFront16 должен Работа. Многие из этих идей попали в библиотеку.
• «Визуализация меню обучения Академии Хана, где бы я ни хотел», Джордан Скейлс. Отличная статья, в которой документируется переход сложной базы кода от комбинации Handlebars и LESS к React и стилям в JavaScript. Настоятельно рекомендуется, если вы не уверены, подходит ли вам React или стили в JavaScript.

(рб, вф, ил, ык, ал)