Gatsby: Désactiver le routage côté client?

Pourquoi ne savez-vous pas quels chemins le serveur affiche?

C'est moins que je ne connaisse pas les chemins (je peux écrire une regex qui les corresponde) mais plus le chevauchement. La configuration réelle se trouve derrière un serveur Apache qui inverse les proxies vers un tas d'applications différentes, y compris le site gatsby. Si l'une de ces applications devient indisponible ou renvoie une erreur de serveur interne, nous renvoyons une page d'erreur personnalisée qui fait partie du site gatsby.

Ainsi, à tout moment, si app1 est indisponible ou se comporte mal, toute demande à / app1 renverra le contenu de /error/unavailable.html ou /error/internal.html, et il en irait de même pour app2, et ainsi de suite .

L'utilisation d'un matchPath comme /^(app1|app2)/.*/ , sur les deux pages d'erreur interne et indisponible ne fonctionne pas car findPage ne sait pas (en fonction de l'URL) quelle page je souhaite réellement pour montrer à l'utilisateur.

J'ai pu faire fonctionner quelque chose en utilisant une variable globale et en "patcher" ___history et ___loader dans onClientEntry . C'est très fragile en raison de la dépendance à gatsby exposant ces globaux - je ne sais pas s'il existe un moyen de généraliser cela et de l'ajouter à gatsby.

• L'historique des patches intercepte les appels en utilisant props.location.pathname
  component-renderer.js # L18-L28

• Le chargeur de correctifs attrape l'utilisation directe de window.location.pathname
  production-app.js # L155

// gatsby-browser.js
exports.onClientEntry = () => {
  // Check for a custom pathname
  const pathname = global.___pathname
  if (!pathname) return

  // Override the history location
  const history = global.___history
  history.location.pathname = pathname

  // Patch the resource loader
  const loader = global.___loader
  const { getResourcesForPathname } = loader

  loader.getResourcesForPathname = (path, ...args) => {
    return getResourcesForPathname(path === location.pathname ? pathname : path, ...args)
  }
}

// src/pages/page1.js
import React from "react"
import Helmet from 'react-helmet'

export default () => (
  <div>
    <Helmet>
      <script>{`window.___pathname = '/page1'`}</script>
    </Helmet>
    <div>Page 1!</div>
  </div>
)

Je suis également d'accord qu'il devrait y avoir une option de construction pour désactiver cette fonctionnalité. Nous avons également une configuration non conventionnelle et aimerions désactiver cette fonctionnalité temporairement pendant que nous terminons notre migration vers un site Gatsby complet.

Un simple drapeau au moment de la construction serait parfait.

Celui-ci, ça va? une solution pour cela?

Nous avons fini par modifier le pages.json pour qu'il corresponde au chemin dont nous avions besoin. Nous appelons fondamentalement addPagesArray avec le nom de chemin corrigé.

Je ne comprends toujours pas pourquoi cela génère une erreur? La page se charge bien et fonctionne. Cela devrait tout au plus être un avertissement lorsqu'il ne peut pas correspondre au chemin.

Cela étant dit, je ne sais pas s'il existe un moyen plus élégant de modifier le pages.json via un code de configuration ou d'exécution.

Je veux aborder ce problème.

Un projet sur lequel je travaille rencontre un problème similaire. Nous construisons un générateur de page de destination qui créera des applications Gatsby d'une seule page. Ce problème survient lorsque nous essayons de diffuser une page de destination en dehors de son domaine.

Ainsi, par exemple, nous avons notre application principale Gatsby www.example.com . Nous avons un service qui prendra les pages de destination de Gatsby et les servira à www.example.com/trial . Ainsi, une URL de page de destination ressemblerait à www.example.com/trail/ad-123 La page se charge initialement correctement jusqu'à ce que tout le JS se charge et que le routeur prenne le relais. La page de destination regarde le chemin et ne sait pas où il se trouve, alors elle essaie de changer le chemin pour placer la page à la racine, ressemblant à ceci www.example.com/ad-123 , ce qui entraîne une redirection 404.

Y a-t-il des plans pour ajouter une option configurable pour résoudre ce problème? L'équipe Gatsby serait-elle ouverte à un PR?

