Как глобально стилизовать динамические c данные (опасно SetInner HTML) с помощью стилевых компонентов? - PullRequest
Новая
       17

Как глобально стилизовать динамические c данные (опасно SetInner HTML) с помощью стилевых компонентов?

1 голос
/ 04 февраля 2020

Учитывая, что у нас есть этот компонент: 

const Policy = ({ policy }) => (
    <div dangerouslySetInnerHTML={ { __html: policy } }></div>
)
export default Policy

и некоторые другие, подобные этим (для каждого сценария, h1, h2 и т. Д. c.): 

import styled from 'styled-components';

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

Как правильно централизовать ведение стилей заголовков?

Варианты:

  • Разделить и импортировать одинаковые CSS для обоих / et c, один глобальный и один ограниченный;
  • Конвертировать данные нашего бэкэнда HTML в наш React / HTML каким-либо образом (html -реагировать );
  • Внедрение стилей CSS только в этот компонент политики
  • Другая идея

Я думаю, что этот стиль доступен для любого h1, h2 и др. c. но я не знаю, ошибаюсь ли я и должен ли я по какой-то причине избавиться от этого старого паттерна.

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

Обновление : может быть, createGlobalStyle будет хорошим вариантом для этого?

Ответы [ 2 ]

1 голос
/ 05 февраля 2020

Как вы упомянули, у вас есть несколько опций, которые в основном личные предпочтения.

  1. Глобальный стиль в head с использованием функции createGlobalStyle , Преимущество этого подхода в том, что он не блокирует рендеринг и может быть легко ограничен с помощью className. Недостатком является то, что он всегда в head.

  2. Использование модульного css и локальный охват компонента. Преимущества заключаются в том, что если вы используете Webpack, то вы можете лениво импортировать модуль компонента и, следовательно, требовать таблицу стилей только при необходимости, и это дает вам возможность нацеливаться на :global s, если это необходимо. Недостатком является то, что он блокирует рендеринг (кроме того, он остается в head после загрузки, однако, поскольку он локально ограничен, он не должен мешать другим стилям) и не может выбирать stati c имена дочерних классов. .

  3. Условно добавьте таблицу стилей в head, используя react-helmet. Преимущество этого подхода заключается в том, что он используется только в head, когда это необходимо. Недостатком является то, что он может вызывать мигание пользовательского интерфейса (поскольку он был загружен в операторе render method / return), должен вызывать API для получения таблицы стилей для каждого (повторного) монтирования и не очень многократно используется потому что он добавляет таблицу стилей для каждого экземпляра компонента.

Итак, я бы рекомендовал перейти к варианту 1. При этом, если я работаю с большими таблицами стилей, тогда опция 2 - даже с учетом ограничений селектора. На этой ноте я обычно стараюсь не хранить строковый HTML, если это абсолютно не необходимо. При работе с базами данных извлечение больших строк может быть медленным и, в зависимости от устройства пользователя, даже медленнее для отображения. Кроме того, использование dangerouslySetInnerHTML открывает вам до XSS-атак . На самом деле, я нахожусь в процессе создания редактора markdown , который использует простой текст и преобразует его в HTML на лету. Возможно, стоит рассмотреть этот вариант - он также обрабатывает HTML, хотя, опять же, открывает уязвимости XSS.

Рабочая демонстрация всех 3 вариантов :

Демо

Edit Stylesheets

1 голос
/ 04 февраля 2020

Вот как я бы это сделал: 

const Policy = ({ className, policy }) => (
    <div className={className} dangerouslySetInnerHTML={{ __html: policy }}></div>
)

const StyledPolicy = styled(Policy)`
  h1 {
    font-size: 1.5em;
    text-align: center;
    color: palevioletred;
  }

  h2 {
    ...
  }
`;

export default StyledPolicy

Тогда вам не нужно глобально определять область действия CSS.

...