@ jonathan-chin können Sie bitte relevante Umgebungsinformationen bereitstellen, indem Sie gatsby info --clipboard ausführen?

Außerdem habe ich festgestellt, dass Sie Gatsby v1 aus Ihrer package.json in dem von Ihnen freigegebenen Repo verwenden. Bitte verwenden Sie gatsby-cli Version 1.x.x für Gatsby v1. gatsby-cli version 2.x.x ist für Gatsby v2

@ Kakadiadarpan

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 9.4.0 - /usr/local/bin/node
    Yarn: 1.3.2 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Safari: 12.0
  npmPackages:
    gatsby: ^1.9.277 => 1.9.278
    gatsby-image: ^1.0.24 => 1.0.55
    gatsby-link: ^1.6.28 => 1.6.46
    gatsby-plugin-canonical-urls: ^1.0.11 => 1.0.18
    gatsby-plugin-google-analytics: ^1.0.12 => 1.0.31
    gatsby-plugin-google-fonts: 0.0.3 => 0.0.3
    gatsby-plugin-material-ui: ^0.1.3 => 0.1.3
    gatsby-plugin-nprogress: ^1.0.10 => 1.0.14
    gatsby-plugin-react-helmet: ^1.0.5 => 1.0.8
    gatsby-plugin-react-next: ^1.0.11 => 1.0.11
    gatsby-plugin-sass: ^1.0.26 => 1.0.26
    gatsby-plugin-sharp: ^1.6.48 => 1.6.48
    gatsby-remark-autolink-headers: ^1.4.8 => 1.4.19
    gatsby-remark-copy-linked-files: ^1.5.36 => 1.5.37
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^1.5.67 => 1.5.67
    gatsby-remark-responsive-iframe: ^1.4.19 => 1.4.20
    gatsby-source-filesystem: ^1.5.8 => 1.5.39
    gatsby-transformer-remark: ^1.7.21 => 1.7.44
    gatsby-transformer-sharp: ^1.6.14 => 1.6.27
  npmGlobalPackages:
    gatsby-cli: 2.0.0-rc.1
    gatsby: 1.9.278

Wenn ich mein globales gatsby-cli auf 1.9.X herunterstufte, tritt das CSS-Problem auf. Wenn ich es bei 2.0.0-rc.1 behalte, wird mir der Fehler BrowserslistError: Unknown browser query dead angezeigt

@ jonathan-chin Ich verstehe, dass Sie das CSS-Problem mit gatsby-cli Version 1.9.x , aber das ist die Version, die Sie verwenden sollten, da sie mit der von Ihnen verwendeten Gatsby-Version kompatibel ist.

Vielen Dank, dass Sie das Reproduktions-Repo geteilt haben. Ich werde mir das ansehen.

@ jonathan-chin Könnten Sie feststellen, welches CSS sich in Entwicklung und Build genau unterscheidet?

@ Kakadiadarpan
Dies ist von der Entwicklung und ist das Styling erwartet

Das bekomme ich von Build:

Sie können sehen, dass ihre CSS-Klassen unterschiedlich sind.

Ich erinnere mich nicht, dass dies zuvor ein Problem war. Der letzte gute Build (bei dem CSS nicht betroffen war) war https://gitlab.com/sharemeals/gatsby-site/commit/4342a715d6a1cdcb2808e5450819753be6f56a19

Ich denke, das Update dafür ist # 8092.

@ jonathan-chin Würdest du in der Lage sein, den Inhalt dieses Fixes nach unten zu ziehen und es dann mit diesen Änderungen zu versuchen? Hinweis: Wenn Sie es noch nicht gesehen haben, finden Sie im Abschnitt " Wie man einen Beitrag leistet" in Gatsbys Dokumenten Informationen dazu, wie Sie mit gatsby-dev-cli eingerichtet werden. Sie müssen es testen!

Auch @ jonathan-chin sieht aus, als wären Sie auf Gatsby v1. Könnten Sie ein Upgrade auf Gatsby v2 durchführen, um dieses Update zu erhalten?

@DSchau Entschuldigung, ich habe so lange

Die Migration des vorhandenen Projekts auf Version 2 war zu viel Arbeit. Ich habe beschlossen, einen neuen v2-Starter zu starten und ihn Stück für Stück zu migrieren (nach Bedarf kopieren und ändern). In diesem Fall erzeugt Gatsby Develop eine radikal andere Ausgabe als Gatsby Build:

Gatsby bauen

gatsby entwickeln

Vergleichen der CSS-Stile zweier identischer Elemente beim Erstellen und Entwickeln:

bauen:

.jss94 {
  color: #fff;
  font-size: 0.875rem;
  font-weight: 500;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  text-transform: uppercase;
}

entwickeln:

.MuiTypography-headline-88 {
  color: #fff;
  font-size: 1.5rem;
  font-weight: 400;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  line-height: 1.35417em;
}

Ich habe einige Material UI überschreibende scss, die ich in die Layout-Komponente in v2 lade. in der Entwicklung scheint es, sie gut zu verschmelzen, aber in der Entwicklung scheint es, sie zu ignorieren? Kann das die Ursache sein?

Ich habe nur ein import '../scss/style.scss';

@ jonathan-chin hast du das mit v2 oder gemäß den im Kommentar von @DSchau oben erwähnten Schritten

@kakadiadarpan Entschuldigung, ich habe nicht die Kapazität (dh die Zeit), um diesen

Nachdem ich mir das PR-Update angesehen habe, scheint es das gleiche Problem zu sein, das ich habe. Ich kann dieses Problem vorerst schließen und die PR überwachen.

@kakadiadarpan Entschuldigung, ich habe gerade etwas Seltsames realisiert.