@ alex-greco-harrys Il me semble qu'un préfixe de chemin est ce que vous voudrez utiliser dans ce scénario.

J'avais également besoin de désactiver le routage côté client pour exécuter correctement Google Adsense sur mon site Web.

Les annonces automatiques Google Adsense ne détectent pas le routage côté client et les annonces ne s'actualisent pas lorsque les itinéraires sont mis à jour.

Puis-je désactiver le routage côté client?

Vous pouvez utiliser des balises a au lieu de gatsby-link dans des cas comme celui-là

J'ai pu faire fonctionner quelque chose en utilisant une variable globale et en "patcher" ___history et ___loader dans onClientEntry . C'est très fragile en raison de la dépendance à gatsby exposant ces globaux - je ne sais pas s'il existe un moyen de généraliser cela et de l'ajouter à gatsby.

• L'historique des patches intercepte les appels en utilisant props.location.pathname
  component-renderer.js # L18-L28
• Le chargeur de correctifs attrape l'utilisation directe de window.location.pathname
  production-app.js # L155

// gatsby-browser.js
exports.onClientEntry = () => {
  // Check for a custom pathname
  const pathname = global.___pathname
  if (!pathname) return

  // Override the history location
  const history = global.___history
  history.location.pathname = pathname

  // Patch the resource loader
  const loader = global.___loader
  const { getResourcesForPathname } = loader

  loader.getResourcesForPathname = (path, ...args) => {
    return getResourcesForPathname(path === location.pathname ? pathname : path, ...args)
  }
}

// src/pages/page1.js
import React from "react"
import Helmet from 'react-helmet'

export default () => (
  <div>
    <Helmet>
      <script>{`window.___pathname = '/page1'`}</script>
    </Helmet>
    <div>Page 1!</div>
  </div>
)

@TuckerWhitehouse où obtenez-vous ___history , ___loader ? Lorsque j'essaye de reproduire votre exemple, ces deux propriétés de global sont undfined .

@ alex-greco-harrys Il me semble qu'un préfixe de chemin est ce que vous voudrez utiliser dans ce scénario.

@ jgierer12 Cela aide à résoudre le premier élément de mon problème. Le deuxième élément est que le chemin final est inconnu jusqu'à ce que la page soit rendue. Nous avons un service d'apprentissage qui prend une collection de pages statiques et les sert en fonction des taux de conversion. Donc, à un chemin example.com/go/ nous pourrions servir 1 d'une collection de pages. Nous ne servirions donc pas la page sur un chemin comme example.com/go/first-page ou example.com/go/second-page . Ces deux seraient servis à example.com/go/page chemin.

Essentiellement, ce que j'essaie d'accomplir est de servir une page Gatsby sur le chemin que je veux.

@ alex-greco-harrys ces globaux ont été exposés par gatsby v1. Avec la mise à niveau vers la v2, je sais que le routeur sous-jacent est passé de react-router à reach-router, donc je suppose que ces globaux ont été affectés.

J'espère également utiliser Gatsby pour créer une application d'une seule page et je souhaite désactiver complètement le routage. Est-ce que quelqu'un connaît une solution de contournement (à la @TuckerWhitehouse ) qui serait compatible avec V2?

METTRE À JOUR:
Bien que je n'ai pas été en mesure de trouver une solution qui _désactiver_ le routage côté client, j'ai pu empêcher la redirection référencée par @ alex-greco-harrys et d'autres en définissant:

window.page = window.page || {};
window.page.path = window.location.pathname;

dans gatsby-browser.js qui court-circuite ce contrôle conditionnel dans production-app.js. Cette redirection conditionnelle tente de «faire correspondre le chemin canonique au chemin réel» et entraîne le comportement inattendu (IMO) référencé ci-dessus.

J'ai aussi besoin de ça.

J'utilise actuellement du code généré par Gatsby sur un autre projet et je l'utilise sur plusieurs pages. J'utilise Gatsby car il génère du code statique. Par conséquent, j'ai utilisé le pathPrefix pour pouvoir tout générer sous un chemin spécifique et le servir. De cette façon, tout y est demandé puis rendu comme un fragment de page. Cependant, je reçois tout le temps des redirections indésirables vers le pathPrefix parce que c'est dans les scripts. Je dois supprimer manuellement la condition mentionnée par @ethagnawl à chaque fois que je construis. J'ai juste essayé sa solution mais cela n'a pas fonctionné pour moi.

