Detaillierte Erklärung zur Verwendung von css-vars-ponyfill in der IE-Umgebung (nextjs-Build)

CSS-Vars-Ponyfill

Bei der Verwendung von CSS-Variablen zum Skinning von Webseiten können Kompatibilitätsprobleme auftreten.

Um die Kompatibilitätsprobleme von IE, QQ, Baidu-Browser usw. zu lösen, wurde css-vars-ponyfill eingeführt. Im IE-Browser funktioniert css-vars-ponyfill unter nextjs jedoch schlecht. Der Hauptfehler besteht darin, dass die Seite serverseitig gerendert wird. Nachdem der Benutzer die Benutzeroberfläche gesehen hat, können dynamische Designfarben und andere Stile nicht schnell gerendert werden, sondern es gibt eine Übergangszeit (css-vars-ponyfill unterstützt nur clientseitig) und es wird einen offensichtlichen Farbaustauschprozess geben, was zu einer schlechten Benutzererfahrung führt. Durch Lesen des Quellcodes können wir sehen, dass cssVars warten muss, bis der Browserinhalt geladen ist, bevor es ausgelöst wird. Andernfalls hört es weiterhin auf das Dateninhaltsereignis des DOM, was zu Erfahrungsproblemen führt.

Lösung

1. Analysegeschwindigkeit

Durch direktes Entfernen der Einschränkungsbedingung von document.readyState !== 'loading' kann der Browser es analysieren und dann die Einführungsmethode von css-vars-ponyfill ändern (die alte Einführungsmethode besteht darin, das Modul in mainjs in nextjs einzuführen und dann cssVars() direkt aufzurufen. Auf diese Weise werden andere, nicht verwandte Blöcke analysiert, bevor das Ponyfill-Skript aufgerufen wird. Um die CSS-Variablen schneller zu analysieren, müssen Sie die Einfügeposition manuell auswählen). Das geänderte css-vars-ponyfill findet den Speicherort der CSS-Variable (nextjs verpackt die Stile unter verschiedenen Komponenten im Header) und fügt dann das geänderte Ponyfill in den aufzurufenden Stil ein. Dieser Schritt wird in der auf dem Server gerenderten Datei _document.tsx geändert.

2. Stabilität der Analyse

Durch manuelles Ändern des Dateianalysespeicherorts und relevante Änderungen am bedingten Auslösemechanismus des Quellcodes wurde die Farbwiedergabegeschwindigkeit der Homepage bis zu einem gewissen Grad verbessert. Es besteht jedoch immer noch ein Problem. Wenn ein neuer Stilblock über die Route-Jump-Schnittstelle eingefügt wird, kann keine effektive CSS-Variablenanalyse durchgeführt werden (ich habe versucht, die Option cssVars so zu konfigurieren, dass MutationObserver aktiviert wird).

Daher besteht die Lösung darin, die UA so zu bestimmen, dass alle Routen in Browsern wie IE über das A-Tag umgeleitet werden können, wodurch die erneute Analyse und Ausführung von CSS-Ponyfill ausgelöst wird.

Exportfunktion Browser() {
  const UA = window.navigator.userAgent
  wenn (UA.includes("qqbrowser")) returniere "qqbrowser"
  wenn (UA.includes("baidu")) "baidu" zurückgibt
  wenn (UA.includes("Opera")) "Opera" zurückgibt
  wenn (UA.includes("Edge")) returniere "Edge"
  wenn (UA.includes("MSIE") || (UA.includes("Trident") && UA.includes("rv:11.0")))
    "IE" zurückgeben
  wenn (UA.includes("Firefox")) "Firefox" zurückgibt
  wenn (UA.includes("Chrome")) "Chrome" zurückgibt
  wenn (UA.includes("Safari")) return "Safari"
}

Typ CommonLinkProps = {
    untergeordnete Elemente: ReactElement
    href?: Zeichenfolge
    Ziel?: Zeichenfolge
    äußererLink?: Boolesch
    Stile?: unbekannt
}
exportiere Standardfunktion CustomLink(props: CommonLinkProps) {
  const { untergeordnete Elemente, href, Ziel, as, outerLink, Stile = leereStile } = Requisiten
  const [isIE, setIE] = useState<boolean>(false)
  const cloneEl = (c: ReactElement, Eigenschaften?: beliebig) =>
    React.cloneElement(c, { href: als ?? href, Ziel, ...Requisiten })
  useEffect(() => {
    wenn (["IE", "qqbrowser", "baidu"].includes(browser())) {
      setIE(true)
    }
  }, [])
  Funktion renderLink() {
    wenn (Kinder.nur(Kinder).Typ === "a") {
      const node = cloneEl(untergeordnete Elemente als ReactElement)
      Rückgabeknoten
    } anders {
      lass fn: () => void | null = null
      wenn (äußerer Link) {
        fn = () => {
          Fenster.öffnen(als ?? href)
        }
      } anders {
        fn = () => {
          window.location.href = als ??href
        }
      }
      const node = cloneEl(children als ReactElement, {
        bei Klick: () => {
          fn()
        },
      })
      Rückgabeknoten
    }
  }

  zurückkehren (
    <>
      {!href ? (
        Kinder
      ) : istIE? (
        renderLink()
      ) : (
        <Link {...Requisiten}>{Kinder}</Link>
      )}
      <style jsx>{Stile}</style>
    </>
  )
}

Hier ist der Typ der untergeordneten Elemente ReactElement und nicht ReactNode , das normalerweise in Slots unterstützt wird. Dies liegt hauptsächlich daran, dass wir die Situation des direkten Einfügens von Zeichenfolgen nicht berücksichtigen möchten, da dies die Komplexität des Problems erhöhen würde. Daher beschränken wir es direkt auf Typebene. Fragmente werden nicht berücksichtigt und es wurde kein gültiger Fragmenttyp gefunden, daher kann er in ReactNode nicht weggelassen werden. Wenn Fragmente in die erste Ebene eingefügt werden, kann der Link in nextjs nicht normal springen. Der mögliche Grund ist, dass es unmöglich ist, gültige Ereignisse an Fragmente zu binden. Derzeit unterstützen Fragmente (16.13.1) nur Schlüsselattribute. Ich hoffe, dass dies später optimiert werden kann.

Zusammenfassen

Dies ist das Ende dieses Artikels über die Verwendung von css-vars-ponyfill in der IE-Umgebung (NextJS-Build). Weitere relevante Inhalte zur Verwendung von css-vars-ponyfill finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!