Wenn meine Site zum ersten Mal geladen wird, ist das CSS verrückt. Wenn Sie jedoch das Neuladen der Indexseite erzwingen, wird das CSS problemlos geladen. Hier sind die Schritte zum Reproduzieren:

1) Laden Sie https://sharemeals.org/
Untersuchen Sie das Emerson-Zitat unten:

2) Klicken Sie oben links auf den Site-Namen. Die Indexseite wird neu geladen, ohne die Site zu aktualisieren. Das Emerson-Zitat erscheint wie erwartet:

(Das Emerson-Zitat weist auf andere CSS-Änderungen hin. Ich rufe dieses nur auf, weil es am sichtbarsten ist.)

@ Jonathan-Chin Danke für das Update. Ich kann das Problem mit den von Ihnen angegebenen Schritten reproduzieren. Verwenden Sie Gatsby v1 oder v2 für https://sharemeals.org/?

~ Ich habe genau das gleiche Problem: ~

~ Wenn ich injectGlobal , erhalte ich verschiedene Stile, nachdem ich gatsby build . Sie können das Problem hier sehen: https://ivorpad.com/about~

~ Nachdem die Seite vollständig geladen wurde, bewegen Sie den Mauszeiger über die Links 'Schreiben' oder 'Arbeiten' und Sie werden sehen, wie sich die Stile ändern. ~

Es wurde behoben, indem die Überschriftenstile auf page.js anstatt auf global verschoben wurden.

 System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.11.4 - ~/n/bin/node
    Yarn: 1.2.1 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/n/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 62.0.2
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.7 => 2.0.8
    gatsby-plugin-google-analytics: ^2.0.0-rc.2 => 2.0.0-rc.2
    gatsby-plugin-google-fonts: ^0.0.4 => 0.0.4
    gatsby-plugin-react-helmet: ^3.0.0-rc.1 => 3.0.0
    gatsby-plugin-styled-components: ^3.0.0 => 3.0.0
    gatsby-plugin-typography: ^2.2.0 => 2.2.0
    gatsby-remark-prismjs: ^3.0.1 => 3.0.1
    gatsby-source-contentful: ^2.0.1-beta.15 => 2.0.1
    gatsby-transformer-remark: ^1.7.44 => 1.7.44

@kakadiadarpan , das "gatsby": "^1.9.277"

Ich denke, das Update dafür ist # 8092.

@ jonathan-chin Würdest du in der Lage sein, den Inhalt dieses Fixes nach unten zu ziehen und es dann mit diesen Änderungen zu versuchen? Hinweis: Wenn Sie es noch nicht gesehen haben, finden Sie im Abschnitt " Wie man einen Beitrag leistet" in Gatsbys Dokumenten Informationen dazu, wie Sie mit gatsby-dev-cli eingerichtet werden. Sie müssen es testen!

@ jonathan-chin Kannst du Vorschläge von @DSchau in diesem Kommentar ausprobieren?

@kakadiadarpan Ich glaube, ich habe gerade versucht, dies umzusetzen. Ich habe gatsby-cli-dev installiert, gegabelt und gezogen, den Zweig gewechselt usw. usw.

Das Problem besteht weiterhin.

Wie kann ich überprüfen, ob die neuen node_modules / gatsby, die ich habe, korrekt sind und nicht die alten?

Ich habe weitere Nachforschungen angestellt, mit Gatsby 1.XX und ohne das vorgeschlagene Update.

(Ich habe versucht, ein Upgrade auf Gatsby 2.XX durchzuführen, und das vorgeschlagene Update wurde separat durchgeführt. Beide haben nicht funktioniert.)

Die jss-Klasse für den gewünschten Stil ist beim ersten Seitenladen vorhanden. in diesem Fall .jss58. Das Element, das ich betrachte, erhält jedoch beim ersten Laden nicht .jss58. Erst wenn eine andere Seite angefordert wird (auch wenn dieselbe Seite angefordert wird), erhält das Element .jss58 korrekt

Was ist also für die Bestimmung der anzuwendenden JSS-Klassen zuständig? Gibt es einen Grund, warum es beim ersten Laden ein Ergebnis geben würde, bei allen nachfolgenden Seitenanforderungen jedoch ein anderes Laden?

EDIT: Es gibt einige andere wichtige Probleme. Beim Erstellen der Produktion werden meine SVG-Symbole unabhängig von der Seitenanforderung nie vollständig geladen:

Das bekomme ich stattdessen bei der Entwicklung:

Ich stehe vor dem gleichen Problem. Die Versionen Gatsby Develop und Gatsby Build sind für mich sehr unterschiedlich.

Wenn ich direkt lande oder eine Seite mit Material-UI-Komponenten aktualisiere, ist das CSS für diese Komponenten fehlerhaft. Die Klassen sind in der Quelle vorhanden, werden jedoch nicht auf die Elemente angewendet. Wenn ich einem <Link> auf dieselbe Seite folge, funktioniert jedoch alles einwandfrei.

Ich habe auch festgestellt, dass sich die Gatsby-Entwicklungsversion genauso verhält wie die Gatsby-Build-Version, wenn ich gatsby build ausführe, während gatsby develop wird.

System:
    OS: Linux 3.10 Red Hat Enterprise Linux Workstation 7.3 (Maipo)
    CPU: x64 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
    Shell: 4.2.46 - /bin/bash
  Binaries:
    Node: 11.1.0 - /usr/bin/node
    Yarn: 1.12.1 - /usr/bin/yarn
    npm: 6.4.1 - /usr/bin/npm
  Browsers:
    Chrome: 70.0.3538.77
  npmPackages:
    gatsby: 2.0.37 => 2.0.37
    gatsby-cli: 2.4.4 => 2.4.4
    gatsby-plugin-typography: 2.2.1 => 2.2.1
    gatsby-source-atom: 0.1.0 => 0.1.0
    gatsby-source-ghost: 2.1.2 => 2.1.2
  npmGlobalPackages:
    gatsby-cli: 2.4.4