J'espère également utiliser Gatsby pour créer une application d'une seule page et je souhaite désactiver complètement le routage. Est-ce que quelqu'un connaît une solution de contournement (à la @TuckerWhitehouse ) qui serait compatible avec V2?

METTRE À JOUR:
Bien que je n'ai pas été en mesure de trouver une solution qui _désactiver_ le routage côté client, j'ai pu empêcher la redirection référencée par @ alex-greco-harrys et d'autres en définissant:

window.page = window.page || {};
window.page.path = window.location.pathname;

dans gatsby-browser.js qui court-circuite ce contrôle conditionnel dans production-app.js. Cette redirection conditionnelle tente de «faire correspondre le chemin canonique au chemin réel» et entraîne le comportement inattendu (IMO) référencé ci-dessus.

@ethagnawl J'ai une sorte de solution hacky pour produire une application d'une seule page qui peut être servie à n'importe quelle URL. Par page unique, j'entends en fait une seule page sans routage du tout.

Si vous regardez l'exemple Gatsby suivant: https://github.com/gatsbyjs/gatsby/tree/master/examples/client-only-paths .

Vous pouvez éditer ce fichier à la ligne 15 pour qu'il ressemble à <Page path="/*" {...props} /> et supprimer la ligne 16. Lorsque vous construisez cette application, n'importe quel chemin aboutira à servir le Page vous avez défini. De là, vous pouvez faire ce Page ce que vous voulez. Maintenant, si vous devez héberger cette page sur un chemin arbitraire, vous ne verrez aucune redirection.

Je n'ai pas pu comprendre comment cette solution pouvait fonctionner avec plusieurs pages dans une application. L'objectif de mon projet était de diffuser une seule page Gatsby (page de destination marketing) à n'importe quelle URL que je souhaite.

Je ne sais pas si cela aide dans votre cas d'utilisation, mais cela peut peut-être alimenter une découverte future!

J'ai pu accomplir cela en suivant les instructions de personnalisation de html.js dans la documentation et en supprimant {this.props.postBodyComponents}

https://www.gatsbyjs.org/docs/custom-html/

Sur la base de l'activation de ce fil, il semble y avoir un nombre non négligeable d'utilisateurs qui souhaitent ce comportement.

Pour réitérer rapidement mon cas d'utilisation: je veux (j'ai fait! ) Utiliser Gatsby comme générateur de _page_ statique - par opposition à un générateur _site_ statique - et parce que la "page" Gatsby est injectée dans une page contenant dont l'URL est hors de mon contrôle et sujet à changement, je ne veux pas que l'application Gatsby _ever_ se moque de l'URL. Hors de la boîte, Gatsby prend en charge _principalement_ ce cas d'utilisation et est un grand plaisir à utiliser, mais il fait certaines hypothèses - encore une fois, en raison de son cas d'utilisation statique standard de _site_ - qui entraînent le besoin de hacks comme ceux mentionnés au dessus de.

Alors, y a-t-il un espoir que la possibilité de désactiver le routage côté client devienne une option de configuration de premier niveau? Je serais heureux de soumettre un PR, mais je ne veux pas y perdre de temps s'il n'y a aucune chance qu'il soit accepté.

Cela semble être une fonctionnalité raisonnable pour ajouter @ethagnawl. Je pense qu'il faudrait un nom très long et odieux comme dangeouslySetInnerHTML pour que les gens soient pleinement conscients de ce qu'ils font car il s'agit d'un cas très spécial.

Mon premier passage à un PR traitant de ce problème peut être trouvé ici . J'apprécierais beaucoup les commentaires des responsables et / ou d'autres utilisateurs qui ont rencontré ce problème.

Merci d'avoir créé aPR @ethagnawl

pouvez-vous me rappeler à nouveau pourquoi ce qui suit ne fonctionnera pas?

// Implement the Gatsby API “onCreatePage”. This is
// called after every page is created.
exports.onCreatePage = ({ page, actions }) => {
  const { createPage } = actions;
  page.matchPath = `${page.path}*`;
  createPage(page);
};

