Синтаксис JSS. Keyframes

Анимации также задаются в отдельном свойстве объекта стилей.

const styles = {
  '@keyframes slideRight': {
    from: {opacity: 0},
    to: {opacity: 1}
  }
}

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

const styles = {
  // ...
  container: {
    animationName: '$slideRight'
  }
}

#документация #стили #jss #примерыкода

Синтаксис JSS. Фоллбэки

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

В JSS это делается вот так:

const styles = {
  container: {
    background: 'linear-gradient(to right, red 0%, green 100%)',
    fallbacks: {
      background: 'red'
    }
  }
}

Сгенерированный код:

.container-0 {
  background: red;
  background: linear-gradient(to right, red 0%, green 100%);
}

Если нужно несколько фоллбэков, их можно указать в массиве:

const styles = {
  container: {
    display: 'flex',
    fallbacks: [{display: 'box'}, {display: 'flex-box'}]
  }
}

#документация #стили #jss #примерыкода

Синтаксис JSS. Font Face

По аналогии с медиа-запросами, правило @font-face указывается в отдельном свойстве объекта стилей:

const styles = {
  '@font-face': {
    fontFamily: 'MyWebFont',
    src: 'url(webfont.eot)'
  }
}

Или в виде массива, если шрифтов несколько:

const styles = {
  '@font-face': [
    {
      fontFamily: 'MyWebFont',
      src: 'url(webfont.eot)'
    },
    {
      fontFamily: 'MySecondFont',
      src: 'url(webfont2.eot)'
    }
  ]
}

Вообще все @-правила указываются подобным образом:

const styles = {
  '@charset': '"utf-8"',
  '@import': 'url(http://mysite.com/custom.css)',
  '@namespace': 'url(http://mysite.com/xhtml)'
}

#документация #стили #jss #примерыкода

Синтаксис JSS. Сложные значения

Если нужно задать какому-то свойству несколько значений, например, несколько фоновых изображений, в обычном CSS мы обычно разделяем их запятой.

Если мы используем короткий вариант свойства, например, margin вместо margin-top + margin-left + margin-right + margin-bottom, то отдельные значения мы разделяем пробелом.

JSS предлагает подобные конструкции оформлять в виде массивов:

const styles = {
  button: {
    margin: [5, 10]
  }
}

Или даже в виде массивов массивов, если у вас несколько составных значений:

const styles = {
  button: {
    background: [
      ['url(image1.png)', 'no-repeat', 'top'],
      ['url(image1.png)', 'no-repeat', 'right']
    ]
  }
}

Кроме того, помним, что короткое свойство можно разбить на составляющие:

const styles = {
  button: {
    background: {
      color: 'white',
      image: 'url("/some/url/image.png")',
      repeat: 'no-repeat',
      position: 'contain'
    }
  }
}

Быстро потестировать JSS-синтаксис можно здесь: https://cssinjs.org/repl/

#документация #стили #jss #примерыкода

Синтаксис JSS

!important

Чтобы добавить к значению свойства модификатор !important, нужно использовать массивы:

const styles = {
  button: {
    color: [['red'], '!important'],
    margin: [[5, 10], '!important']
  }
}

Выглядит избыточно, так что это еще одна хорошая причина не использовать !important.

content

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

const styles = {
  button: {
    '&:after': {
      content: '"JSS"'
    }
  }
}

Тут же отметим, что в качестве ссылки на элемент для вложенных селекторов псевдоэлементов используется символ &, как в SCSS.

#документация #стили #jss #примерыкода

Синтаксис JSS. CSS Гудини

JSS поддерживает API CSS Houdini:

const styles = {
  button: {
    margin: CSS.px(10)
  }
}

Главное, не забывать про полифилл для браузеров без поддержки.

Вот здесь есть пример кода: https://codesandbox.io/s/houdini-typed-value-jmec9
А вот здесь можно почитать подробнее про CSS Houdini (рус.): https://habr.com/ru/post/494660/

#документация #стили #jss #примерыкода #ссылки

Создание универсальной UI-библиотеки

Доклад с конференции YaTalks 2021, которая проходила в начале декабря 2021: https://www.youtube.com/watch?v=0LuKoLJ3zbU

Время: 35 минут, можно смотреть на скорости 1.25.

Разработчик из Яндекса, который занимается созданием общей библиотеки компонентов (для всех сервисов Яндекс, очевидно), рассказывает о том, зачем нужен универсальный UI Kit, какие проблемы современного веба он должен решать, а главное, как же его создать.

Он предлагает выносить из компонентов всю императивную логику в хуки (весь код на React) и использовать ее декларативно.

Если у вас есть компонент Button, у которого есть состояние hover, то это состояние не нужно создавать в самом компоненте, а следует вынести в хук useHover. Из хука следует вернуть собственно флаг isHovered, а также набор атрибутов, которые нужно поместить на HTML-элемент кнопки, чтобы все заработало.

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