(Ich habe noch nie Gatsby-Plugin-Offline verwendet)

Sie können die Website unter http://pawanhegde.netlify.com besuchen
Die Quelle ist https://gitlab.com/PawanH/pawanh.gitlab.io/tree/gatsbyjs

Um die "erwartete" Version anzuzeigen, klicken Sie auf eines der komisch großen Symbole unten.

Ich hatte noch keine Zeit, das Update für # 8092 zu testen

Ich hatte noch keine Zeit, das Update für # 8092 zu testen

Es hat das Problem für mich nicht behoben. Ich sehe immer noch das gleiche Verhalten.

Erwartet

Tatsächlich

Wenn ich direkt lande oder eine Seite aktualisiere ... ist das CSS für diese Komponenten fehlerhaft. Die Klassen sind in der Quelle vorhanden, werden jedoch nicht auf die Elemente angewendet. Wenn ich einem <Link> auf dieselbe Seite folge, funktioniert jedoch alles einwandfrei.

Dies geschieht auch genau so, wie es für mich beschrieben wurde. Ich habe das Update unter https://github.com/gatsbyjs/gatsby/pull/8092 versucht und es hat für die meisten Seiten funktioniert, aber nicht für alle.

Erwartet:

Tatsächlich:

  System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.10.0 - /usr/local/bin/node
    Yarn: 1.9.4 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 70.0.3538.102
    Firefox: 62.0.3
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.46 => 2.0.46 
    gatsby-image: ^2.0.20 => 2.0.20 
    gatsby-link: ^2.0.6 => 2.0.6 
    gatsby-plugin-catch-links: ^2.0.8 => 2.0.8 
    gatsby-plugin-flow: 1.0.2 => 1.0.2 
    gatsby-plugin-google-analytics: ^2.0.7 => 2.0.7 
    gatsby-plugin-manifest: ^2.0.9 => 2.0.9 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.1 
    gatsby-plugin-root-import: 2.0.4 => 2.0.4 
    gatsby-plugin-sass: ^2.0.4 => 2.0.4 
    gatsby-plugin-sharp: 2.0.12 => 2.0.12 
    gatsby-plugin-sitemap: ^2.0.2 => 2.0.2 
    gatsby-plugin-svgr: 2.0.0-alpha => 2.0.0-alpha 
    gatsby-remark-copy-linked-files: 2.0.6 => 2.0.6 
    gatsby-remark-images: 2.0.6 => 2.0.6 
    gatsby-remark-responsive-iframe: ^2.0.6 => 2.0.6 
    gatsby-remark-smartypants: 2.0.6 => 2.0.6 
    gatsby-source-filesystem: 2.0.8 => 2.0.8 
    gatsby-source-wordpress: 3.0.13 => 3.0.13 
    gatsby-transformer-remark: 2.1.12 => 2.1.12 
    gatsby-transformer-sharp: ^2.1.8 => 2.1.8 

Ich habe dieses Problem wie folgt gelöst
in der index.js Datei hatte ich

import 'injectSheet' from react-jss
import './../bootstrap.min.css'

Durch Umkehren der Reihenfolge konnte ich die Reihenfolge angeben, in der ich CSS in das HTML importieren wollte.
Mein letzter Code war also

import './../bootstrap.min.css'
import 'injectSheet' from react-jss

Lösung : Ändern Sie die Reihenfolge der Importe
Dies löste das Problem für mich. Hoffentlich macht es dir dasselbe.

Ich habe unter anderem die gleichen Probleme:

• develop läuft nicht deterministisch, aber wenn es läuft, funktioniert es gut.
• StaticQuery kann das Laden von Bildern nicht unbestimmt beenden.
• build schlägt nicht deterministisch fehl, normalerweise fehlerhaft in Bildmaterial.
• build Ausgabe von develop - dies ist der Deal Breaker.
• develop und build scheinen miteinander zu interagieren.

Diese Probleme sind so schlimm, dass sie leider den Nutzen von Gatsby für mich überwiegen und mich dazu zwingen, wieder zur Create React App zu wechseln.

Ich habe verschiedene Problemumgehungen ausprobiert, z. B. das Entfernen aller Inline-Stile und das Importieren von .scss in die untergeordneten Komponenten und nicht auf Stammebene.
Trotzdem bleibt das Problem bestehen. Das ist wirklich beunruhigend

Ich verwende gestaltete Komponenten und füge gatsby-plugin-styled-components in gatsby-config.js für mich funktioniert hat.

Das gleiche Problem haben.
Der Gatsby-Build wendet einen anderen Klassennamen an, aber ich kann im React Inspector sehen, dass die richtige Klasse angewendet wird.

System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.14.2 - ~/.nvm/versions/node/v10.14.2/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.14.2/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 59.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.107 => 2.0.107
    gatsby-image: ^2.0.20 => 2.0.25
    gatsby-plugin-google-analytics: ^2.0.9 => 2.0.9
    gatsby-plugin-manifest: ^2.0.9 => 2.0.12
    gatsby-plugin-offline: ^2.0.16 => 2.0.19
    gatsby-plugin-react-helmet: ^3.0.2 => 3.0.4
    gatsby-plugin-react-svg: ^2.0.0-beta1 => 2.0.0-beta1
    gatsby-plugin-sass: ^2.0.7 => 2.0.7
    gatsby-plugin-sharp: ^2.0.16 => 2.0.16
    gatsby-remark-copy-linked-files: ^2.0.8 => 2.0.8
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^3.0.1 => 3.0.1
    gatsby-source-filesystem: ^2.0.12 => 2.0.12
    gatsby-transformer-remark: ^2.1.15 => 2.1.15
    gatsby-transformer-sharp: ^2.1.9 => 2.1.9
  npmGlobalPackages:
    gatsby-cli: 2.4.6

