Gatsby: ¿Deshabilitar el enrutamiento del lado del cliente?

¿Por qué no sabe qué rutas está representando el servidor?

Es menos que no conozca las rutas (puedo escribir una expresión regular que las coincida) pero más la superposición. La configuración real está detrás de un servidor apache que invierte los proxies a un montón de aplicaciones diferentes, incluido el sitio gatsby. Si alguna de esas aplicaciones deja de estar disponible o devuelve un error interno del servidor, devolvemos una página de error personalizada que forma parte del sitio de gatsby.

Entonces, en cualquier momento, si app1 no está disponible o se comporta mal, cualquier solicitud a / app1 devolvería el contenido de /error/unavailable.html o /error/internal.html, y lo mismo sería cierto para app2, y así sucesivamente. .

El uso de matchPath como /^(app1|app2)/.*/ , tanto en las páginas de error interno no disponibles como no funciona porque findPage no sabe (según la URL) qué página realmente pretendo para mostrar al usuario.

Pude hacer que algo funcionara usando una variable global y "parcheando" ___history y ___loader en onClientEntry . Es muy frágil debido a la dependencia de gatsby exponiendo esos globales; no estoy seguro de si hay alguna forma de generalizar esto y agregarlo a gatsby.

• El historial de parches captura llamadas usando props.location.pathname
  component-renderer.js # L18-L28

• El cargador de parches detecta el uso directo de window.location.pathname
  producción-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>
)

También estoy de acuerdo en que debería haber una opción de compilación para desactivar esta función. También tenemos una configuración poco convencional y nos gustaría desactivar esta función temporalmente mientras finalizamos nuestra migración a un sitio completo de Gatsby.

Una simple bandera en el momento de la construcción sería perfecta.

¿que tal este? alguna solución para esto?

Terminamos modificando pages.json para que coincida con la ruta que necesitábamos. Básicamente, llamamos addPagesArray con el nombre de ruta corregido.

¿Todavía no entiendo por qué esto arroja un error? La página se carga bien y funciona. Esto como mucho debería ser una advertencia cuando no coincida con la ruta.

Dicho esto, no sé si hay una forma más elegante de modificar el archivo pages.json a través de un código config vs runtime.

Quiero abordar este problema.

Un proyecto en el que estoy trabajando está experimentando un problema similar. Estamos construyendo un generador de página de destino que creará aplicaciones Gatsby de una sola página. Este problema surge cuando intentamos publicar una página de destino fuera de su dominio.

Entonces, por ejemplo, tenemos nuestra aplicación principal de Gatsby www.example.com . Tenemos un servicio que tomará las páginas de destino de Gatsby y las servirá a www.example.com/trial . Entonces, una URL de página de destino se vería como www.example.com/trail/ad-123 La página inicialmente se carga bien hasta que se carga todo el JS y el enrutador se hace cargo. La página de destino mira la ruta y no sabe dónde está, por lo que intenta cambiar la ruta para colocar la página en la raíz, luciendo así www.example.com/ad-123 , lo que da como resultado una redirección 404.

¿Hay planes para agregar una opción configurable para solucionar este problema? ¿El equipo de Gatsby estaría abierto a un PR?

@ alex-greco-harrys Me parece que un prefijo de ruta es lo que querrás usar en ese escenario.

También necesitaba deshabilitar el enrutamiento del lado del cliente para ejecutar Google Adsense correctamente en mi sitio web.

Los anuncios automáticos de Google Adsense no detectan el enrutamiento del lado del cliente y los anuncios no se actualizan cuando se actualizan las rutas.

¿Existe alguna forma de deshabilitar el enrutamiento del lado del cliente?

Puede usar a etiquetas en lugar de gatsby-link en casos como ese

Pude hacer que algo funcionara usando una variable global y "parcheando" ___history y ___loader en onClientEntry . Es muy frágil debido a la dependencia de gatsby exponiendo esos globales; no estoy seguro de si hay alguna forma de generalizar esto y agregarlo a gatsby.

• El historial de parches captura llamadas usando props.location.pathname
  component-renderer.js # L18-L28