@wardpeet Je suis sûr que cela fonctionnera et ressemble à la solution que j'ai mentionnée ci-dessus . Cependant, ces types de solutions sont difficiles à documenter et potentiellement fragiles (voir la solution proposée par @TuckerWhitehouse qui ne fonctionne plus).

OMI, codifier ce concept vaut la peine car, encore une fois, cela rend la documentation plus simple et cet indicateur pourrait également être utilisé pour faire des optimisations supplémentaires en contournant / noop-ing / etc. fonctionnalité qui n'est pas pertinente lorsque Gatsby est utilisé de cette manière.

De plus, l'utilisation de matchPath nécessite que l'URL du navigateur reflète la page que vous souhaitez afficher, mais cela tombe en panne lorsque vous injectez un site Gatsby dans un emplacement inconnu. (Mon problème initial était d'avoir gatsby derrière un proxy inverse Apache et de ne pas connaître les itinéraires qui entraîneraient le rendu d'une certaine page).

@ethagnawl pensez -vous qu'il serait possible de désactiver le routage au niveau de la page (quelque chose comme page.__disable_client_side_routing__ = true )? Cela résoudrait probablement également le problème initial que j'avais.

pensez-vous qu'il serait possible de désactiver le routage au niveau de la page

Je ne vois pas pourquoi pas? Est-ce que cela s'ajouterait ou remplacerait ma solution proposée? Si c'est le dernier, y a-t-il un avantage à le faire au niveau de la page?

J'ai configuré ce repo :)
https://github.com/wardpeet/gatsby-plugin-static-site

Je ne sais pas si cela fonctionne pour vos cas d'utilisation.
Pour l'instant tu dois faire

git clone https://github.com/wardpeet/gatsby-plugin-static-site
npm install
npm run build
npm link

cd "into your project"
npm link gatsby-plugin-static-site

ajoutez gatsby-plugin-static-site à votre gatsby-config.js

Faites-moi savoir si cela convient à votre cas d'utilisation, je n'ai pas l'intention de le supporter, donc je suis heureux de le transférer: smile:

J'ai mis à jour le dépôt car il y avait quelque chose qui ne va pas dans mon fichier gitignore (merci @ m-allanson). Je l'ai également publié sur npm sous mon propre nom.

donc l'installation peut être faite

npm install --save @wardpeet/gatsby-plugin-static-site

et ajoutez @wardpeet/gatsby-plugin-static-site à gatsby-config.json

Si cela semble bon, je peux ajouter des tests et des options pour désactiver ce comportement pour le développement.

Hiya!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.

Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!

Merci de faire partie de la communauté Gatsby! 💪💜

Je voudrais que cela reste ouvert car il semble qu'il attend un examen

Je ne suis pas sûr que ce ne soit pas périmé, j'ai fait une solution et j'espère avoir des commentaires à ce sujet
https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -470075540

Si personne ne répond, je pense que c'est une bonne idée de fermer celui-ci car il est probablement résolu.

@wardpeet est-il possible avec ce plugin de désactiver conditionnellement le routage côté client?

@wardpeet IIRC, votre solution proposée est la première étape du processus (peut-être, éventuellement) de l'ajout de cette fonctionnalité en tant qu'option de configuration de Gatsby. Donc, ce _sort of_ le fait hors de la bande en ce qui concerne ce problème et Gatsby, mais je pourrais faire valoir que ce problème devrait rester ouvert afin de continuer cette conversation.

@wardpeet le problème initial concernait la désactivation du routage côté client pour des routes spécifiques , @ethagnawl a

Je dois désactiver temporairement le routage côté client pendant que je migre un site sur un ancien CMS vers Gatsby. Je le fais une page à la fois avant de basculer complètement le commutateur vers juste Gatsby.

J'ai essayé le plugin @wardpeet mais il semble ne pas fonctionner.

@brianbento avez-vous une reproduction? si vous pouvez créer un problème sur le repo https://github.com/wardpeet/gatsby-plugin-static-site, je peux jeter un œil à ce qui manque