Hiya!

Dieses Problem ist behoben. Gruselig leise. 👻

Wir haben viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Seit dem letzten Update hier sind mindestens 20 Tage vergangen.

Wenn wir dieses Problem verpasst haben oder wenn Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Label "not stale" hinzufügen, um dieses Problem offen zu halten!

Vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

Bitte bleiben Sie offen.

Problem ist immer noch nicht behoben. Bitte bleiben Sie ein bisschen offen

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

Problem ist immer noch nicht behoben. Bitte bleiben Sie ein bisschen offen

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

Wie unter https://github.com/gatsbyjs/gatsby/issues/11072 angegeben , sollte das Problem in 7058a256d2dcfab91259bdf00e811375737414e7 behoben werden.

Nur in meinem speziellen Anwendungsfall wurde @emotion/global zum Einfügen eines globalen Stils in die Anwendung verwendet. Irgendwie blieben die Probleme bei der Codeaufteilung in Kombination mit den @emotion/global -Funktionalitäten weiterhin bestehen.

Problemumgehung beheben

Die folgenden Schritte wurden unternommen, um die Probleme zu beheben. Keine perfekte Lösung, aber es hat in diesem Setup funktioniert.

1. Update auf den neuesten Gatsby-Build ^2.1.8
2. Finden Sie heraus, wo import { Global, css } from '@emotion/core' wird, und verschieben Sie das CSS-Styling in eine neue Datei ./styles/global.css
3. Fügen Sie das Stylesheet in Ihren Produktionsbuild ein, indem Sie gatsby-brower.js zum Projektstamm hinzufügen

// gatsby-brower.js

import './src/styles/globals.css'

1. Bereinigen Sie den alten Cache und erstellen Sie den Ordner rm -rf .cache && rm -rf public
2. gatsby build -> gatsby serve
3. Voilá 💁‍♂️

Anmerkungen

• Ich vermute, dass viele der oben genannten Probleme durch ungewöhnliche Methoden zum Einfügen von (globalen) Stilen verursacht werden, die unter https://github.com/gatsbyjs/gatsby/issues/11072 erwähnt werden
• Wahrscheinlich ist die obige Problemumgehung eine spezifische Lösung für den Anwendungsfall.
• Dieses Tutorial zum Styling in Gatsby hat mir geholfen, es zu lösen

Dies ist ein frustrierendes Problem.

Für mich machten Animationen, die mit react-pose nämlich in gatsby-browser.js und gatsby-ssr.js , einige seltsame Voodoo-Sachen, doppeltes Rendern und einige unbestimmte CSS-Sachen, bei denen die Seite bei einer zweiten Aktualisierung funktionieren würde.

Ich kann immer noch nicht auf das genaue Problem hinweisen, aber Plugins überprüfen und schließlich entfernen, Bibliotheken entfernen, es lösen.

Während Gatsby neben anderen JS-Tools fantastisch und auffällig sein kann, sollten Sie vorsichtig und verantwortungsbewusst sein, wenn Sie es in der Produktion (nicht) verwenden.

Ist es möglich, eine neue Reproduktion zu teilen? Denn wenn wir css-in-js verwenden, können wir dies möglicherweise nicht beheben, da es nicht unsere Schuld ist.

Ich bin auch auf dieses Problem gestoßen.

Ich habe vor ein paar Tagen typography.js hinzugefügt. Dann erkannte ich die Stile basierend auf typography.js funktioniert gut in gatsby develop , aber sie sind nicht in gatsby build . Ich habe die Apps aus der Starter-Vorlage erstellt.

Ich habe versucht, die Version zu aktualisieren, es funktioniert nicht.
Dann fand ich, dass es ein layout.css

Meine Lösung besteht darin, layout.css zu kommentieren, und es scheint dieses Problem zu beheben

Projekt nach dem Hinzufügen von typography.js
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/ffb52973c21014b247a808e444319f8eede6eee6

Projekt nach dem Auskommentieren von layout.css
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/658c7f8976d8d84a1fd28cb9aa6c99bbce2be9b3

@ Jasonlhy Das war genau das Problem für mich. Die Datei layout.js in meinem Komponentenordner importiert die Datei layout.css. Nachdem ich diesen Import entfernt und npm run build und npm run serve erneut ausgeführt hatte, wurde die Site einwandfrei angezeigt. Ich danke dir sehr!

Ist es möglich, eine neue Reproduktion zu teilen? Denn wenn wir css-in-js verwenden, können wir dies möglicherweise nicht beheben, da es nicht unsere Schuld ist.

Hallo @wardpeet , dies tauchte gerade in einem meiner Projekte auf, als ich Komponenten im Gatsby-Plugin-Stil hinzufügte. Hier ist eine neue Reproduktion des Problems, das weiterhin auf dem aktualisierten Gatsby auftritt:

BEARBEITEN: Es stellt sich heraus, dass ich keine Reproduktion mehr habe, da sich das Problem beim Bearbeiten meiner Stile ständig ändert. Nach dem Bereitstellen meines nächsten Commits hat sich die Reihenfolge der Importe erneut geändert. Mein CSS ist jetzt in dev und prod gleich. Die beigefügten Screenshots und die Beschreibung zeigen, was früher passiert ist ...

Beschreibung

Gatsby bestellt die <head> in Entwicklung und Produktion unterschiedlich. Wenn Sie Komponenten im Gatsby-Plugin-Stil neben globalem CSS verwenden, kann dies dazu führen, dass sich die CSS-Ladereihenfolge zwischen dev und prod unterscheidet, was zu unerwarteten visuellen Fehlern führt.

