JavaScript | Взаимодействие с CSS
333 68Веб-программирование — JavaScript — Взаимодействие JavaScript и CSS
Каскадные таблицы стилей (Cascading Style Sheets — CSS) — это стандарт визуального представления HTML-документов. Каскадные таблицы стилей предназначены для использования дизайнерами: они позволяют точно определить шрифты, цвета, величину полей, выравнивание, параметры рамок и даже координаты элементов в документе.
Но они также представляют интерес и для программистов, пишущих на клиентском языке JavaScript, потому что позволяют воспроизводить анимационные эффекты, такие как плавное появление содержимого документа из-за правого края, например, или сворачивание и разворачивание списков, благодаря чему пользователь получает возможность управлять объемом отображаемой информации.
Управление встроенными стилями
Самый простой способ управления стилями CSS — это манипулирование атрибутом style отдельных элементов документа. Как и для большинства HTML-атрибутов, атрибуту style соответствует одноименное свойство объекта Element, и им можно манипулировать в сценариях на языке JavaScript. Однако свойство style имеет одну отличительную особенность: его значением является не строка, а объект
Например, чтобы вывести содержимое текстового элемента e крупным, полужирным шрифтом синего цвета, можно выполнить следующие операции для записи желаемых значений в свойства, которые соответствуют свойствам стиля font-size, font-weight и color:
e.style.fontSize = "24px";
e.style.fontWeight = "bold";
e.style.color = "blue";При работе со свойствами стиля объекта CSSStyleDeclaration не забывайте, что все значения должны задаваться в виде строк. В таблице стилей или атрибуте style можно написать:
position: absolute;
font-family: sans-serif;
background-color: #ffffff; Чтобы сделать то же самое для элемента e в JavaScript, необходимо заключить все значения в кавычки:
e.style.position = "absolute";
e.style.fontFamily = "sans-serif";
e.style.backgroundColor = "#ffffff";Обратите внимание, что точки с запятыми не входят в строковые значения. Это точки с запятой, употребляемые в синтаксисе языка JavaScript. Точки с запятой, используемые в таблицах стилей CSS, не нужны в строковых значениях, устанавливаемых с помощью JavaScript.
Кроме того, помните, что во всех свойствах позиционирования должны быть указаны единицы измерения. То есть:
e.style.left = 300; // Неправильно: это число, а не строка
e.style.left = "300"; // Неправильно: отсутствуют единицы измерения
e.style.left = "300px"; // ПравильноЕдиницы измерения обязательны при установке свойств стиля в JavaScript — так же, как при установке свойств стиля в таблицах стилей.
Многие CSS-свойства стиля, такие как font-size, содержат в своих именах дефис. В языке JavaScript дефис интерпретируется как знак минус, поэтому нельзя записать выражение, приведенное ниже:
e.style.font-size = "24px"; // Синтаксическая ошибка!Таким образом, имена свойств объекта CSSStyleDeclaration слегка отличаются от имен реальных CSS-свойств. Если имя CSS-свойства содержит дефисы, имя свойства объекта CSSStyleDeclaration образуется путем удаления дефисов и перевода в верхний регистр буквы, непосредственно следующей за каждым из них. Другими словами, CSS-свойство border-left-width доступно через свойство borderLeftWidth, а к CSS-свойству font-family можно обратиться через свойство fontFamily.
Кроме того, когда CSS-свойство, такое как float, имеет имя, совпадающее с зарезервированным словом языка JavaScript, к этому имени добавляется префикс «css», чтобы создать допустимое имя свойства объекта CSSStyleDeclaration. То есть, чтобы прочитать или изменить значение CSS-свойства float элемента, следует использовать свойство cssFloat объекта CSSStyleDeclaration.
Атрибут style HTML-элемента — это его встроенный стиль, и он переопределяет любые правила стилей в таблице CSS. Встроенные стили в целом удобно использовать для установки значений стиля, и именно такой подход использовался во всех примерах выше. Сценарии могут читать свойства объекта CSSStyleDeclaration, представляющего встроенные стили, но они возвращают осмысленные значения, только если были ранее установлены сценарием на языке JavaScript или если HTML-элемент имеет встроенный атрибут style, установивший нужные свойства.
Например, документ может включать таблицу стилей, устанавливающую левое поле для всех абзацев равным 30 пикселам, но если прочитать свойство leftMargin одного из этих элементов, будет получена пустая строка, если только этот абзац не имеет атрибут style, переопределяющий значение, установленное таблицей стилей.
Чтение встроенного стиля элемента представляет особую сложность, когда выполняется чтение свойств стиля, имеющих единицы измерения, а также свойств сокращенной формы записи: сценарий должен включать далеко не простую реализацию синтаксического анализа строк с CSS-стилями, чтобы обеспечить возможность извлечения и дальнейшего использования значений. В целом, встроенный стиль элемента удобно использовать только для установки стилей.
Иногда бывает проще прочитать или зап
особенности работы со стилизованными компонентами
От автора: CSS никуда не девается. Множество проектов предпочитают стилизовать документы через JS по недопониманию. В этой статье собраны распространенные мифы об использовании в JavaScript CSS и существующие решения этих проблем.
Статья не нацелена навредить определенным проектам или людям. «CSS в JS» я определяю, как использование styled-components. Сейчас это тренд стилизации компонентов в React.
История CSS и JS
Каскадные таблицы стилей (CSS) были созданы для описания представления документа, написанного с помощью языка разметки. JS был создан как «связующий язык» для связки компонентов, таких как изображения и плагины. Шли годы, JS рос и мутировал под новые примеры использования.
Появление термина Ajax (2005) – важная веха. Именно тогда библиотеки типа Prototype, jQuery, MooTools привлекли огромные сообщества к совместному решению проблем получения данных в фоновом режиме и неоднородности работы кода в разных браузерах. Так была создана новая проблема – как управлять всеми данными?
Перенесемся в 2010. Backbone.js стал стандартом управления состоянием приложения. Почти сразу после этого появились React и Flux. Так началась эра одностраничных приложений (SPA) – приложений, состоящих из компонентов.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнееЧто же с CSS?
В документации к styled-components:
«Проблема чистого CSS заключается в том, что он создавался в эру, когда веб состоял из документов. В 1993 году был создан интернет для обмена по большей части научными документами, и CSS был представлен, как решение стилизации этих документов. Сегодня мы создаем богатые, интерактивные, user-facing приложения, и CSS не предназначен для них.»
Не соглашусь.
CSS эволюционировал под требования современных UI. Количество новых функций, появившихся за последние 10 лет, выходит за рамки разумного (псевдоклассы, псевдоэлементы, CSS переменные, медиа запросы, кейфреймы, комбинаторы, колонки, flex, сетки, вычисляемые значения…).
С точки зрения UI компонент – это изолированный фрагмент документа (button — компонент). CSS придумали для стилизации документов, которые полностью состоят из компонентов. Так в чем же проблема?
Как говорится «используйте правильный инструмент для работы».
Стилизованные компоненты
styled-components позволяют писать CSS в JS с помощью шаблонных литералов из тегов. Они удаляют связь между компонентами и стилями – компонент превращается в стилевую конструкцию низкого уровня.
import React from ‘react’; import styled from ‘styled-components’; // Create a <Title> react component that renders an <h2> which is // centered, palevioletred and sized at 1.5em const Title = styled.h2` font-size: 1.5em; text-align: center; color: palevioletred; `; // Create a <Wrapper> react component that renders a <section> with // some padding and a papayawhip background const Wrapper = styled.section` padding: 4em; background: papayawhip; `; // Use them like any other React component – except they’re styled! <Wrapper> <Title>Hello World, this is my first styled component!</Title> </Wrapper>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | import React from ‘react’; import styled from ‘styled-components’; // Create a <Title> react component that renders an <h2> which is // centered, palevioletred and sized at 1.5em const Title = styled.h2` font-size: 1.5em; text-align: center; color: palevioletred; `; // Create a <Wrapper> react component that renders a <section> with // some padding and a papayawhip background const Wrapper = styled.section` padding: 4em; background: papayawhip; `; // Use them like any other React component – except they’re styled! <Wrapper> <Title>Hello World, this is my first styled component!</Title> </Wrapper> |
Результат:
styled-components сейчас в тренде. С их помощью стилизуют компоненты в React.
Проясним кое-что: styled-components – это просто абстракция высокого уровня поверх CSS. Она лишь парсит ваш CSS, написанный в JS, и создает JSX элементы, связанные с CSS.
Мне не нравится этот ажиотаж, вокруг него много недоразумений.
Я спросил на IRC, Reddit и Discord, почему люди используют styled-components. Я собрал список общих ответов, почему люди предпочитают styled-components. Я называю их мифами.
Миф №1: они решают проблему глобального пространства имен и конфликты стилизации
Я называю эту причину мифом, потому что она звучит так, будто бы эта проблема не была решена ранее. CSS Modules, Shadow DOM и бесконечное множество систем именования (BEM) решили эту проблему намного раньше.
styled-components (как CSS модули) снимает с людей ответственность за именование. Люди делают ошибки, компьютеры делают их меньше.
Это не самая хорошая причина использовать styled-components.
Миф №2: styled-components сокращает код
Часто предлагают такой пример:
<TicketName></TicketName> <div className={styles.ticketName}></div>
<TicketName></TicketName> <div className={styles.ticketName}></div> |
Во-первых, это совсем не важно. Различия незначительны.
Во-вторых, это не правда. Количество символов зависит от имени стиля.
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div> |
То же самое применимо к созданию стилей. Это вы увидите ниже в статье (миф №5: так легче стилизовать компоненты по условию). styled-components выигрывает в краткости только при использовании самых базовых компонентов.
Миф №3: styled components заставляет вас больше задумываться о семантике
Неправильный сам посыл. Стили и семантика представляют разные проблемы и требуют разных решений. Процитируем Adam Morse (mrmrs):
«Семантика контента ВООБЩЕ НЕ СВЯЗАНА С ВИЗУАЛЬНЫМИ СТИЛЯМИ. Когда в детстве я играл в лего, я никогда не думал «этот блок для двигателя». Я думал «о, круто, это блок 1×4, я могу сделать с ним, что угодно». Неважно что я собирал, будь-то подводная база для подводников или самолет, я точно знал, как пользоваться лего.»
Все же давайте предположим, что связь есть.
Пример:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList> |
Семантика – использование правильных тегов для написания разметки. Вы знаете, какие HTML теги будут рендерить эти компоненты? Не, не знаете.
Сравните с:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol> |
Миф №4: так легче расширять стили
В v1 вы можете расширять стили через конструкцию styled(StyledComponent), в v2 представили метод extend для расширения существующих стилей.
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `; |
Отлично. Но это моно делать и в CSS (с помощью CSS module composition или унаследованного Sass миксина @extend).
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнееbutton { padding: 10px; } button.tomato-button { color: #f00; }
button { padding: 10px; } button.tomato-button { color: #f00; } |
Что легче сделать в JS?
Миф №5: так легче стилизовать компоненты по условию
Суть в том, что вы можете стилизовать компоненты по их свойствам.
<Button primary /> <Button secondary /> <Button primary active={true} />
<Button primary /> <Button secondary /> <Button primary active={true} /> |
В мире React это много значит. По сути ведь, поведение компонентов контролируется через свойства. Можно ли прикреплять значения свойств напрямую в стили, есть ли в этом смысл? Возможно. Но давайте посмотрим на компонент:
styled.Button` background: ${props => props.primary ? ‘#f00’ : props.secondary ? ‘#0f0’ : ‘#00f’}; color: ${props => props.primary ? ‘#fff’ : props.secondary ? ‘#fff’ : ‘#000’}; opacity: ${props => props.active ? 1 : 0}; `;
styled.Button` background: ${props => props.primary ? ‘#f00’ : props.secondary ? ‘#0f0’ : ‘#00f’}; color: ${props => props.primary ? ‘#fff’ : props.secondary ? ‘#fff’ : ‘#000’}; opacity: ${props => props.active ? 1 : 0}; `; |
Создание стилей по условию через JS дает вам большую силу. Но такие стили также сложнее интерпретировать. Сравните с:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; } |
CSS короче (229 символов против 222) и проще читается (кому как). Более того, в CSS можно еще сильнее укоротить и сгруппировать код через препроцессор.
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | button { background: #00f; opacity: 0; color: #000;
&.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } } |
Миф №6: стилизованные компоненты лучше организуют код
Пара людей мне заявили, что им нравятся styled-components, потому что они позволяют писать стили и JS в одном файле.
Я понимаю, что несколько файлов для одного компонента утомляет, однако писать стили и разметку в одном файле – ужасная идея. Это не только усложняет контроль версий, но вам придется долго крутить код на любом компоненте сложнее кнопки.
Если вам обязательно необходимо писать CSS и JS в одном файле, используйте css-literal-loader. Этот инструмент позволяет вытаскивать CSS в момент билда с помощью extract-text-webpack-plugin и использовать стандартные настройки загрузки для обработки CSS.
Миф №7: это улучшает DX. Инструменты потрясающие!
Вы, скорее всего, не использовали styled-components.
Когда со стилями что-то идет не так, ломается все приложение с большим логом ошибки. Сравните с CSS, где ошибка стиля просто неправильно отображает элемент.
У элементов нет распознаваемых className, поэтому в дебаге вам остается лишь переключаться между деревом элементов React и деревом DevTools DOM (в v2 это можно решить с помощью babel-plugin-styled-components).
Нет линтинга (сейчас разрабатывается stylelint plugin).
Невалидные стили просто игнорируются (clear: both; float left; color: #f00; не вернут ошибок и предупреждений; у меня ушло 15 минут в дебаге на прохождение трассировки стека, даже после прочтения исходного кода styled-components). Только после того, как я скопировал код в чат и попросил помочь, кто-то указал мне, что отсутствует :. Вы же заметили, так ведь?)
Подсветка синтаксиса, автозавершение кода и другие тонкости поддерживаются в нескольких IDE. Если вы работаете с правительственными и финансовыми агентствами, есть вероятность, что Atom IDE вам не подойдет.
Миф №8: чем меньше размер, тем больше производительность
Как бы то ни было, styled-components нельзя извлечь в статичный CSS файл (например, https://github.com/webpack-contrib/extract-text-webpack-plugin).То есть браузер не начнет интерпретацию стилей, пока styled-components не распарсит их и не добавит в DOM.
Отсутствие файлов говорит о том, что нельзя кэшировать отдельный CSS и JS
Все стилизованные компоненты оборачиваются в дополнительный HoC. Удар по производительности незначительный. По этой же причине я перестал разрабатывать https://github.com/gajus/react-css-modules (и создал https://github.com/gajus/babel-plugin-react-css-modules).
Из-за HoC рендер на сервере приводит к увеличению разметки в документе
Не заставляйте меня запускать компоненты анимации с помощью динамических значений стилей или кейфреймов
Миф №9: позволяет разрабатывать адаптивные компоненты
Говорится о возможности стилизовать компонент по его окружению, т.е. размерам родительского контейнера, количеству дочерних элементов и т.д.
Во-первых, styled-components вообще с этим не связаны. Это за пределами проекта. Лучше устанавливайте значения style прямо на компонент.
Элементные запросы – интересная проблема, набирающая обороты в обсуждении CSS, в основном в проекте EQCSS и его копиях. Элементные запросы похожи на @media запросы по синтаксису, за исключением того, что элементные запросы работают с определенными элементами.
@element {selector} and {condition} [ and {condition} ]* { {css} }
@element {selector} and {condition} [ and {condition} ]* { {css} } |
{selector} – CSS селектор, направленный на один или более элементов. Пример — #id или .class
{condition} – состоит из измерения и значения
{css} – может содержать любые валидные CSS правила. Пример #id div { color: red }
Элементные запросы позволяют стилизовать элементы по условиям min-width, max-width, min-height, max-height, min-characters, max-characters, min-children, max-children, min-lines, max-lines, min-scroll-x, max-scoll-x и т.д. (см. http://elementqueries.com/).
Когда-нибудь вариация EQCSS появится в существующей CSS спецификации (скрестим пальцы).
Но постойте!
Почти все (если не все) описанное можно решить. Сообществом, изменениями в React или в styled-components. Но в чем смысл? CSS уже везде поддерживается, у него огромное сообщество, и он просто работает.
Суть статьи в том, чтобы отпугнуть читателей от использования CSS и JS или от использования styled-components. У стилизации через styled-components есть отличный пример использования: улучшенная кроссплатформенная поддержка. Не используйте его по неправильным причинам.
Так что же сегодня использовать?
Использовать Shadow DOM v1 (51% поддержки) слишком рано. Используйте CSS с системами именования (рекомендую BEM). Если беспокоитесь о коллизиях с именами классов (или слишком ленивы, чтобы использовать BEM), используйте CSS modules. Если разрабатываете для React, попробуйте babel-plugin-react-css-modules. Если разрабатываете для нативного React, возьмите styled-components.
Автор: Gajus Kuizinas
Источник: https://medium.com/
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
СмотретьCSS-in-JS — мифы и реальность (на примере styled-components) / Habr
CSS-in-JS, будучи не совсем новой технологией и реализованной во множестве библиотек, до сих пор вызывает сомнения и споры в целесообразности ее использования. Свои точки над «i» в спорах о CSS-in-JS в общем, и о styled-components в частности, расставил еще год назад, ( 27 Apr 2017 ), и Gajus Kuizinas, автор react-css-modules и babel-plugin-react-css-modules, во все еще, на мой взгляд, актуальной публикации «Прекратите использовать CSS-in-JavaScript в веб-разработках».
Ниже предлагается слегка сокращенный ее перевод с некоторыми добавлениями и выводами:
CSS никуда не уходит. Во множестве проектов выбор в пользу стилизации в JavaScript делается ошибочно. Мы приведем перечень распространенных заблуждений(мифов) и соответствующих им решений посредством CSS.
История Css и JavaScript
CSS был создан для описания представления документа, написанного на языке разметки. JavaScript был создан, как «язык-клей» для сборки компонентов, таких, как изображения и плагины. Спустя годы, JS рос и изменялся, приспосабливаясь ко все новым сферам применения. И, как результат, мы сегодня живем в эру одностраничных приложений (SPA), приложений собранных из компонентов.
А что же с CSS?
Приведем цитату из документации styled-components:
Проблема обычного CSS состоит в том, что он был создан в эру, когда веб состояла из документов. Web была создана для обмена по преимуществу научными документами в 1993 году и CSS был введен, как решение для стилизации этих документов. Однако, сегодня мы разрабатываем развитые, интерактивные, ориентированные на пользователя приложения, а CSS просто не предназначен для этого.
Это не так.
CSS уже учитывает все требования современных пользовательских интерфейсов. Количество новых функций, реализованных в последнее десятилетие таково, что их все невозможно здесь даже перечислить (pseudo-classes, pseudo-elements, CSS variables, media queries, keyframes, combinators, columns, flex, grid, computed values, …).
С точки зрения пользовательского интерфейса, «component» — это изолированный фрагмент документа (<button />- это «component»). CSS создан для стилизации документов, а документ охватывает все компоненты. В чем же проблема?
Как говорится: «Используйте правильный инструмент для работы».
Styled-components
styled-components дает возможность написания CSS в JavaScript используя т.н. тегированные шаблонные строки. Библиотека удаляет сопоставление между компонентами и стилями — компонент превращается в конструкцию с низкоуровневой стилизацией, например:
// Create a <Title> react component that renders an <h2> which is
// centered, palevioletred and sized at 1.5em
const Title = styled.h2`
font-size: 1.5em;
text-align: center;
color: palevioletred;
`;styled-components сегодня пользуется популярностью и известна, как новый способ стилизации компонентов в React, хотя иногда ее представляют даже, как «вершину развития CSS»:
CSS Evolution: From CSS, SASS, BEM, CSS Modules to Styled Components.
Но давайте уясним следующее: styled-components — это всего лишь надстройка над CSS. Эта библиотека разбирает стили CSS, определенные вами в JavaScript и создает соответствующие JSX элементы.
Популярность styled-components сопряжена со множеством заблуждений. Обзор ответов программистов (найденных на IRC, Reddit и Discord) на вопрос о причинах, побудивших их применить эту библиотеку, позволил составить список наиболее упоминаемых. Назовем их мифами.
Миф #1: styled-components решает проблемы глобального пространства имен и конфликтов стилей
Это миф, потому что звучит так, якобы упомянутая проблема еще никак не решалась. Однако CSS Modules, Shadow DOM и бесчисленные соглашения по именованиям ( такие как BEM) предложили решения проблемы давным давно.
styled-components (точно так же, как и CSS modules) снимает с человека проблему ответственности за наименования. Человеку свойственно ошибаться, компьютеры ошибаются не столь часто.
Сам по себе, это еще недостаточно веский довод для использования styled-components.
Миф 2: Использование styled-components дает возможность получать более компактный код
В подтверждение часто приводят пример:
<TicketName></TicketName>
<div className={styles.ticketName}></div>Прежде всего — это не имеет значения. Разница незначительна.
Во-вторых, это неправда. Общее количество символов зависит от имени стиля.
<TinyBitLongerStyleName></TinyBitLongerStyleName>
<div className={styles.longerStyleName}></div>То же самое применимо и к созданию стилей, что мы увидим позже в этой статье
(Миф5: styled-components облегчает условную стилизацию компонентов). styled-components выигрывает в краткости только в случаях самых базовых компонентов.
Миф 3. Использование styled components вынуждает больше думать о семантике
Сам первоначальный посыл ошибочен. Стилизация и семантика представляют собой разные проблемы и требуют различных решений. Прочтите, например, это Adam Morse (mrmrs).
Тем не менее, рассмотрим:
<PersonList>
<PersonListItem>
<PersonFirstName>Foo</PersonFirstName>
<PersonLastName>Bar</PersonLastName>
</PersonListItem>
</PersonList>Семантика занимается применением правильных тегов для разметки. А вы знаете, какие HTML теги будут использованы для рендеринга такого компонента? Нет, не знаете.
Cравните:
<ol>
<li>
<span className={styles.firstName}>Foo</span>
<span className={styles.lastName}>Bar</span>
</li>
</ol>Миф 4: Проще расширять стили
Сравните:
const Button = styled.button`
padding: 10px;
`;
const TomatoButton = Button.extend`
color: #f00;
`;Замечательно! Но то же самое вы можете сделать и в CSS (или использовать CSS module composition, а также SASS inheritance mixin @extend).
button {
padding: 10px;
}
button.tomato-button {
color: #f00;
}И чем проще первый вариант?
Миф 5: Облегчается условная стилизация компонентов
Идея состоит в том, что вы можете стилизовать элементы используя props, например:
<Button primary />
<Button secondary />
<Button primary active={true} />Это имеет смысл в React. В конце концов, поведение компонента контролируется через props. Есть ли смысл в прямой привязке prop значений к стилям? Может быть. Но давайте рассмотрим имплементацию такого компонента:
styled.Button`
background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'};
color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'};
opacity: ${props => props.active ? 1 : 0};
`;Создание условных стилей при помощи JavaScript дает массу возможностей. Однако, это также означает, что стили будет намного сложнее интерпретировать. Сравните с CSS:
button {
background: #00f;
opacity: 0;
color: #000;
}
button.primary,
button.seconary {
color: #fff;
}
button.primary {
background: #f00;
}
button.secondary {
background: #0f0;
}
button.active {
opacity: 1;
}В этом случае, CSS короче (229 символов против 222) и проще для понимания (субъективно). Более того, в CSS вы могли бы использовать препроцессор, чтобы получить еще более короткий и сгрупированный результат:
button {
background: #00f;
opacity: 0;
color: #000;
&.primary,
&.seconary {
color: #fff;
}
&.primary {
background: #f00;
}
&.secondary {
background: #0f0;
}
&.active {
opacity: 1;
}
}Миф 6: Улучшается организация кода
Некоторые говорят о том, что им нравится styled-components, потому что появляется возможность размещать стили и скрипты в одном файле. Можно понять, что наличие множества файлов для одного компонента может показаться утомительным, но впихивание стилей и разметки в единый файл — это ужасно. Это не только системе контроля версий усложнит отслеживание изменений, но и приведет к бесконечному «скроллингу» на любом элементе посложнее простой кнопки.
Если же вам непременно нужно разместить CSS и JavaScript в одном и том же файле, попробуйте css-literal-loader. Последнее позволит вам собирать стили во время «build» посредством extract-text-webpack-plugin и использовать стандартную конфигурацию лоадера для обработки CSS.
Миф 7: «Developer Experience (DX) » становится прекрасным. Инструмент потрясающий!
Очевидно, что вы не использовали styled-components.
- Если что-то пошло не так со стилями, все приложение «падает» с длинной стековой трассировкой ошибки. Противоположность этому — CSS, где ошибка в стилях приведет просто к неправильному отображению элемента.
- У элементов отсутствуют различаемые className, поэтому при отладке придется бесконечно переключаться между React element tree и DevTools DOM tree.
- И хотя плагины для линтинга, подсветки кода, автозавершения кода, и другие подобные «прелести» уже существуют и для styled-components, они все еще могут быть недоступны для вашего IDE. Если вы работаете с финансами в правительственном агенстве, есть шансы, что Atom IDE будет недоступна.
Миф 8: Все становится «шустрее», все становится «легче»
- Как выяснилось, styled-components стили не могут быть экстрагированы в статический
CSS файл (например используя extract-text-webpack-plugin). Это значит, что браузер не сможет начать интерпретацию стилей до тех пор, пока styled-components не «распарсит» их и не добавит в DOM. - Совмещение стилей и скриптов в одном файле означает, что раздельное их кеширование невозможно.
- Природа styled-components такова, что все они обернуты в дополнительный HOС. А это ненужное понижение производительности. Такой же недостаток привел к прекращению поддержки react-css-modules и появлению babel-plugin-react-css-modules.
- Из-за того же HOC, серверный рендеринг приводит к значительно большему размеру разметки документа.
- Даже и не пробуйте анимировать компоненты используя динамические стили, а не keyframes.
Миф 9: Появляется возможность разработки «responsive» компонентов
Речь идет о способности стилизовать компонент на основе окружающей среды, например, размеров родительского контейнера, количества наследников и т. д.
Прежде всего, styled-components не имеют ничего общего с этим.
Это выходит за рамки проекта. В данном случае лучше прямо установить значения стиля компонента, чтобы избежать дополнительных нагрузок на процессор.
Минуточку, однако!
Большинство, если не все из этих проблем, могут быть решены в перспективе то ли сообществом, изменениями в React или в самой styled-components. Только зачем? CSS уже широко поддерживается, имеется солидное сообщество и… просто работает.
Но не нужно всегда избегать применения CSS-in-JavaScript или styled-components.
Есть кое-что, что делает styled-components хорошей библиотекой — это лучшая кросс-платформенная поддержка.
Просто не используйте styled-components исходя из ошибочных представлений.
Пара мнений от заинтересованных лиц
Talia Marcassa: Что мы нашли разочаровывающим в styled-components?
Применяя styled-components в нашем проекте мы обнаружили, что имеются некоторые стилевые правила, которые трудно внедрять в styled-components; например, правила, которые управляют размещением элементов на странице ( margins или display свойство). Это трудно поддавалось стандартизации, так что мы по-прежнему были вынуждены в значительной степени опереться на простой CSS для размещения компонентов в потоке элементов.
… хотя и были сложности в применении styled-components, библиотека помогла нам уменьшить кодовую базу.
Prometheus: В итоге что?
(комментарий к «Эволюция CSS: от CSS, SASS, BEM и CSS–модулей до styled-components»)
… Никакая эволюция CSS тут не значится, эволюционируют инструменты.
На мой взгляд, проблемы никакой нету, когда версткой занимается верстальщик, а программист — программированием.
А вот когда программисты занимаются версткой — вот тогда начинается весь этот зоопарк, который вместо ПРОСТОТЫ с дальнейшей поддержкой, дает лишнюю головную боль.
…
Пишите на чистом CSS, а инструментам отведите роль пространства имен и сборщика — тогда будет всем счастье…
И в заключение, слово автору:
Gajus Kuizinas: — Так что, все-таки, использовать?
- Еще слишком рано говорить о Shadow DOM, ввиду недостаточно глобальной поддержки.
- Используйте CSS с каким-либо соглашением об именовании (например BEM).
- Если вас волнует проблема коллизий имен классов или вы слишком ленивы, чтобы использовать BEM, используйте CSS Modules.
- Если вы работаете с React — рассмотрите возможность использования babel-plugin-react-css-modules.
- Если же вы работаете с React native, styled-components — это то, что надо.
JS JavaScript Уроки и примеры
JavaScript — это язык программирования HTML и Web.
JavaScript прост в изучении.
Этот учебник научит вас JavaScript от Basic до Advanced.
Примеры в каждой главе
С помощью редактора «Попробуйте сами» вы можете изменить все примеры и просмотреть результаты.
Пример
Мой первый JavaScript
Щелкните на меня, чтобы отобразить дату и времяМы рекомендуем прочитать этот учебник в последовательности, указанной в левом меню.
Узнать по примерам
Примеры лучше, чем 1000 слов. Примеры часто легче понять, чем текстовые пояснения.
Этот учебник дополняет все объяснения с уточнением «Попробуйте сами» примеры.
Если вы попробуете все примеры, вы узнаете много о JavaScript, в очень короткое время!
Зачем изучать JavaScript?
JavaScript является одним из 3 языков все веб-разработчики должны узнать:
1. HTML Определение содержимого веб-страниц
2. CSS Указание макета веб-страниц
3. JavaScript Программирование поведения веб-страниц
Веб-страницы не являются единственным местом, где используется JavaScript. Многие настольные и серверные программы используют JavaScript. Node. js является наиболее известным. Некоторые базы данных, такие как MongoDB и CouchDB, также используют JavaScript в качестве языка программирования.
Ты знала?
JavaScript и Java-это совершенно разные языки, как в концепции, так и в дизайне.
JavaScript был изобретен Брендан Айх в 1995, и стал стандартом ECMA в 1997.
ECMA-262 является официальным названием стандарта. ECMAScript является официальным названием языка.
Вы можете прочитать больше о различных версиях JavaScript в версии главы JS.
Скорость обучения
В этом учебнике, скорость обучения является вашим выбором.
Все до вас.
Если вы боретесь, сделать перерыв, или перечитать материал.
Всегда убедитесь, что вы понимаете все «попробовать сами» примеры.
преимущества использования и возможные проблемы, статический рендеринг
От автора: CSS-in-JS может предоставить огромные преимущества для удобства обслуживания. Но для больших статически визуализируемых веб-сайтов использование простого CSS все еще имеет смысл.
Все больше и больше разработчиков переходят на CSS-in-JS, включая такие громкие имена, как Microsoft, Atlassian и … конкурс песни Евровидение! И хотя я не всегда был большим поклонником CSS-in-JS, даже я признаю его преимущества:
Это позволяет вам легко обмениваться переменными между JavaScript и CSS (просто не забывайте разделять их).
Это благо для инструментов, облегчающих удаление мертвого кода и доставку минимально возможного количества CSS.
И самое главное, это поощряет написание CSS в композитном стиле.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Узнать подробнееПохоже, что CSS-in-JS будет доминировать в дизайне веб-приложений в обозримом будущем. Но веб-приложения составляют лишь небольшую часть Интернета, потому что контент по-прежнему остается королем.
Если вы разработчик React, высока вероятность того, что вы будете работать со статически визуализируемым веб-сайтом. И, как я обнаружил при создании create-react-blog и Frontend Armory, использование CSS-in-JS для статически визуализируемых сайтов по-прежнему сопровождается несколькими оговорками …
В чем разница между статическим и серверным рендерингом?
Избегайте мелькания неустановленного контента
Идея статического рендеринга заключается в том, чтобы ускорить сайт путем предварительной рендеринга HTML-кода для каждой страницы, который затем может быть отображен пользователям до завершения загрузки JavaScript. Конечно, с помощью CSS-in-JS ваши стили, в основном содержатся в JavaScript. И это создает проблему — исходный HTML-код не будет работать до завершения загрузки JavaScript.
К счастью, команды, поддерживающие styled-components и emotion, позволяют решить эту проблему с помощью небольшого дополнительного кода. Например, styled-components предоставляет объект ServerStyleSheet, который позволяет статически визуализировать стили одновременно со статической визуализацией HTML. Затем вы просто отправляете статически визуализированный тег style как часть HTML:
render.js
import React from ‘react@next’ import { renderToString } from ‘react-dom@next/server’ import styled, { ServerStyleSheet } from ‘styled-components’ // стилизованный компонент const Button = styled.a` border: 2px solid palevioletred; border-radius: 3px; color: palevioletred; display: inline-block; font-family: sans-serif; padding: 0.5rem 1rem; margin: 0.5rem 1rem; ` // Элемент React, который будет фактически визуализироваться const pageContent = ( <Button as={‘a’} href=’https://www.youtube.com/watch?v=FpBJih02aYU’ target=’_blank’> Not my Gumdrop Buttons! </Button> ) // `ServerStyleSheet` может собирать стили из статически // визуализируемого HTML, а затем выводит их в виде строки тега <style>. const sheet = new ServerStyleSheet() const html = renderToString(sheet.collectStyles(pageContent)) const styleTags = sheet.getStyleTags() console.log(‘Static stylesheet:\n’, styleTags) document.getElementById(‘root’).innerHTML = styleTags+html
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | import React from ‘react@next’ import { renderToString } from ‘react-dom@next/server’ import styled, { ServerStyleSheet } from ‘styled-components’
// стилизованный компонент const Button = styled.a` border: 2px solid palevioletred; border-radius: 3px; color: palevioletred; display: inline-block; font-family: sans-serif; padding: 0.5rem 1rem; margin: 0.5rem 1rem; `
// Элемент React, который будет фактически визуализироваться const pageContent = ( <Button as={‘a’} href=’https://www.youtube.com/watch?v=FpBJih02aYU’ target=’_blank’> Not my Gumdrop Buttons! </Button> )
// `ServerStyleSheet` может собирать стили из статически // визуализируемого HTML, а затем выводит их в виде строки тега <style>. const sheet = new ServerStyleSheet() const html = renderToString(sheet.collectStyles(pageContent)) const styleTags = sheet.getStyleTags()
console.log(‘Static stylesheet:\n’, styleTags)
document.getElementById(‘root’).innerHTML = styleTags+html |
index.js
// DON’T DO THIS. It’s a hack to tell styled-components // that server rendering is allowed, even in the browser. import ‘react@next’ const {StyleSheet} = require(‘styled-components’).__DO_NOT_USE_OR_YOU_WILL_BE_HAUNTED_BY_SPOOKY_GHOSTS StyleSheet.reset(true) require(‘./render’)
// DON’T DO THIS. It’s a hack to tell styled-components // that server rendering is allowed, even in the browser. import ‘react@next’ const {StyleSheet} = require(‘styled-components’).__DO_NOT_USE_OR_YOU_WILL_BE_HAUNTED_BY_SPOOKY_GHOSTS StyleSheet.reset(true) require(‘./render’) |
Предварительно выполнив рендеринг тега style и отправив его вместе с HTML, вы избежите появления нестандартного содержимого, но есть одна загвоздка. Поскольку ServerStyleSheet создает только стили для свойства initial, любое использование состояния компонента, componentDidMount или componentDidUpdate не будет отражено в стилях, представленных на сервере. Учитывая, что ваш предварительно визуализированный HTML имеет те же ограничения, это не должно быть проблемой. Но если вам нужна небольшая помощь в получении исходных данных для каждого из URL-адресов приложения, взгляните на Navi - маршрутизатор, созданный с учетом статического / серверного рендеринга. Но я отвлекся.
Статическое отображение стилей имеет еще одно преимущество: оно уменьшает количество CSS, которое требуется при начальной загрузке каждой страницы. Это связано с тем, что отображаемые теги style содержат только критический CSS, необходимый для предварительно обработанного HTML. Остальная часть CSS по-прежнему управляется с помощью JavaScript, что позволяет разделить его с помощью динамического import(). Это может быть очень важно для производительности … или может привести к тому, что многие мегабайты CSS будут недействительными при каждом обновлении — даже для обновлений, которые не затрагивают содержимое.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Узнать подробнееВстроенные и внешние таблицы стилей
Если вы посмотрите на сгенерированный тег style в приведенном выше примере, вы заметите, что он содержит атрибут data-styled. Это важно, потому что показывает, что styled-components привязаны к этому тегу style. Вы не можете надежно извлечь содержимое этого тега style в файл CSS, на который ссылается link. Что … может быть не такой уж большой проблемой?
Я имею в виду, почему вы все равно хотите поместить свои стили в отдельный файл?
Чтобы ответить на этот вопрос, рассмотрим основную причину статического рендеринга: он позволяет обслуживать JavaScript через CDN. Теперь, что касается ресурсов, обслуживаемых через CDN, они часто кэшируются со сроками истечения в далеком будущем. Таким образом, изменения в этих ресурсах требуют новых имен файлов, чтобы обойти кэш.
Естественно, изменения в именах файлов JavaScript потребуют соответствующих изменений в HTML, который ссылается на них. В результате HTML-файлы приложения не могут кэшироваться так же полно, как и теги style, встроенные в них. А благодаря дизайну Webpack изменения любого файла JavaScript в вашем проекте обычно требуют изменения каждого тега script и, следовательно, файла HTML в вашем приложении.
<!— К примеру, этот тег скрипта: —> <script src=»/static/js/runtime~main-47df755c101a4.js»></script> <!— Может быть исправлен в это: —> <script src=»/static/js/runtime~main-55ce84a0cc19b.js»></script>
<!— К примеру, этот тег скрипта: —> <script src=»/static/js/runtime~main-47df755c101a4.js»></script>
<!— Может быть исправлен в это: —> <script src=»/static/js/runtime~main-55ce84a0cc19b.js»></script> |
Для приложений с небольшим количеством страниц, небольшим трафиком или небольшими тегами style это не проблема. Но для сайтов, ориентированных на контент, цифры могут значительно увеличиться. Например, предположим, что вы работаете с сайтом с 1000 страницами и 25 КБ критического CSS на каждой. Во всех HTML-файлах теперь у вас будет 25 МБ CSS в тегах style; и весь этот CSS должен передаваться в CDN при каждом изменении сайта — даже если ваше единственное изменение — исправление опечатки!
25 КБ критического CSS?! Критический CSS содержит только глобальные стили и стили для компонентов при начальном рендеринге одной страницы. Но некоторые компоненты могут содержать много стилей! Например, компонент <MarkdownDocument>, который содержит все возможные стили для любого возможного документа.
Вы все еще можете использовать CSS-in-JS
Является ли проблемой необходимость передавать в CDN весь встроенный CSS при каждом изменении? Это проблема, если пользователи не могут кэшировать критический CSS? Ответ — конечно, это зависит от. В частности, есть три условия, которые могут вызвать проблемы:
Если у вас много страниц с большим количеством критического CSS
Если ваш контент часто обновляется
Если у вас на сайте значительный трафик
В частности, если ваш сайт удовлетворяет всем этим трем условиям, есть большая вероятность, что вы сможете повысить производительность (и сэкономить на стоимости хостинга), переместив часть CSS в отдельные файлы CSS. Имейте в виду, что вы можете продолжать использовать CSS-in-JS наряду с обычным CSS или CSS Modules — вам просто нужно сохранить размер критического CSS-кода управляемым.
Конечно, styled-components — не единственный вариант. Другой популярный инструмент, emotion, во много схож с ними. Но есть также linaria - инструмент CSS-in-JS, который больше ориентирован на статический рендеринг. Если вы хотите использовать CSS-in-JS, но styled-components не удовлетворяют вашим требованиям, тогда вам определенно стоит попробовать linaria!
Но, возможно, вы предрасположены к стилизованным компонентам — в конце концов, у них есть звездная команда и огромное сообщество. И что важно, открытый исходный код! Команда Styled-Components в настоящее время работает над тем, чтобы сделать возможным извлечение кэшируемого CSS-кода, поэтому, если вы хотите внести свой вклад, посмотрите этот запрос.
Наконец, нужно сказать, что, хотя CSS-in-JS — отличный вариант, в нем нет абсолютной необходимости. Модули CSS и SASS решают большинство из тех же проблем, работая из коробки с create-react-app and create-react-blog. И CSS-in-JS, и простой CSS занимают свои ниши, и знание всех вариантов поможет вам выбрать правильный инструмент для работы.
Автор: James K Nelson
Источник: https://frontarm.com/
Редакция: Команда webformyself.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Узнать подробнее
PSD to HTML
Практика верстки сайта на CSS Grid с нуля
СмотретьОбъединение JavaScript и CSS в одном файле / Habr
Если Вы работали над оптимизацией загрузки страницы, Вы знаете, насколько дорогостоящая каждая загрузка ресурса. Чем больше число внешних ресурсов, к которым Вы обращаетесь, тем больше время требуется для загрузки страницы.Как правило, веб-страницы обращаются ко многим внешним CSS и файлам JS и следовательно подвергаются многим загрузкам ресурса. Совет от гуру оптимизации в необходимости объединить все файлы CSS и все до одного файлы JS, чтобы уменьшить число ресурсов до двух. Это, без сомнения, поможет сократить время загрузки страницы.
Если Вы все же считаете что эти две загрузки не являются лучшим решениям, я с Вами соглашусь. В этой статье мы рассмотрим способ объединения CSS с JS и сведем количество загрузок к одной. Я обнаружил этот способ, отчаянно пытаясь оптимизировать страницы в Microsoft Office Live
Техника основана на том как CSS и анализатор JS ведут себя в IE и Firefox.
• Когда анализатор CSS сталкивается с символом комментария HTML (
• Когда анализатор JS сталкивается с символом комментария HTML (
Рассмотрим на примере
<!— /*
function t(){}
<!— */
<!— body { background-color: Aqua; }
Когда анализатор CSS будет разбирать вышеупомянутое код, символы комментария HTML будут пропущенны, и код станет эквивалентным коду ниже…
/*
function t(){}
*/
body { background-color: Aqua; }
Как Вы видите, анализатор CSS видит только код CSS, а код скрипта закомментирован (/*… */).
Когда анализатор JS станет разбирать код, символы комментария HTML будут интерпретированы в комментарии строки (//), и следовательно код станет таким…
// /*
function t(){}
// */
// body { background-color: Aqua; }
Как Вы видите анализатор JS видет только код скрипта, а все остальное закоментрованно.
Что бы ссылаться на этот ресурс можно использовать теги SCRIPT и LINK в вашей страницы. Например:
<link type=«text/css» rel=«stylesheet» href=«test.jscss» />
<script type=«text/javascript» language=«javascript» src=«test.jscss»></script>
Заметьте эти два тега ссылаются на один тот же ресурс и следовательно он загрузиться всего один раз, и будет интерпретирован и как стили и как скрипты.
И на последок, есть еще одна вещь, о которой Вы должны заботиться — content type ответа — необходимо ставить */* чтобы дать подтверждение Firefox, что содержание может быть обработано как что-либо подходящее.