@wardpeet Je vais voir si je peux obtenir quelque chose. Le problème principal est que votre "correctif" mentionné précédemment (https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment-465497418) ne fonctionne pas lorsque vous utilisez pathPrefix. Il "corrige" toujours l'adresse à ce qui est attendu.

@brianbento Avez-vous essayé la solution que j'ai mentionnée ci-dessus ? Cela a bien fonctionné pour moi sur deux projets différents.

@ethagnawl Je reçois toujours la correction d'URL, puis elle double le préfixe de chemin.

Alors "/" devient "//"après le canonique ne correspond pas.

Peut-être que je l'implémente mal. Avez-vous utilisé le préfixe de chemin pour vos pages? Suis-je censé avoir le plugin de site statique actif?

Avez-vous utilisé le préfixe de chemin pour vos pages?

Oui. J'utilisais également cette branche pour permettre des actifs distants. Donc, c'est _possible_ que la branche a introduit un comportement qui a fait fonctionner le correctif pour moi et pas pour vous.

Cependant, il est plus probable que les dernières versions de Gatsby (je n'ai pas suivi) aient cassé ma «solution», car c'était un hack au départ.

@ethagnawl Super utile! Je vous remercie! Je sais que @DSchau a créé des plugins pour tester la fonctionnalité assetPrefix. Je vais essayer!

Il semble que la solution __disable_client_side_routing__ qui désactiverait la vérification canonique serait super cool. Je serais ravi de travailler dessus et de soumettre un PR s'il est envisagé de fusionner. Avez-vous un soutien pour cette idée ou pensez-vous qu'elle ne rentre pas dans la feuille de route?

@xavivars J'aimerais ça et je trouve ça utile, c'est sûr.

@xavivars J'ai pris une passe à cette fonctionnalité il y a quelque temps, qui a été fermée en faveur de la solution de @wardpeet . Si vous envisagez de revoir cette approche, cela pourrait valoir la peine de jeter un œil à ma tentative.

Merci @ethagnawl ! J'ai jeté un coup d'œil à votre approche et c'est à peu près ce à quoi je pensais.

Je pense que la solution location.href , donc il navigue "côté serveur". Mais je n'ai pas pu le faire fonctionner pour mon cas d'utilisation car la redirection initiale est toujours en cours: mon hypothèse initiale est qu'il y a une sorte d'interaction avec prefixPath qui fait que cette condition est évaluée à true

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/cache-dir/production-app.js#L65

Avez-vous réussi à le faire fonctionner correctement?

Je pourrais peut-être faire plus de travail sur le plugin si quelqu'un peut m'expliquer le problème réel car j'ai un peu oublié ce que je dois résoudre. Peut-être que la plupart de ces problèmes peuvent être résolus par l'option assetPrefix nouvellement fusionnée?

Désolé de ne pas comprendre.

@xavivars

Avez-vous réussi à le faire fonctionner correctement?

Mon hack et le PR soumis fonctionnaient correctement pour mon cas d'utilisation: génération de page unique et statique sans redirection. J'ai abandonné mes relations publiques car l'équipe Gatsby semblait préférer un plugin au lieu d'une option de configuration au niveau de l'application.

Je n'ai jamais essayé le plugin de @wardpeet , car j'avais déjà terminé le projet Gatsby sur

@wardpeet : le assetPrefix ne le corrige pas. J'ai réussi à le faire fonctionner en utilisant à la fois votre plugin (pour, fondamentalement, désactiver la "navigation" côté client en cliquant) et la solution de contournement mentionnée par @ethagnawl il y a quelques mois

https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611

Cette solution de contournement est nécessaire pour désactiver l'événement «navigation» qui se produit onClientEntry . Nous avons corrigé l'ajout d'un hook là-bas et l'application de cette solution de contournement (forçant page.path au chemin réel). Mais je n'ai aucune idée si cela a des effets secondaires, et combien de temps cela prendra-t-il avant que cela cesse de fonctionner (ce n'est pas plus qu'un hack).

Idéalement, je pense que cela devrait être une configuration au niveau de l'application, étant donné le nombre de personnes qui semblent utiliser Gatsby comme "générateur de pages statiques"

@xavivars Avez-vous un lien que vous pouvez partager avec vous?

Pas vraiment, mais c'est à peu près tout:

Ajoutez le plugin statique mentionné précédemment, et dans gastby-browser.js

exports.onClientEntry = () => {
    window.page = window.page || {};
    window.page.path = window.location.pathname;
}

Ce qui suit fonctionne également, bien qu'il repose sur les composants internes de gatsby:

export function onInitialClientRender() {
  window.___navigate = (to, { replace }) => {
    if (replace) {
      window.location.replace(to);
    } else {
      window.location.assign(to);
    }
  };
}

Est-ce que l'utilisation de https://github.com/wardpeet/gatsby-plugin-static-site & assetPrefix fonctionne?

Problème lié qui a fait fonctionner l'exemple, je ne sais pas si c'est ce dont vous avez réellement besoin.
https://github.com/wardpeet/gatsby-plugin-static-site/issues/1#issuecomment -494802726

Pour moi, cela fonctionnait avec les trois choses: site statique du plugin gatsby + assetPrefix + désactivation de "naviguer" comme indiqué ci-dessus

On dirait que j'ai encore du mal à comprendre ce qui est nécessaire ici. Je pourrais simplement résoudre le problème avec gatsby-plugin-static-site & assetPrefix.

@wardpeet Avez-vous un lien vers une démo qui utilise gatsby-plugin-static?

@ethagnawl désolé de vous avoir fait attendre.

J'ai fait une démo:
https://github.com/wardpeet/gatsby-demos/tree/static-asset-prefix

le site est en ligne:
https://zen-wright-33c2d8.netlify.com/

Comme prévu (et anticipé par @TuckerWhitehouse et @ethagnawl), une solution fragile comme celle fournie dans https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611 ne fonctionne plus, en raison d'un changement dans Gatsby 2.9.2, pour plusieurs raisons:

Le premier, résoluble, est que cette ligne
window.page.path = window.location.pathname;
doit être remplacé par
window.pagePath = window.location.pathname;
afin d'éviter le changement du côté client de l'URL.

Mais cela a des effets secondaires indésirables: pagePath est défini avec le chemin _wrong_, et page-data.json n'est plus chargé (car il repose sur le chemin d'origine de la page, et non sur celui où il est finalement rendu)