Dies ist identisch mit # 9908, das zusammen mit einer Reihe ähnlicher Probleme zugunsten von # 9733 geschlossen wurde, das wiederum geschlossen wurde, weil es gemäß @KyleAMathews in # 11800 behoben wurde. Ich sehe jedoch immer noch das Verhalten von # 9908, nachdem sichergestellt wurde, dass Gatsby aktualisiert wurde.

Schritte zum Reproduzieren

Ich habe ein Live-Beispiel (aber nicht minimal) für das Problem in diesem Repo: https://github.com/vivshaw/vivshaw. Diese Site enthält einen Teil des globalen CSS, einschließlich des Bulma CSS-Frameworks. Der Rest der Site besteht aus gestalteten Komponenten. Die Produktionsversion ist live auf netlify .

Erwartetes Ergebnis

Sowohl gatsby develop als auch gatsby build gatsby serve sollten gleich aussehen. Die Ladereihenfolge sollte konsistent sein.

Tatsächliche Ergebnis

Bei der Erstellung für die Produktion sehen wir das richtige Seiten-Styling:

Aber wenn wir es mit gatsby develop aufladen, ist die Polsterung im Intro-Bereich AWOL geworden:

Ich grub ein bisschen und fand heraus, warum. In der Produktion lädt Gatsby den globalen CSS-Block vor den Stilen der gestalteten Komponenten, wie durch die beiden hervorgehobenen Linien hier sichtbar:

Bei der Entwicklung werden jedoch zuerst die Stile für gestaltete Komponenten geladen:

Warum verursacht dies einen Fehler? Nun, ich habe die Komponente sowohl mit einer Bulma-Klasse als auch mit einer von Styled-Components generierten Klasse markiert. Beide Klassen wirken sich auf die Polsterungseigenschaften aus. Was also zuletzt geladen wird, wird angewendet. In diesem Fall ist es leicht lösbar, indem einfach die Bulma-Klasse entfernt wird. Ich kann mir jedoch Situationen vorstellen, in denen dieses Ladeordnungsverhalten zu komplexeren Problemen führt.

Umgebung

> gatsby info

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
  Binaries:
    Yarn: yarn install v0.27.5
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 118.04s. - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.4.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.13 - /c/Python27/python
  Browsers:
    Edge: 42.17134.1.0
  npmPackages:
    gatsby: ^2.3.16 => 2.3.16
    gatsby-image: ^2.0.37 => 2.0.37
    gatsby-plugin-eslint: ^2.0.4 => 2.0.4
    gatsby-plugin-layout: ^1.0.14 => 1.0.14
    gatsby-plugin-manifest: ^2.0.28 => 2.0.28
    gatsby-plugin-netlify: ^2.0.13 => 2.0.13
    gatsby-plugin-netlify-cms: ^3.0.17 => 3.0.17
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-purgecss: ^3.1.1 => 3.1.1
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-robots-txt: ^1.4.0 => 1.4.0
    gatsby-plugin-sass: ^2.0.11 => 2.0.11
    gatsby-plugin-sharp: ^2.0.32 => 2.0.32
    gatsby-plugin-sitemap: ^2.0.12 => 2.0.12
    gatsby-plugin-styled-components: ^3.0.7 => 3.0.7
    gatsby-plugin-webpack-size: 0.0.3 => 0.0.3
    gatsby-source-filesystem: ^2.0.29 => 2.0.29
    gatsby-transformer-remark: ^2.3.8 => 2.3.8
    gatsby-transformer-sharp: ^2.1.17 => 2.1.17

Vielen Dank, wir sind uns nicht sicher, wie wir das beheben können. Vielleicht möchten wir den Kopfkomponenten eine Art Sortierung hinzufügen.

Ich sehe die gleichen Probleme wie oben von @topherauyeung erwähnt

Umgebung

gatsby info

  System:
    OS: macOS High Sierra 10.13.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.7.0 - /usr/local/bin/node
    Yarn: 1.15.2 - ~/.yarn/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 73.0.3683.103
    Firefox: 66.0.2
    Safari: 11.1
  npmPackages:
    gatsby: ^2.3.24 => 2.3.27
    gatsby-image: ^2.0.39 => 2.0.40
    gatsby-plugin-manifest: ^2.0.29 => 2.0.29
    gatsby-plugin-material-ui: ^1.2.4 => 1.2.4
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-sharp: ^2.0.35 => 2.0.35
    gatsby-plugin-typography: ^2.2.13 => 2.2.13
    gatsby-source-filesystem: ^2.0.29 => 2.0.31
    gatsby-transformer-sharp: ^2.1.18 => 2.1.18
  npmGlobalPackages:
    gatsby-cli: 2.5.4

Ich habe auch dieses Problem. Wir haben ein Gatsby-Repo, das Komponenten aus einer NPM-Bibliothek abruft. Die Komponenten importieren .scss Dateien, die beim Erstellen in der falschen Reihenfolge in <head> eingefügt werden. Bei der Entwicklung haben die Stile des Gatsby-Repos den letzten Platz, daher haben sie Vorrang. Beim Erstellen stehen sie jedoch an erster Stelle und werden von den Stilen der importierten Komponente überschrieben.

Ich habe ein ähnliches Problem, das möglicherweise damit zusammenhängt. Ich lade die Stile dinamisch, beim Entwickeln von Gatsby sind die Stile relativ zum aktuellen Layout, beim Erstellen von Gatsby werden alle Stile in 'source.less' auch auf das App-Layout angewendet

componentDidMount() { require("./source.less") }

