Символы в ‹style› преобразованы в Unicode HTML Entity в запросах из разных источников

У меня есть приложение NextJS, которое использует response-jss.

В моем CSS есть правило, которое нацелено на '& .working[style="display: block;"] ': {...}

Я могу собрать, запустить и увидеть, что это нормально работает, когда я попадаю на страницу в том же домене, на котором работает сервер, и у меня есть несколько отдельных тегов <style>, которые выглядят так:

<style data-jss="" data-meta="Themed">...</style>
<style data-jss="" data-meta="Themed">...</style>
...

Однако когда я получаю доступ к той же странице, обслуживаемой из другого домена (или с помощью Postman), я вижу, что в рассматриваемом правиле символ " был заменен на &quot;, так что он выглядит как .working[style=&quot;display: block;&quot;] (это не ограничивается " - > позже в этом правиле заменяется на &gt;). Все стили также обслуживаются одним тегом <style>:

<style id="server-side-styles">...</styles>

Приложение не делает ничего необычного, стили добавляются в _document.js, как показано здесь: https://github.com/vercel/next.js/blob/canary/examples/with-react-jss/pages/_document.js

Я не верю, что это проблема NextJS или response-jss, поскольку, когда я проверяю строковый реестр на сервере (при выполнении запроса через Postman), я все еще вижу стиль в том виде, в котором он был изначально написан, без преобразования символов.

Есть ли что-то, связанное с CORS или запросами из разных источников, из-за чего " будет заменено на &quot; таким образом? Если да, то как я могу это предотвратить? Если нет, я упустил что-то очевидное?


reactjs html next.js cross-domain css-in-js
person Ben    schedule 28.10.2020    source источник
comment
@sideshowbarker обдумывает ваше удаление тега cors. Я предполагаю, что это связано с тем, что эта проблема также встречается с Postman? Это не было тем, что я рассматривал, и поскольку я прямо спрашивал, может ли это быть связано с CORS, по крайней мере, комментарий к этому влиянию был бы полезен. Определенно что-то очевидное, что я упустил ...   -  person Ben    schedule 28.10.2020
comment
В общем, учитывая конкретную проблему, способ узнать, связана ли она с CORS, - это посмотреть в консоли devtools и посмотреть, зарегистрировал ли браузер там какие-либо сообщения, в которых явно упоминается CORS. Если браузер не зарегистрировал никаких сообщений в консоли, в которых явно упоминается CORS. Что касается конкретной проблемы, описанной в вопросе, то ни в протоколе CORS, ни в поведении браузера нет ничего, связанного с CORS, которое могло бы вызвать поведение, описанное в вопросе.   -  person sideshowbarker    schedule 28.10.2020

Ответы (1)


arrow_upward
2
arrow_downward

Используя пример, который вы связали, в этой строке:

<style id="server-side-styles">{registry.toString()}</style>

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

По ссылке в примере это будет _document.js выглядеть так:

import Document from 'next/document'
import { SheetsRegistry, JssProvider, createGenerateId } from 'react-jss'

export default class JssDocument extends Document {
  static async getInitialProps(ctx) {
    const registry = new SheetsRegistry()
    const generateId = createGenerateId()
    const originalRenderPage = ctx.renderPage
    ctx.renderPage = () =>
      originalRenderPage({
        enhanceApp: (App) => (props) => (
          <JssProvider registry={registry} generateId={generateId}>
            <App {...props} />
          </JssProvider>
        ),
      })

    const initialProps = await Document.getInitialProps(ctx)
    const rawStyles = {
      __html: registry.toString(),
    }

    return {
      ...initialProps,
      styles: (
        <>
          {initialProps.styles}
          <style id="server-side-styles" dangerouslySetInnerHTML={rawStyles} />
        </>
      ),
    }
  }
}
person Luke    schedule 28.10.2020
comment
Это было, спасибо. Я добавлю правку с некоторым кодом, когда очередь редактирования больше не заполнится. - person Ben; 28.10.2020