https://github.com/gatsbyjs/gatsby/commit/49fd769f695ccfa6e990e3eaae7c886f073db19b#diff -2d21ea42ec874a0988977e57b17251aa

Il semble que la seule option pour que cela fonctionne maintenant serait d'introduire réellement une variable comme __disable_client_side_routing__ ou, au moins, __disable_client_side_canonical_redirect__ pour court-circuiter cette condition: https://github.com/gatsbyjs/ gatsby / blob / master / packages / gatsby / répertoire-cache / production-app.js # L69

@wardpeet :

Nous préférons ne pas activer ces trappes d'échappement dans le noyau. Ce que je comprends fondamentalement du problème, c'est ceci:

J'ai un site Gatsby et un chemin / mon-chemin-spécial et sur mon serveur j'ai une route appelée / quelque chose-d'autre. Si je réécris / quelque chose d'autre dans / gatsby / mon-chemin-spécial, cela ne fonctionnera pas car il essaie de changer la page en / mon-chemin-spécial?

Si c'est le cas, je vais voir si je peux le réparer dans mon plugin. Avez-vous peut-être une démo en direct de cela?

Oui, c'est exactement le problème. Je vais essayer de mettre en place un autre PR (qui n'ajoute pas quelque chose d'aussi invasif que la variable de configuration globale comme https://github.com/gatsbyjs/gatsby/pull/15173).

J'ai quelque chose qui peut être acceptable que je vais pousser comme un autre PR dans quelques minutes

@wardpeet c'est ce que je pense qu'il faudra ajouter à Gatsby pour que votre plugin puisse être étendu. J'ai ajouté quelques exemples et documentation sur le PR

https://github.com/gatsbyjs/gatsby/pull/15180

Après une conversation avec @DSchau dans Discord, il semble que les principaux contributeurs s'accordent sur le fait qu'une solution comme # 15173 ou # 15180 ne devrait pas vivre dans le noyau, mais dans un plugin. J'aimerais donc explorer d'autres options pour le résoudre.