Fand dieses Problem auch. Aber mein Fall war ein einfacher Fehler.
Ich habe benutzt

<Button href="/path/to/page">blah blah</Button>

Wenn ich auf Gatsby Link umgestiegen bin, funktioniert es

<Link to="/path/to/page">
  <Button>blah blah</Button>
</Link>

Gleiches Problem. Behalte eine Lösung im Auge, während ich versuche zu debuggen.

Hinzu kommt, weil ich denke, dass es verwandt ist, aber erst in letzter Zeit ein Problem war:
Ich verwende sowohl Typography.js als auch Bootstrap - in der Produktion wird der Bootstrap von typography.js überschrieben, was ich möchte, aber auf dem Entwicklungsserver überschreiben die Bootstrap-Schriftstile meine Typografiestile. Das ist ziemlich ärgerlich, weil ich die Site bereitstellen muss, um zu sehen, wie sie wirklich aussieht. Wenn jemand weiß, wie ich Bootstrap mit typography.js in Gatsby Develop außer Kraft setzen kann, würde ich es wirklich schätzen

Hinzu kommt, weil ich denke, dass es verwandt ist, aber erst in letzter Zeit ein Problem war:
Ich verwende sowohl Typography.js als auch Bootstrap - in der Produktion wird der Bootstrap von typography.js überschrieben, was ich möchte, aber auf dem Entwicklungsserver überschreiben die Bootstrap-Schriftstile meine Typografiestile. Das ist ziemlich ärgerlich, weil ich die Site bereitstellen muss, um zu sehen, wie sie wirklich aussieht. Wenn jemand weiß, wie ich Bootstrap mit typography.js in Gatsby Develop außer Kraft setzen kann, würde ich es wirklich schätzen

Dies wurde behoben, indem Bootstrap einfach mit dem neu erstellt wurde, was ich wollte

Gleiches Problem hier - https://github.com/gatsbyjs/gatsby/issues/16075

Ich habe ein ähnliches Problem wie hier beschrieben. Obwohl ich keine CSS-Frameworks (alle benutzerdefinierten .sass) verwende, werden einige Stile, Elemente und Klassen zwischen gatsby develop und gatsby build .

Dies geschieht auf einer Seite, auf der ich mit URLSearchParams(window.location.search) nach Suchparametern suche. Damit zeige ich dynamisch ein Element an, je nachdem, ob ein Parameter vorhanden ist oder nicht. Wenn Sie direkt zur URL auf develop , funktioniert alles einwandfrei. Bei build wird alles anders gehandhabt.

Erwartet ( develop ) :

Tatsächlich ( build ) :

Bedingte Logik :

{(!!params ? !params.has('signup') : true) && (
    <div className={[ styles.form__element, styles.contact__message, ].join( ' ')}>
        <label htmlFor="message">
            Message
            <textarea required minLength="10" name="message" id="message" cols="30" rows="10" className={styles.form__control} placeholder="Questions, comments, etc..." />
        </label>
    </div>
)}

params wird festgelegt durch :

const params = typeof window !== `undefined` ? new URLSearchParams(window.location.search) : ''

System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.15.3 - /usr/local/bin/node
    npm: 6.10.2 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.13.50 => 2.13.50
    gatsby-image: ^2.2.8 => 2.2.8
    gatsby-plugin-google-analytics: ^2.1.6 => 2.1.6
    gatsby-plugin-hotjar: ^1.0.1 => 1.0.1
    gatsby-plugin-manifest: ^2.2.4 => 2.2.4
    gatsby-plugin-offline: ^2.2.4 => 2.2.4
    gatsby-plugin-react-helmet: ^3.1.3 => 3.1.3
    gatsby-plugin-sass: ^2.1.4 => 2.1.4
    gatsby-plugin-sharp: ^2.2.9 => 2.2.9
    gatsby-plugin-sitemap: ^2.2.5 => 2.2.5
    gatsby-remark-external-links: 0.0.4 => 0.0.4
    gatsby-source-contentful: ^2.1.17 => 2.1.17
    gatsby-source-filesystem: ^2.1.8 => 2.1.8
    gatsby-transformer-remark: ^2.6.10 => 2.6.10
    gatsby-transformer-sharp: ^2.2.5 => 2.2.5
  npmGlobalPackages:
    gatsby-cli: 2.7.27

@ j-651 Ich habe anscheinend das gleiche Problem. Ich lese Daten aus dem lokalen Speicher und rendere Klassennamen bedingt, und die falschen Klassennamen werden gerendert. Problemumgehungen?

@OrKoN Was ich letztendlich getan habe, um dieses Problem zu

Ich habe ein ähnliches Problem. Erstens hatte ich eine andere Version wegen gestylter Komponenten. Ich habe das Plugin gatsby-plugin-styled-components hinzugefügt und diese haben sich selbst behoben. Dann bemerkte ich, dass MaterialUI zu brechen begann, also fügte ich gatsby-plugin-material-ui und hatte immer noch kein Glück. Die Material-Benutzeroberfläche ist bei der Bereitstellung immer noch fehlerhaft.

Produktion:

Dev (lokal)

Ich konnte mein Problem reproduzieren und im Repo https://github.com/gatsbyjs/gatsby/issues/16925 isolieren. Es hängt mit dem Verhalten der Linkkomponente zusammen und ist wahrscheinlich ein anderes Problem

Dies ist keine richtige Lösung, sondern wollte nur eine schnelle Lösung finden, mit der ich ein Projekt aus der Tür bekommen musste.

Ich habe die Ausgabe von typography.js kopiert und eingefügt, sie in eine .scss-Datei eingefügt und danach alles andere mit einer kleinen Nachricht importiert.