Еще более полезный хук usePressed, который отслеживает состояние "нажатия". Недостаточно поставить обработчик только на событие клика, чтобы знать, когда ваша кнопка нажата. Нужно учитывать также клавиатурные события (нажатие на Enter или Space, когда кнопка находится в фокусе), тач-события и т.д. Всю эту логику полезно инкапсулировать в хуке, из которого наружу торчит только флаг isPressed и атрибуты, которые нужно установить для HTML-элемента.

Это примеры вынесения в хук интерактивного взаимодействия. Таким же образом можно выделять состояние компонента (ToggleState - включен/выключен, SelectState - выбранный элемент из списка) или его семантику (Select, Button и т.д.) Это уже могут быть более сложные хуки, которые под капотом используют композицию более простых. Например, хук useOption представляет элемент списка и может отслеживать состояния isFocused и isSelected.

Помимо основной логики в такие хуки можно поместить всю необходимую HTML-семантику - aria-атрибуты, так что вам не придется задумываться об этом.

Отдельные хуки легче тестировать, описывать и переиспользовать.

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

Репозиторий с примерами кода: https://github.com/use-platform/use-platform. Здесь уже реализованы многие хуки для интерактивности и семантики.

#ссылки #хуки #паттерны

​JSS + React

В React-приложениях можно, конечно, использовать базовый пакет JSS, но лучше все-таки воспользоваться специальным пакетом react-jss. У него есть ряд преимуществ:

1. Дефолтный пресет плагинов уже установлен.
2. Извлекается критический CSS.
3. Создаются таблицы стилей только для смонтированных компонентов.
4. Правила, заданные в виде функций, обновляются автоматически.

https://codepen.io/furrycat/pen/xxPwmvM?editors=0010

Для создания стилей нам понадобится функция createUseStyles. Она получает стили в виде объекта и возвращает пользовательский хук (в документации он назван useStyles), который можно использовать в компонентах.

Из хука возвращается объект, содержащий сгенерированные имена классов.

Официальная песочница: https://codesandbox.io/s/j3l06yyqpw

#документация #стили #jss #примерыкода

React JSS. Динамические свойства

При использовании react-jss не нужно обновлять таблицу стилей вручную. Достаточно передать в хук данные, которые могут изменяться. При изменении этих данных стили тоже автоматически изменятся.

https://codepen.io/furrycat/pen/QWOjYjO?editors=0011

#документация #стили #jss #примерыкода

​Префикс для имен классов

При необходимости можно добавить сгенерированным классам определенный префикс.

Метод createUseStyles принимает вторым параметром объект с настройками. Желаемый префикс нужно указать в поле name.

#документация #стили #jss #примерыкода

React JSS. Темы

Для поддержки тем нам потребуется готовый компонент ThemeProvider. Ему нужно передать в проп theme текущую тему (в виде объекта или функции).

Далее есть два способа использовать тему в компоненте.

Способ #1

https://codesandbox.io/s/react-jss-temy-react-junior-f6d6x?file=/src/Button1.js

Чтобы выцепить тему в компоненте, используем готовый хук useTheme. Он возвращает тему, которую мы передаем как параметр в хук useStyles вместе с остальными динамически изменяющимися данными. При изменении темы, стили тоже изменятся.

Способ #2

https://codesandbox.io/s/react-jss-temy-react-junior-f6d6x?file=/src/Button2.js

Вместо объекта стилей нужно передать в метод createUseStyles функцию. Первым параметром этой функции как раз и будет тема. Из функции нужно вернуть объект стилей.

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

Второй способ удобнее, если много css-свойств зависят от темы. Тогда их не придется оформлять в виде функций. А первый способ лучше выглядит, когда кроме темы стили зависят от других пропсов.

#документация #стили #jss #примерыкода

​React JSS. Отдельные контексты тем

Можно создавать собственные контексты тем, с собственными провайдерами и хуками useTheme, например, чтобы избежать конфликтов разных тем.

Контекст создается с помощью функции createTheming. А потом из него уже берутся ThemeProvider и хук useTheme.

Подробнее в документации: https://cssinjs.org/react-jss?v=v10.9.0#using-custom-theming-context

#документация #стили #jss

Настройка JSS с помощью JssProvider

react-jss предоставляет компонент JssProvider, который позволяет более тонко настроить механизм работы JSS. Соответственно все настройки будут действовать для дочерних компонентов провайдера.

С помощью JssProvider, например, можно изменить функцию, которая генерирует имена классов.

Подробнее в документации: https://cssinjs.org/react-jss?v=v10.9.0#class-name-generator-options

#документация #стили #jss

Получив представление о React JSS идем дальше по списку способов стилизации React-компонентов.

Следующий в списке Radium, но честно говоря, он выглядит каким-то не очень живым.

Репозиторий: https://github.com/FormidableLabs/radium

Radium - это опенсорсная библиотека от Formidable. В репозитории указано, что она стабильна, изменения больше не вносятся. На npm довольно много скачиваний.

Разберем его коротко, для общего развития.

Компонент высшего порядка

Radium - это HOC, то есть функция, которая оборачивает ваш компонент как декоратор, добавляя к нему некоторую функциональность. В данном случае - это функциональность обработки стилей.

