Синтаксис 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, но при этом не придется заботиться о передаче состояния элементам, так как это происходит под капотом.

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

JSX Style

И наконец, последний в списке способ стилизации React-компонентов - JSX Style (есть еще утилитарные фреймворки, но это не специфический для React подход).

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

jsxstyle предлагает указывать стили в inline-режиме, то есть не выносить их в отдельный объект, а писать прямо в пропсах компонентов. Библиотека предоставляет несколько готовых компонентов с уже предустановленными стилями отображения (Block, Inline, Row и т. п.). При этом скомпилированные стили не остаются инлайновыми, а превращаются в нормальные CSS-таблицы, а компонент трансформируется в обычный HTML-тег с каким-то уникальным классом.

Пример: https://codesandbox.io/s/jsxstyle-react-junior-wn88n?file=/src/App.js

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

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

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

Атрибуты, которые не относятся к стилям и должны быть установлены прямо на HTML-элемент (вроде placeholder, type) можно передать в пропе props. Хотя в документации сказано, что такие свойства как placeholder, type, id можно указывать и на верхнем уровне компонента, но у меня это почему-то не сработало.

Поддерживаются псевдоэлементы и псевдоклассы. Чтобы задать, например, цвет плейсхолдера, нужно использовать свойство placeholderColor, а для изменения цвета при фокусе - focusColor.

Медиа-запросы тоже есть. Чтобы их использовать нужно указать список запросов в пропе mediaQueries, как объект, где у каждого запроса есть имя. Затем эти имена нужно использовать как префиксы для стилевых пропсов.

В качестве альтернативы такому громоздкому синтаксису можно использовать хук useMatchMedia.

В целом, мне не очень нравится образ мышления "jsxstyle", возможно, мой мозг для него еще просто не готов 🤯. Код получается, возможно, и более понятным (или нет), но уж точно намного более раздутым. Но что еще хуже, нет развернутой документации, только readme в репозитории. Так что дальше углубляться в jsxstyle, пожалуй, не буду.

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

CSS-переменные для React-разработчиков

Статья (англ.): https://www.joshwcomeau.com/css/css-variables-for-react-devs/

CSS-in-JS решения позволяют писать очень гибкие стили, но не следует забывать про нативные возможности CSS. Автор статьи считает, что CSS-переменные aka кастомные свойства - это очень мощный инструмент, который иногда может переплюнуть все эти ваши JS-интерполяции.

CSS-переменные дают возможность изменять значения, а не свойства. Они декларативны, и код с ними становится короче и чище. CSS-переменные наследуются вложенными элементами, а при необходимости с ними можно легко взаимодействовать из JS-кода. Ко всему прочему, с помощью переменных можно анимировать то, что нельзя анимировать другими способами, например, градиенты (с некоторыми оговорками).

В статье рассмотрен конкретный кейс обеспечения доступности кнопки на тач-устройствах - в двух вариантах: CSS-in-JS (Styled Components) и CSS-переменные.

В целом полностью поддерживаю мнение автора, CSS-переменные - очень мощная штука, к тому же нативная.

#стили #ссылки

По итогам опроса CSS Модули и препроцессоры вырвались вперед :) React JSS догоняет, остальные отстают.

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

Из других решений мне более симпатичен React JSS. У Styled Components не нравится синтаксис, Radium кажется недоделанным, JSX Style избыточным, а React Shadow слишком радикальным.

#стили