typographyjs-output.scss
Ignorieren Sie einfach diese Datei bitte und danke!
Ich musste das von typography.js erzeugte CSS extrahieren und hier platzieren.
Warum? Siehe hier: https://github.com/gatsbyjs/gatsby/issues/8560
Der Produktionsbuild importiert SCSS und css-in-js in einer anderen Reihenfolge als dev (nicht sicher, ob es sich immer um eine konsistente Reihenfolge handelt).
Ich habe 'gatsby-plugin-typography' entfernt und das daraus generierte CSS wie ein normales altes Stylesheet importiert.
Typography.js war von Anfang an in dem Projekt enthalten und ich hatte nicht erwartet, dass es Probleme verursachen würde.
Also ja - ich habe den Rest der Site mit diesen Standardeinstellungen gestaltet, sodass das Entfernen dieser Datei die Dinge etwas seltsam aussehen lässt.

Ziemlich schreckliche Lösung, aber es funktioniert, wenn Sie in einer Bindung sind.

Ich habe gerade festgestellt, dass beim Laden der ersten Seite das CSS fehlerhaft ist, aber die Seite geändert und dann wieder zur Startseite zurückgekehrt wird und das CSS funktioniert. Erst beim ersten Laden der Seite sieht das CSS nicht richtig aus und wird auch ziemlich langsam geladen