Стили предполагается оформлять в виде объекта, практически как в JSS, с некоторыми тонкостями.

Основная же идея здесь в том, что мы имеем дело с inline-стилями. То есть Radium не генерирует CSS, а навешивает стили прямо на элемент.

Он даже умеет эмулировать псевдоклассы :focus, :hover и :active - с помощью отслеживания событий из JavaScript. Из-за такого механизма не получится, например, эмулировать ховер из панели разработчика.

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

В целом на первый взгляд выглядит довольно проблемно: инлайновые стили, эмуляция состояний из JavaScript, не поддерживаются другие псевдоклассы, нет псевдоэлементов.

Небольшая практика: https://codesandbox.io/s/radium-react-junior-3utg2?file=/src/Button.js

#документация #стили #radium #примерыкода

Визуальное руководство по хуку useEffect

Статьи (англ.):

👉 Первая часть (основная информация)
👉 Вторая часть (сброс эффекта)

Неплохая статья с анимированными примерами кода. Поможет освежить в памяти (или немного глубже понять), как работает хук useEffect в React.

Вкратце:

✔️ Любые действия с сайд-эффектами внутри компонента должны выполняться внутри хука useEffect, иначе мы можем получить бесконечный цикл (эффект запускается при рендеринге, меняет состояние компонента, вызывает новый рендеринг и по кругу).

✔️ Функция переданная в useEffect запускается после рендеринга. Можно также установить зависимости. Если какая-то зависимость изменилась, эффект запускается.

✔️ Если эффект продолжает работать даже после размонтирования компонента (например, setInterval), его нужно очищать. Для этого из эффекта нужно вернуть функцию, которая очистит последствия этого эффекта.

#хуки #ссылки

​React Shadow

Еще один способ стилизовать приложение React - использовать теневой DOM. Shadow DOM - это изолированное DOM-дерево внутри главного DOM-дерева документа. В нем не действуют стили документа, то есть не возникает никаких конфликтов.

Теневой DOM внутри какого-либо элемента (хоста), можно создать и с помощью обычного JavaScript, но так как мы работаем с React, будет логично взять готовый модуль react-shadow.

https://codesandbox.io/s/react-shadow-react-junior-4pko0?file=/src/App.js

Импортируем из модуля объект root. Чтобы создать Shadow Host, используем компонент root.div. Это автоматически создаст обычный div-элемент с теневым dom. Все, что вы поместите внутрь root.div будет находиться уже в теневом dom.

__Примечание: Вместо root.div можно использовать root.article, root.p, root.h1, и другие элементы, к которым по спецификации можно прикрепить теневой dom.__

Чтобы стилизовать то, что находится "в тени", нужно передать туда стили - как обычный тег style. Важно, что это должна быть именно строка стилей (не объект), поэтому если вы импортируете стили из другого файла, убедитесь это именно строка.

Стили, расположенные внутри shadow dom действуют только на этот shadow dom. При этом внешние стили документа сюда не проникают.

#стили #shadowdom #примерыкода

React Shadow

Немного более пристальный взгляд на react-shadow: https://codesandbox.io/s/react-shadow-2-react-junior-fd58m?file=/src/App.js

Все фичи React работают, состояние внутри теневого dom меняется, на хост можно установить `ref`и через него добраться до shadow root.

#стили #shadowdom #примерыкода

3 паттерна для создания React-компонентов

Статья (англ.): https://blog.openreplay.com/3-react-component-design-patterns-you-should-know-about

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

Презентационные компоненты и компоненты-контейнеры

Презентационные компоненты отвечают только за внешний вид. Они получают данные через пропсы, выводят их и никак не зависят от других компонентов. Очень часто презентационные компоненты не имеют состояния, но также могут отслеживать какое-то состояние, связанное с интерфейсом (например, текст в поле ввода). Примеры презентационных компонентов: список элементов, поле ввода.

Компоненты-контейнеры обеспечивают логику приложения. У них есть состояние, они используют различные методы жизненного цикла и содержат в себе презентационные компоненты для вывода данных. Именно в контейнерных компонентах происходит запрос и обработка данных.

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

Провайдер

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

Пример Провайдера в React - это контекст. Мы создаем объект контекста с нужными данными (например, цветовой темой приложения), оборачиваем все приложение в провайдер этого контекста и в нужных местах связываемся с ним с помощью хука useContext, или свойства contextType, или Context.Consumer.

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

Составные компоненты

Компоненты в React могут работать в симбиозе, разделяя общее состояние. Например, компонент списка (Menu) и компоненты отдельных элементов списка (MenuItem). Вынесение элементов в отдельные компоненты может быть удобно с точки зрения передачи пропсов и структуризации кода.

Но у Menu и MenuItem есть общее состояние - активный элемент, оно должно храниться в компоненте Menu, значит, его нужно передать во все вложенные компоненты MenuItem. Об этом должен позаботиться сам компонент списка (например, с помощью React Context), тогда мы получим составной компонент (compound component).

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

#паттерны #ссылки