• El cargador de parches detecta el uso directo de window.location.pathname
  producción-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 ¿de dónde ___history , ___loader ? Cuando trato de replicar su ejemplo, esas dos propiedades de global son undfined .

@ alex-greco-harrys Me parece que un prefijo de ruta es lo que querrás usar en ese escenario.

@ jgierer12 Eso ayuda a resolver la primera parte de mi problema. La segunda parte es que se desconoce la ruta final hasta que se renderiza la página. Tenemos un servicio de aprendizaje que toma una colección de páginas estáticas y las sirve según las tasas de conversión. Entonces, en una ruta example.com/go/ podríamos estar sirviendo 1 de una colección de páginas. Por lo tanto, no estaríamos sirviendo la página en una ruta como example.com/go/first-page o example.com/go/second-page . Ambos se servirían en la ruta example.com/go/page .

Básicamente, lo que estoy tratando de lograr es servir una página de gatsby en cualquier camino que desee.

@ alex-greco-harrys esos globales fueron expuestos por gatsby v1. Con la actualización a v2, sé que el enrutador subyacente se cambió de react-enrutador a enrutador de alcance, por lo que supongo que esos globales se vieron afectados.

También espero usar Gatsby para crear una aplicación de una sola página y me gustaría deshabilitar el enrutamiento por completo. ¿Alguien sabe de una solución alternativa (a la @TuckerWhitehouse 's) que sería compatible con V2?

ACTUALIZAR:
Si bien no pude encontrar una solución que _deshabilitara_ el enrutamiento del lado del cliente, pude evitar la redirección a la que hacen referencia @ alex-greco-harrys y otros configurando:

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

en gatsby-browser.js que cortocircuita esta verificación condicional en production-app.js. Esa redirección condicional intenta "hacer que la ruta canónica coincida con la ruta real" y da como resultado el comportamiento inesperado (IMO) mencionado anteriormente.

También necesito esto.

Actualmente estoy usando código generado por Gatsby en otro proyecto y lo uso en varias páginas. Estoy usando Gatsby ya que genera código estático. Por lo tanto, usé pathPrefix para poder generar todo en una ruta específica y servirlo. De esa manera, todo se solicita allí y luego se representa como un fragmento de una página. Sin embargo, obtengo redireccionamientos no deseados todo el tiempo al pathPrefix porque está en los scripts. Tengo que eliminar manualmente la condición que @ethagnawl mencionó cada vez que construyo. Solo probé su solución pero no funcionó para mí.

También espero usar Gatsby para crear una aplicación de una sola página y me gustaría deshabilitar el enrutamiento por completo. ¿Alguien sabe de una solución alternativa (a la @TuckerWhitehouse 's) que sería compatible con V2?

ACTUALIZAR:
Si bien no pude encontrar una solución que _deshabilitara_ el enrutamiento del lado del cliente, pude evitar la redirección a la que hacen referencia @ alex-greco-harrys y otros configurando:

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

en gatsby-browser.js que cortocircuita esta verificación condicional en production-app.js. Esa redirección condicional intenta "hacer que la ruta canónica coincida con la ruta real" y da como resultado el comportamiento inesperado (IMO) mencionado anteriormente.

@ethagnawl Tengo una especie de solución hacky para producir una aplicación de una sola página que se puede servir en cualquier URL. Por página única, en realidad me refiero a una sola página sin ningún enrutamiento.

Si observa el siguiente ejemplo de Gatsby: https://github.com/gatsbyjs/gatsby/tree/master/examples/client-only-paths .

Puede editar este archivo en la línea 15 para que se vea como <Page path="/*" {...props} /> y eliminar la línea 16. Cuando cree esta aplicación, cualquier ruta dará como resultado el servicio Page que ha definido. A partir de ahí, puedes hacer que Page lo que quieras. Ahora, si necesita alojar esta página en una ruta arbitraria, no verá ninguna redirección.

No pude averiguar cómo esta solución podría funcionar con varias páginas en una aplicación. El objetivo de mi proyecto era ofrecer una sola página de Gatsby (página de destino de marketing) en cualquier URL que desee.

No estoy seguro de si esto ayuda en su caso de uso, ¡pero tal vez esto pueda impulsar algún descubrimiento futuro!

Pude lograr esto siguiendo las instrucciones de Personalización de html.js en los documentos y eliminando {this.props.postBodyComponents}

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

Según lo activo que siga siendo este hilo, parece que hay un número considerable de usuarios que desean este comportamiento.

Para reiterar rápidamente mi caso de uso: quiero ( ¡hice! ) Usar Gatsby como un generador de _página_ estático, en lugar de un generador de _sitio_ estático, y porque la "página" de Gatsby se inyecta en una página contenedora cuya URL está fuera de mi control y sujeto a cambios, no quiero que la aplicación Gatsby _ nunca_ estropee la URL. Fuera de la caja, Gatsby _ principalmente_ admite este caso de uso y es un gran placer usarlo, pero hace algunas suposiciones, nuevamente, debido a su caso de uso estándar de _site_ estático, que resultan en la necesidad de hacks como los mencionados. encima.

Entonces, ¿hay alguna esperanza de que la capacidad de deshabilitar el enrutamiento del lado del cliente se convierta en una opción de configuración de nivel superior? Me encantaría enviar un PR, pero no quiero perder tiempo en él si no hay posibilidad de que sea aceptado.

Esto parece una característica razonable para agregar @ethagnawl. Creo que necesitaría un nombre muy largo y desagradable como dangerSetInnerHTML para que las personas sean plenamente conscientes de lo que están haciendo, ya que este es un caso extremo muy especial.

Mi primer pase en un PR que aborda este problema se puede encontrar aquí . Agradecería mucho los comentarios de los mantenedores y / o de otros usuarios que se hayan encontrado con este problema.

Gracias por crear aPR @ethagnawl

¿Podrías recordarme de nuevo por qué no funciona lo siguiente?

// 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 Estoy seguro de que funcionará y se verá similar a la solución que mencioné anteriormente . Sin embargo, ese tipo de soluciones son difíciles de documentar y potencialmente frágiles (consulte la solución ofrecida por @TuckerWhitehouse que ya no funciona).

En mi opinión, vale la pena codificar este concepto ya que, nuevamente, hace que la documentación sea más sencilla y esta bandera también podría usarse para realizar optimizaciones adicionales omitiendo / noop-ing / etc. funcionalidad que no es relevante cuando Gatsby se usa de esta manera.

Además, el uso de matchPath requiere que la URL en el navegador refleje la página que desea representar, pero esto se rompe cuando inyecta un sitio gatsby en una ubicación desconocida. (Mi problema original era tener a gatsby detrás de un proxy inverso de apache y no saber las rutas que harían que se renderizara una determinada página).

@ethagnawl , ¿crees que sería posible deshabilitar el enrutamiento a nivel de página (algo así como page.__disable_client_side_routing__ = true )? Esto probablemente también resolvería el problema original que estaba teniendo.

¿Crees que sería posible deshabilitar el enrutamiento a nivel de página?

No veo por qué no ¿Sería eso adicional o en lugar de mi solución propuesta? Si es lo último, ¿hay alguna ventaja en hacerlo a nivel de página?

He configurado este repositorio :)
https://github.com/wardpeet/gatsby-plugin-static-site

No estoy seguro de si esto funciona para sus casos de uso.
Por ahora tienes que hacer

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

agregue gatsby-plugin-static-site a su gatsby-config.js

Avíseme si esto está bien para su caso de uso, no tengo la intención de admitirlo, así que estoy feliz de transferirlo: smile:

Actualicé el repositorio porque tenía algo mal en mi archivo gitignore (gracias @ m-allanson). También lo publiqué en npm con mi propio nombre.

para que la instalación se pueda hacer

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

y agregue @wardpeet/gatsby-plugin-static-site a gatsby-config.json

Si esto se ve bien, puedo agregar algunas pruebas y algunas opciones para deshabilitar este comportamiento para el desarrollo.

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente los cerramos después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.

Si nos perdimos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

Me gustaría que esto permaneciera abierto ya que parece que está esperando una revisión

No estoy seguro de que no esté obsoleto, hice una solución y espero recibir comentarios al respecto.
https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -470075540

Si nadie responde, creo que es una buena idea cerrar este, ya que probablemente esté resuelto.

@wardpeet ¿ es posible con ese complemento deshabilitar condicionalmente el enrutamiento del lado del cliente?

@wardpeet IIRC, su solución propuesta es el primer paso en el proceso de (tal vez, eventualmente) agregar esta característica como una opción de configuración de Gatsby. Por lo tanto, ese _sort of_ sale fuera de banda en lo que respecta a este tema y a Gatsby, pero podría argumentar que este tema debería permanecer abierto para continuar esa conversación.

@wardpeet, el problema original era deshabilitar el enrutamiento del lado del cliente para rutas específicas , @ethagnawl mencionó el caso de uso de deshabilitar el enrutamiento para todo un sitio, que es lo que creo que dirige su complemento.

Necesito deshabilitar el enrutamiento del lado del cliente temporalmente mientras migro un sitio en un CMS antiguo a Gatsby. Lo estoy haciendo una página a la vez antes de cambiar completamente el interruptor a solo Gatsby.

Probé el complemento

@brianbento ¿tienes una reproducción? si puede crear un problema en el repositorio https://github.com/wardpeet/gatsby-plugin-static-site , puedo ver lo que falta

@wardpeet Veré si puedo conseguir algo. El problema principal es que su "corrección" mencionada anteriormente (https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment-465497418) no funciona cuando usa pathPrefix. Siempre "corrige" la dirección a lo esperado.

@brianbento ¿Has probado la solución que mencioné anteriormente ? Eso me ha funcionado bien en dos proyectos diferentes.

@ethagnawl Todavía obtengo la corrección de URL y luego duplica el prefijo de ruta.

Entonces "/"se convierte" //"después de que el canónico no coincide.

Quizás lo estoy implementando mal. ¿Usó el prefijo de ruta para sus páginas? ¿Se supone que debo tener activo el complemento de sitio estático?

¿Usó el prefijo de ruta para sus páginas?

Si. También estaba usando esta rama para permitir activos remotos. Entonces, es _posible_ que la rama haya introducido un comportamiento que hizo que la solución funcionara para mí y no para usted.

Sin embargo, es más probable que los lanzamientos recientes de Gatsby (no he mantenido el ritmo) hayan roto mi "solución", ya que fue un truco para empezar.

@ethagnawl ¡ Súper útil! ¡Gracias! Sé que @DSchau creó algunos complementos para probar la función assetPrefix. ¡Lo intentaré!

Parece que la solución @wardpeet no funciona cuando también necesita usar el prefijo de ruta. Tener una solución como la propuesta __disable_client_side_routing__ que deshabilitara la verificación canónica sería genial. Me complacerá trabajar en él y enviar un PR si se considerará su fusión. ¿Algún apoyo para esa idea, o cree que no encaja en la hoja de ruta?

@xavivars Me gustaría eso y lo encuentro útil, seguro.

@xavivars Aproveché esa función hace un tiempo, que se cerró a favor de la solución de @wardpeet . Si va a considerar revisar ese enfoque, podría valer la pena echarle un vistazo a mi intento.

¡Gracias @ethagnawl ! Eché un vistazo a tu enfoque y eso era más o menos lo que estaba pensando.

Creo que la solución @wardpeet cubre un caso de uso diferente: la aplicación no se comporta como un SPA porque los enlaces en realidad están cambiando el navegador location.href , entonces navega por el "lado del servidor". Pero no pude hacer que funcionara para mi caso de uso porque la redirección inicial todavía está sucediendo: mi hipótesis inicial es que hay algún tipo de interacción con prefixPath que hace que esta condición se evalúe en true

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

¿Conseguiste que funcionara correctamente?

Es posible que pueda trabajar más en el complemento si alguien puede explicarme el problema real, ya que olvidé un poco lo que necesito solucionar. ¿Quizás la mayor parte de esto se pueda resolver con la opción assetPrefix recién fusionada?

Perdón por no entender.

@xavivars

¿Conseguiste que funcionara correctamente?

Tanto mi truco como el PR enviado estaban _funcionando correctamente_ para mi caso de uso: generación de página única y estática sin redireccionamientos. Renuncié a mi PR porque el equipo de Gatsby parecía preferir un complemento en lugar de una opción de configuración a nivel de aplicación.

Nunca llegué a probar el complemento de

@wardpeet : el assetPrefix no lo corrige. Logré tener que trabajar utilizando tanto su plugin (que, básicamente, deshabilitar el lado del cliente "navegación" al hacer clic en torno) y la solución mencionada por @ethagnawl hace unos meses

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

Esa solución es necesaria para deshabilitar el evento "navegar" que ocurre onClientEntry . Arreglamos agregar un gancho allí y aplicar esa solución alternativa (forzando page.path a la ruta real). Pero no tengo idea si eso tiene algún efecto secundario, y también cuánto tiempo pasará hasta que deje de funcionar (no es más que un truco).

Idealmente, creo que esta debería ser una configuración a nivel de aplicación, dada la cantidad de personas que parece estar usando gatsby como "generador de páginas estáticas"

@xavivars ¿Tiene un enlace que pueda compartir con su trabajo?

En realidad no, pero esto es todo:

Agregue el complemento estático mencionado anteriormente y en gastby-browser.js

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

Lo siguiente también funciona, aunque se basa en los componentes internos de gatsby:

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

¿Funciona el uso de https://github.com/wardpeet/gatsby-plugin-static-site & assetPrefix?

Problema vinculado que hizo que el ejemplo funcionara, no estoy seguro de si esto es lo que realmente necesita.
https://github.com/wardpeet/gatsby-plugin-static-site/issues/1#issuecomment -494802726

Para mí, funcionó con las tres cosas: sitio estático del complemento gatsby + assetPrefix + deshabilitar "navegar" como se muestra arriba

Parece que todavía me cuesta entender qué se necesita aquí. Podría solucionar el problema con gatsby-plugin-static-site & assetPrefix.

@wardpeet ¿Tiene un enlace a una demostración que usa gatsby-plugin-static?

@ethagnawl siento haberte hecho esperar.

Hice una demostración:
https://github.com/wardpeet/gatsby-demos/tree/static-asset-prefix

el sitio está en vivo:
https://zen-wright-33c2d8.netlify.com/

Como se esperaba (y anticipado por @TuckerWhitehouse y @ethagnawl), una solución frágil como la proporcionada en https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611 ya no funciona, debido a un cambio en Gatsby 2.9.2, por varias razones:

La primera, solucionable, es que esta línea
window.page.path = window.location.pathname;
necesita ser reemplazado con
window.pagePath = window.location.pathname;
para evitar el cambio en el lado del cliente URL.

Pero eso tiene efectos secundarios no deseados: pagePath se establece con la ruta _wrong_, y page-data.json ya no se carga (ya que se basa en la ruta original de la página, y no en la que finalmente se representa)

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

Parece que la única opción para hacer que esto funcione ahora sería introducir realmente una variable como __disable_client_side_routing__ o, al menos, __disable_client_side_canonical_redirect__ para acortar esta condición: https://github.com/gatsbyjs/ gatsby / blob / master / packages / gatsby / cache-dir / production-app.js # L69

@wardpeet : ¿ve algún problema al introducir dicha variable de configuración?

Preferimos no habilitar estas trampillas de escape en el núcleo. Lo que básicamente entiendo del problema es esto:

Tengo un sitio gatsby y una ruta / my-special-path y en mi servidor tengo una ruta llamada / something-else. Si reescribo / algo más en / gatsby / my-special-path, no funcionará porque intenta cambiar la página a / my-special-path?

Si es así, veré si puedo solucionarlo en mi complemento. ¿Quizás tienes una demostración en vivo de esto?

Sí, ese es exactamente el problema. Intentaré armar otro PR (que no agrega algo tan invasivo como la variable de configuración global como https://github.com/gatsbyjs/gatsby/pull/15173).

Tengo algo que puede ser aceptable que impulsaré como otro RP en unos minutos.

@wardpeet esto es lo que creo que sería necesario agregar a Gatsby para que su complemento pueda extenderse. He añadido algunos ejemplos y documentación sobre las relaciones públicas.

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

Después de una conversación con @DSchau en Discord, parece que los colaboradores principales están alineados con que una solución como # 15173 o # 15180 no debería vivir en el núcleo, sino en un complemento. Entonces me gustaría explorar otras opciones para resolverlo.

Actualmente, las únicas formas que encontré fue a través de una variable de configuración global (# 15173) para cortocircuitar la verificación de redirección canónica, o permitiendo modificar la URL renderizada percibida para gatsby (# 15180), por lo que la verificación de redirección canónica no depende directamente window.location , pero en una variable filtrable.

En mi humilde opinión, el desafío es usar un complemento para extender / anular algo que no parece ser extensible / anulable en este momento (depender directamente de window.location sin los valores inyectados desde cualquier lugar lo hace realmente difícil para mí), pero puede haber otras formas de implementar este comportamiento sin modificar el código del núcleo.

@xavivars Fusionaré https://github.com/wardpeet/gatsby-plugin-static-site/pull/4 y publicaré una solución para esto.

Una demostración: (la página 5 tiene un redireccionamiento canónico)
https://static-asset-prefix--zen-wright-33c2d8.netlify.com/

Acabo de publicar @ wardpeet / gatsby-plugin-static-site versión 0.1.0. Esto debería solucionar este problema. No dude en volver a abrir si no solucionó todos sus problemas.

La mejor manera de obtener un mejor soporte para sitios estáticos es crear un problema en el propio complemento. https://github.com/wardpeet/gatsby-plugin-static-site/issues/new

¿Alguien encontró esto después de usar el complemento anterior?

¿Alguna solución que funcione para la versión actual de GatsbyJS?

Lo intenté:
https://github.com/wardpeet/gatsby-plugin-static-site

pero no funciona para mí. Planteé un problema aquí:
https://github.com/wardpeet/gatsby-plugin-static-site/issues/13

También creé un repositorio de muestra para reproducir el problema de redireccionamiento:
https://github.com/isi-gach/gastby-static/tree/create-react-app

@ isi-gach ¿Le importaría dar su opinión sobre la raíz del problema (lo que espera, lo que está viendo, lo que le gustaría ver)? Algunos de los que estamos en este hilo lo hemos intentado, pero podría ser de ayuda tener una nueva perspectiva.

hola @ethagnawl

Espero que la URL del navegador no cambie, pero veo que la URL cambia, en el siguiente video, la URL cambia de /demo/index.html a /public/
https://www.youtube.com/watch?v=SxYbaDidnkY

Ese video fue grabado usando el repositorio de muestra que he creado:
https://github.com/isi-gach/gastby-static/tree/create-react-app

Estoy tratando de evitar la redirección usando @wardpeet/gatsby-plugin-static-site pero parece que no funciona.

Hola @ isi-gach @ethagnawl ,

Hay un par de solicitudes de extracción abiertas en el complemento @wardpeet que deberían resolver el problema que está mencionando.

Mientras se fusionan, puedes usar mi tenedor en su lugar

Hola @xavivars
Probé el npm de su bifurcación y ahora la URL no cambia, pero tengo una página en blanco:
https://www.youtube.com/watch?v=uNzk9UYVCxk

Ese video fue grabado usando el siguiente repositorio de muestra reemplazando el complemento wardpeet por el suyo:
https://github.com/isi-gach/gastby-static/tree/create-react-app

¿Cómo desactivo el enrutamiento del lado del cliente solo para una sola página?

Puedes usar esto

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`)
}

No estoy seguro de si cubre todos los casos de uso que cubre el complemento, pero funciona bien para mi caso.