Mit Material-UI hatte ich einen doppelten Aufruf für die gatsby-plugin-material-ui in der gatsby.config.js. Das anfängliche Laden der Seite flackerte und einige Stile wurden manchmal nicht hinzugefügt. Jetzt funktioniert es mit der neuesten Plugin-Version und diesem Modul-Export in das Plugins-Array von gatsby.config.js:
, { resolve: 'gatsby-plugin-material-ui', // If you want to use styled components you should change the injection order. options: { // stylesProvider: { // injectFirst: true, // }, }, }

Hat hier jemand eine Lösung gefunden? Ich sehe ein falsches Styling in der Produktion (erste Seitenansicht), obwohl lokal in Ordnung ist. Z.B. Die Komponente hat jss13 und jss14 in der Produktion, aber diese Klassen sollten jss43 und jss45 sein. Ich sehe auch, dass die Reihenfolge der Stile im Kopf unterschiedlich ist, aber ich weiß nicht, wie ich sie lösen soll ... Ich habe auch beide Plugins enthalten, aber kein Glück:

plugins: [
    'gatsby-plugin-styled-components',
    'gatsby-plugin-material-ui',
];

@ocundale Für mich bestand die Lösung darin, die Material-

const MyTab = styled(Tab)({
  border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
})

Durch Tun behoben

<Tab style={{
 border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
}}>
...
</Tab>

OK, danke @ Skillz4Killz , schätze die schnelle Antwort, scheint eine Schande, aber ich denke, ich werde dann auf die gleiche Methode zurückgreifen. Prost!

Dies ist keine richtige Lösung, sondern wollte nur eine schnelle Lösung finden, mit der ich ein Projekt aus der Tür bekommen musste.

Meine vorübergehende Korrektur bestand darin, jeder Zeile in meinem CSS !important hinzuzufügen, damit sie nicht von der CSS-Vorlage überschrieben wird. Brutal.

@ gatsbyjs / core Dieses Problem taucht immer wieder in verschiedenen Varianten in diesem Repository auf. # 3741 # 5100 # 9911 # 10370 # 12360 # 14601 # 17676 # 17728 (Ich bin sicher, es gibt noch mehr, ich entdecke sie ständig)

Dies ist ein kritisches Problem, da es keine eindeutige Problemumgehung gibt, Websites nicht deterministisch betrifft und häufig auf "mysteriöse Weise" auftritt, da es einige sehr indirekte Nebenwirkungen hat. Das Ändern von Attributen desselben HTML-Elements - insbesondere von class - ist ein sehr häufiger Anwendungsfall.

Wenn das, was in # 14601 gesagt wird, korrekt ist, ist dies ein Problem bei der Konsolidierung der in React 16 eingeführten Hydratationsfunktion.

Es gibt # 10706, das nur hilft, dieses Problem früher im Entwicklungsmodus zu entdecken, aber es behebt es meines Wissens nicht.

Für alle anderen, die dies erlebten, konnte ich das Problem beheben, ohne Inline-CSS / wichtig zu verwenden.
Kein geplanter Ansatz und fühlte sich eher nach Glück an, aber ich habe die Plugins _gatsby-plugin-material-ui_ und _gatsby-plugin-styled-components_ zusammen mit dem Upgrade der Material-UI auf Versionen> 4 hinzugefügt und sehe die Probleme nicht mehr.

{
  resolve: 'gatsby-plugin-material-ui',
  options: {
    stylesProvider: {
      injectFirst: true,
    },
  },
},
'gatsby-plugin-styled-components',

"@material-ui/core": "^4.0.0",
"@material-ui/icons": "^4.0.0",
"@material-ui/styles": "^4.4.1",

Ich kann das Problem reproduzieren, mindestens eine Instanz davon.

Erstellen Sie aus diesem Repository eine neue Gatsby-Site, die ursprünglich vom Standardstarter geklont wurde: https://github.com/eyalroth/gatsby-hydrate-bug

Es hat kaum Abhängigkeiten / Plugins:

$ gatsby info
  System:
    OS: Linux 4.4 Ubuntu 16.04.6 LTS (Xenial Xerus)
    CPU: (4) x64 Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
    Shell: 4.3.48 - /bin/bash
  Binaries:
    Node: 10.16.0 - ~/n/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.11.3 - ~/n/bin/npm
  Languages:
    Python: 2.7.12 - /usr/bin/python
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22
    gatsby-plugin-offline: ^3.0.8 => 3.0.8
  npmGlobalPackages:
    gatsby-cli: 2.7.44

Die Seite hat nur 2 Seiten und ein Layout. Das Layout wird automatisch über wrapPageElement zu den beiden Seiten hinzugefügt (fast der gleiche Code wie in gatsby-plugin-layout ). Das Layout umschließt den Seiteninhalt mit einem div , dessen Attribut class auf die aktuelle Zeit festgelegt ist, während die Zeit als Text unter dem Seiteninhalt angehängt wird.

Wenn Sie die Site erstellen (und bereitstellen), zum Index navigieren und ihn in den Entwicklertools überprüfen, können Sie feststellen, dass die auf der Seite angezeigte Zeit nicht mit der in div class Attribut:

Wenn Sie zur zweiten Seite navigieren, wird dieses Verhalten korrigiert, und Sie werden feststellen, dass die Zeit zwischen dem Seiteninhalt und dem Attribut class :

Dies bleibt so lange so, wie Sie zwischen den Seiten im selben Fenster navigieren. Wenn Sie die Seite aktualisieren oder in einem Fenster öffnen, schleicht sich die Inkonsistenz zurück. Sie werden tatsächlich feststellen, dass die Zeit im Attribut class jeder Aktualisierung gleich bleibt (was darauf hindeutet, dass sie zwischengespeichert ist). "Hard Refresh" (STRG + F5) lädt die Seite ordnungsgemäß.

Diese spezielle Instanz des Problems tritt nur gatsby-plugin-offline aktiviertem gatsby-plugin-layout und möglicherweise auf jede andere Implementierung von wrapPageElement .

Die einzige Problemumgehung, die ich bisher finden konnte, besteht darin, einfach die Hydratfunktion durch Rendern zu

// gatsby-browser.js
const ReactDOM = require('react-dom')

export function replaceHydrateFunction() {
    return (element, container, callback) => {
        ReactDOM.render(element, container, callback)
    }
}

Dies ist wiederum ein Problem bei der Abstimmung der Hydratmethode , wie in mehreren Abschnitten im React-Repository erläutert, z. B. https://github.com/facebook/react/issues/10591 , https://github.com/. facebook / react / issue / 12713 , https://github.com/facebook/react/issues/13260.

Beachten Sie, dass dies zu Leistungseinbußen führen kann, da der gesamte Zweck der "Hydratation" darin besteht, die Leistung gegenüber dem normalen Rendern zu steigern.

Wir schließen dieses Problem zugunsten von https://github.com/gatsbyjs/gatsby/issues/17914 , um die Organisation zu gewährleisten.

@eyalroth Ich stimme zu, dass dies ein Problem ist, das wir lösen müssen. Lassen Sie uns dies unter https://github.com/gatsbyjs/gatsby/issues/17914 diskutieren und dem auf den Grund gehen

Ich habe auch dieses Problem. Die Gatsby-Entwicklungsumgebung war in Ordnung, wurde jedoch beim erneuten Laden der Problemseite erstellt. Der Klassenname und sogar der Inline-Stil wurden aus den bestimmten Tags entfernt. Was mich mit einem Div ohne Attribute zurückließ, aber alle Kinder wurden gerendert.

Allerdings, wenn ich die Route mit dem Gatsby Link Router geändert habe, anstatt die ganze Seite zu aktualisieren. es behebt das Problem.

Das hat mich stundenlang verrückt gemacht. Ich fand eine schreckliche Lösung, wahrscheinlich keine gute Übung, aber sie hat vorerst funktioniert.

Aber ich habe das (div) -Tag in (article) geändert.

Plötzlich die

<div>

wurden

<article class="CartSummary-module--summary--3zJVn">

auf bauen

Es funktionierte auch mit ul und pre.

Vielen Dank für die verrückte Problemumgehung @ stefantrinh1 - auch ich erlebe dieses verrückte CSS-Verhalten

Wenn jemand möchte, dass es repliziert wird, habe ich ein öffentliches Repo und habe beide Versionen bereitgestellt:

scheint mit @ stefantrinh1s article Workaround zu funktionieren
https://github.com/funkfinger/blog/tree/good
https://good.jaywiggins.com

funktioniert nicht
https://github.com/funkfinger/blog/tree/bad
https://bad.jaywiggins.com

Ich hatte ein ähnliches Problem, als ich unter bestimmten Bedingungen versuchte, eine Komponente basierend auf dem Cookie-Wert zu laden. Dies funktionierte natürlich nicht, da Sie SSR in der Produktion haben (nicht sicher, warum es im Entwicklungsmodus funktioniert). Am Ende habe ich meinen Scheck in useEffect eingewickelt und überprüft, welche Komponente gerendert werden soll, sobald React den Client übernimmt (rehydriert). Sie können componentDidMount() für Klassenkomponenten verwenden. Nachdem ich dies implementiert habe, funktioniert alles wie erwartet.

Mein Problem war, dass ich wrapPageElement und wrapRootElement in gatsby-browser.js aber nicht in gatsby-ssr.js . Nachdem ich das, was ich hatte, auf gatsby-ssr.js kopiert hatte, funktionierten die Dinge wie erwartet. Bitte lesen Sie die Antwort von @jlkiri: https://github.com/gatsbyjs/gatsby/issues/22113#issuecomment -597432337

Gleiche Ausgabe im Jahr 2020. Klicken Sie auf behebt das Problem, aber beim vollständigen Neuladen liegt ein Problem vor.
"gatsby": "^ 2.19.45",
"React-Custom-Scrollbars": "^ 4.2.1",

Ich habe das gleiche Problem wie emailnikola

25729

In meinem Fall verursachte gatsby-plugin-minify dieses Problem, was dazu führte, dass der Produktionsbuild alle Stile im Produktionsbuild neu lud.