Лучшие практики React.js во встроенном стиле

Атрибут style в React ожидает, что это значение будет представлять собой объект, т.е. пару значений ключа.

style = {} будет иметь в нем другой объект, например {float: 'right'}, чтобы он работал.

<span style={{float:'right'}}>{'Download Audit'}</span>

Надеюсь, что это решает проблему

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

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

Эта презентация сотрудника Facebook и вкладчика React Contributor "vjeux" также очень полезна - https://speakerdeck.com/vjeux/react-css-in-js

Основная цель атрибута style - динамические, основанные на состоянии стили. Например, вы можете иметь стиль ширины на индикаторе выполнения на основе некоторого состояния или позиции или видимости на основе чего-то еще.

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

Джеймс К. Нельсон в своем письме "Почему вы не должны реагировать на компоненты с помощью JavaScript" утверждает, что на самом деле нет необходимости использовать встроенные стили со своими минусами. Его утверждение состоит в том, что старое скучное css с меньшим /scss - лучшее решение. Часть его тезисов в пользу css:

• расширяемый внешний вид
• с возможностью использования (встроенные стили перекрывают все)
• дизайнер дружественный

Вы можете использовать react-theme, чтобы организовать свои встроенные стили и сделать их легко настраиваемыми, когда вы создаете повторно используемый компонент.

Он работает аналогично ThemeManager в материале-ui.

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

var MyDiv = React.createClass({
  render: function() {
    return <custom-component style={style}> Have a good and productive day! </custom-component>;
  }
});

И в файле "custom-component.css" каждая запись начнется с тега пользовательского компонента:

custom-component { 
   display: block; /* have it work as a div */
   color: 'white'; 
   fontSize: 200; 
} 
custom-component h1 { 
  font-size: 1.4em; 
}

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

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

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

Это действительно зависит от того, как большое ваше приложение, если вы хотите использовать связки, такие как webpack, и объединить CSS и JS вместе в сборке и как вы хотите управлять потоком приложений! В конце дня, зависит от вашей ситуации, вы можете принять решение!

Мое предпочтение для организации файлов в больших проектах заключается в разделении файлов CSS и JS, это может быть проще для обмена, проще для пользователей пользовательского интерфейса просто просматривать файлы CSS, а также гораздо более аккуратный файл для организации всего приложения!

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

Проблема со встроенными стилями - это политики безопасности контента (CSP), которые становятся все более распространенными, что не позволяет. Поэтому я рекомендую полностью исключить встроенные стили.

Update: Чтобы объяснить далее, CSP представляют собой HTTP-заголовки, отправленные сервером, которые ограничивают, какой контент может отображаться на странице. Это просто дальнейшее смягчение, которое может быть применено к серверу, чтобы остановить злоумышленника от совершения чего-либо непослушного, если разработчик плохо кодирует сайт.

Цель большинства этих ограничений - остановить атаки XSS (межсайтовый скриптинг). XSS - это то, где злоумышленник определяет способ включить свой собственный javascript на вашу страницу (например, если я сделаю свое имя пользователя bob<SCRIPT>alert("hello")</SCRIPT>, а затем опубликую комментарий, и вы заходите на страницу, он не должен показывать предупреждение). Разработчики должны отрицать возможность добавления пользователем такого контента на сайт, но на случай, если они допустили ошибку, CSP блокирует загрузку страницы, если она найдет теги script>.

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

Итак, все это XSS, но что, если злоумышленник не может включать теги <script>, но может включать теги <style> или включать параметр style= в тег? Затем он сможет изменить внешний вид сайта таким образом, чтобы вы обманом нажали на неправильную кнопку или какую-то другую проблему. Это гораздо меньше беспокоит, но все равно что-то избежать, и CSP делает это для вас.

Хорошим ресурсом для тестирования сайта для CSP является https://securityheaders.io/

Вы можете узнать больше о CSP: http://www.html5rocks.com/en/tutorials/security/content-security-policy/