Actuellement, le seul moyen que j'ai trouvé était via une variable de configuration globale (# 15173) pour court-circuiter la vérification de redirection canonique, ou en permettant de modifier l'URL rendue perçue pour gatsby (# 15180), de sorte que la vérification de redirection canonique ne dépend pas directement de window.location , mais sur une variable filtrable.

À mon humble avis, le défi est d'utiliser un plugin pour étendre / remplacer quelque chose qui ne semble pas être extensible / remplaçable pour le moment (le fait de compter directement sur window.location sans les valeurs injectées de n'importe où me rend vraiment difficile), mais il peut y avoir d'autres moyens d'implémenter ce comportement sans modifier le code du noyau.

@xavivars Je vais fusionner https://github.com/wardpeet/gatsby-plugin-static-site/pull/4 et publier un correctif pour cela.

Une démo: (la page 5 a une redirection canonique)
https://static-asset-prefix--zen-wright-33c2d8.netlify.com/

Je viens de publier @ wardpeet / gatsby-plugin-static-site version 0.1.0. Cela devrait résoudre ce problème. N'hésitez pas à rouvrir si cela n'a pas résolu tous vos problèmes.

Le meilleur moyen d'obtenir un meilleur support de site statique est de créer un problème au niveau du plugin lui-même. https://github.com/wardpeet/gatsby-plugin-static-site/issues/new

Quelqu'un a-t-il rencontré cela après avoir utilisé le plugin ci-dessus?

Une solution de contournement fonctionnant pour la version actuelle de GatsbyJS?

J'ai essayé:
https://github.com/wardpeet/gatsby-plugin-static-site

mais ça ne marche pas pour moi. J'ai soulevé un problème ici:
https://github.com/wardpeet/gatsby-plugin-static-site/issues/13

J'ai également créé un exemple de dépôt pour reproduire le problème de redirection:
https://github.com/isi-gach/gastby-static/tree/create-react-app

@ isi-gach Pourriez-vous donner votre point de vue sur le problème racine (ce que vous attendez, ce que vous voyez, ce que vous aimeriez voir)? Quelques-uns d'entre nous dans ce fil ont essayé, mais cela pourrait aider à en avoir une nouvelle.

salut @ethagnawl

Je m'attends à ce que l'URL du navigateur ne change pas mais je vois l'URL changer, dans la vidéo suivante, l'URL passe de /demo/index.html à /public/
https://www.youtube.com/watch?v=SxYbaDidnkY

Cette vidéo a été enregistrée à l'aide de l'exemple de dépôt que j'ai créé:
https://github.com/isi-gach/gastby-static/tree/create-react-app

J'essaie d'empêcher la redirection en utilisant @wardpeet/gatsby-plugin-static-site mais ne semble pas fonctionner.

Salut @ isi-gach @ethagnawl ,

Il y a quelques pull requests ouvertes dans le plug-in

Pendant qu'ils sont fusionnés, vous pouvez utiliser ma fourchette à la place

Salut @xavivars
J'ai essayé le npm de votre fourchette et maintenant l'URL ne change pas mais j'ai une page blanche:
https://www.youtube.com/watch?v=uNzk9UYVCxk

Cette vidéo a été enregistrée à l'aide de l'exemple de dépôt suivant en remplaçant le plugin wardpeet par le vôtre:
https://github.com/isi-gach/gastby-static/tree/create-react-app

comment désactiver le routage côté client uniquement pour une seule page?

Vous pouvez utiliser ceci

exports.onPreBootstrap = ({ store }) => {
  const { program } = store.getState()
  const filePath = path.join(program.directory, '.cache', 'production-app.js')

  const code = fs.readFileSync(filePath, {
    encoding: `utf-8`,
  })

  const newCode = code.replace(
    `const { pagePath, location: browserLoc } = window`,
    `const { pagePath } = window
    let { location: browserLoc } = window

    if (window.parent.location !== browserLoc) {
      browserLoc = {
        pathname: pagePath
      }
    }
  `
  )

  fs.writeFileSync(filePath, newCode, `utf-8`)
}

Je ne suis pas sûr qu'il couvre tous les cas d'utilisation couverts par le plugin, mais cela fonctionne bien pour mon cas.