Gatsby: Desativar o roteamento do lado do cliente?

Por que você não sabe quais caminhos o servidor está renderizando?

É menos que eu não conheça os caminhos (posso escrever uma regex que irá corresponder a eles), mas mais a sobreposição. A configuração real está por trás de um servidor apache que reverte proxies para um monte de aplicativos diferentes, incluindo o site gatsby. Se algum desses aplicativos ficar indisponível ou retornar um erro interno do servidor, retornamos uma página de erro personalizada que faz parte do site do gatsby.

Portanto, a qualquer momento, se app1 não estiver disponível ou se comportar mal, qualquer solicitação para / app1 retornará o conteúdo de /error/unavailable.html ou /error/internal.html, e o mesmo será verdadeiro para app2 e assim por diante .

Usar um matchPath como /^(app1|app2)/.*/ , em ambas as páginas de erro interno indisponíveis não funciona porque findPage não sabe (com base no url) qual página eu realmente pretendo para mostrar ao usuário.

Consegui fazer algo funcionar usando uma variável global e "patching" ___history e ___loader em onClientEntry . É muito frágil por causa da dependência do gats ao expor esses globais - não tenho certeza se há alguma maneira de generalizar isso e adicioná-lo ao gatsby.

• O patch de histórico captura chamadas usando props.location.pathname
  component-renderer.js # L18-L28

• O carregador de patch captura o uso direto 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>
)

Também concordo que deve haver uma opção de construção para desativar esse recurso. Também temos uma configuração não convencional e gostaríamos de desativar esse recurso temporariamente enquanto concluímos nossa migração para um site Gatsby completo.

Um sinalizador simples no momento da construção seria perfeito.

Que tal este? alguma solução para isso?

Acabamos modificando o pages.json para corresponder ao caminho que precisávamos. Basicamente, chamamos addPagesArray com o nome do caminho corrigido.

Ainda não entendo por que isso gera um erro. A página carrega bem e funciona. Isso deve ser, no máximo, um aviso quando não corresponder ao caminho.

Dito isso, não sei se existe uma maneira mais elegante de modificar o pages.json através de um código config vs runtime.

Eu quero resolver esse problema.

Um projeto no qual estou trabalhando está enfrentando um problema semelhante. Estamos construindo um gerador de landing page que irá construir aplicativos Gatsby de página única. Esse problema surge quando tentamos veicular uma página de destino fora de seu domínio.

Portanto, por exemplo, temos nosso aplicativo principal de Gatsby www.example.com . Temos um serviço que pegará as páginas de destino de Gatsby e as veiculará em www.example.com/trial . Portanto, um URL de página de destino seria semelhante a www.example.com/trail/ad-123 A página carrega inicialmente bem até que todo o JS carregue e o roteador assuma. A página de destino analisa o caminho e não sabe onde está, então tenta mudar o caminho para colocar a página na raiz, parecido com www.example.com/ad-123 , o que resulta em um redirecionamento 404.

Existem planos para adicionar uma opção configurável para corrigir isso? A equipe de Gatsby estaria aberta a um RP?

@ alex-greco-harrys Parece-me que um prefixo de caminho é o que você deseja usar nesse cenário.

Também precisei desabilitar o roteamento do lado do cliente para executar o Google Adsense corretamente em meu site.

Os anúncios automáticos do Google Adsense não detectam o roteamento do lado do cliente e os anúncios não são atualizados quando as rotas são atualizadas.

Existe alguma maneira de desabilitar o roteamento do lado do cliente?

Você pode usar tags a vez de gatsby-link em casos como esse

Consegui fazer algo funcionar usando uma variável global e "patching" ___history e ___loader em onClientEntry . É muito frágil por causa da dependência do gats ao expor esses globais - não tenho certeza se há alguma maneira de generalizar isso e adicioná-lo ao gatsby.

• O patch de histórico captura chamadas usando props.location.pathname
  component-renderer.js # L18-L28
• O carregador de patch captura o uso direto 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 de onde você está obtendo ___history , ___loader ? Quando tento replicar seu exemplo, essas duas propriedades de global são undfined .

@ alex-greco-harrys Parece-me que um prefixo de caminho é o que você deseja usar nesse cenário.

@ jgierer12 Isso ajuda a resolver a primeira parte do meu problema. A segunda parte é que o caminho final é desconhecido até que a página seja renderizada. Temos um serviço de aprendizado que pega uma coleção de páginas estáticas e as exibe com base nas taxas de conversão. Portanto, em um caminho example.com/go/ , poderíamos estar servindo 1 de uma coleção de páginas. Portanto, não serviríamos a página em um caminho como example.com/go/first-page ou example.com/go/second-page . Ambos seriam servidos no caminho example.com/go/page .

Essencialmente, o que estou tentando realizar é servir uma página gatsby em qualquer caminho que eu quiser.

@ alex-greco-harrys esses globais foram expostos por gatsby v1. Com a atualização para v2, sei que o roteador subjacente foi trocado de react-router para reach-router, então acho que esses globais foram afetados.

Também espero usar Gatsby para construir um aplicativo de página única e gostaria de desativar totalmente o roteamento. Alguém sabe de uma solução alternativa (a la @TuckerWhitehouse ) que seria compatível com V2?

ATUALIZAR:
Embora eu não tenha conseguido encontrar uma solução que _desativaria_ o roteamento do lado do cliente, consegui evitar o redirecionamento referenciado por @ alex-greco-harrys e outros definindo:

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

em gatsby-browser.js que causa um curto-circuito nesta verificação condicional em production-app.js. Esse redirecionamento condicional tenta "fazer com que o caminho canônico corresponda ao caminho real" e resulta no comportamento inesperado (IMO) mencionado acima.

Eu também preciso disso.

Atualmente, estou usando código gerado por Gatsby em outro projeto e em várias páginas. Estou usando o Gatsby, pois ele gera código estático. Portanto, usei o pathPrefix para que pudesse gerar tudo sob um caminho específico e disponibilizá-lo. Dessa forma, tudo é solicitado lá e, em seguida, processado como um fragmento de uma página. No entanto, recebo redirecionamentos indesejados o tempo todo para pathPrefix porque está nos scripts. Tenho que remover manualmente a condição que @ethagnawl mencionou toda vez que eu crio. Eu apenas tentei sua solução, mas não funcionou para mim.

Também espero usar Gatsby para construir um aplicativo de página única e gostaria de desativar totalmente o roteamento. Alguém sabe de uma solução alternativa (a la @TuckerWhitehouse ) que seria compatível com V2?

ATUALIZAR:
Embora eu não tenha conseguido encontrar uma solução que _desativaria_ o roteamento do lado do cliente, consegui evitar o redirecionamento referenciado por @ alex-greco-harrys e outros definindo:

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

em gatsby-browser.js que causa um curto-circuito nesta verificação condicional em production-app.js. Esse redirecionamento condicional tenta "fazer com que o caminho canônico corresponda ao caminho real" e resulta no comportamento inesperado (IMO) mencionado acima.

@ethagnawl Eu tenho um tipo de solução hacky para produzir um aplicativo de página única que pode ser servido em qualquer URL. Por página única, na verdade, quero dizer uma única página sem roteamento.

Se você olhar o seguinte exemplo de Gatsby: https://github.com/gatsbyjs/gatsby/tree/master/examples/client-only-paths .

Você pode editar este arquivo na linha 15 para se parecer com <Page path="/*" {...props} /> e excluir a linha 16. Ao construir este aplicativo, qualquer caminho resultará em servir o Page você definiu. A partir daí, você pode tornar Page o que quiser. Agora, se você precisar hospedar esta página em um caminho arbitrário, não verá nenhum redirecionamento.

Não consegui descobrir como essa solução poderia funcionar com várias páginas em um aplicativo. O objetivo do meu projeto era servir uma única página Gatsby (página de marketing) em qualquer URL que eu desejasse.

Não tenho certeza se isso ajuda no seu caso de uso, mas talvez isso possa alimentar alguma descoberta futura!

Consegui fazer isso seguindo as instruções de Personalização de html.js nos documentos e removendo {this.props.postBodyComponents}

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

Com base em quão ativo este tópico continua a ser, parece haver um número incomum de usuários que desejam este comportamento.

Para reiterar rapidamente meu caso de uso: Eu quero ( fiz! ) Usar Gatsby como um gerador de _página_ estática - em oposição a um gerador de _site_ estático - e porque a "página" de Gatsby é injetada em uma página contendo cujo URL está fora de meu controle e sujeito a alterações, não quero que o aplicativo Gatsby _ever_ mexe com a URL. Fora da caixa, Gatsby _principalmente_ suporta este caso de uso e é um grande prazer de usar, mas faz algumas suposições - novamente, por causa de seu caso de uso _site_ estático padrão - que resultam na necessidade de hacks como os mencionados acima.

Portanto, há alguma esperança de que a capacidade de desativar o roteamento do lado do cliente se torne uma opção de configuração de nível superior? Eu ficaria feliz em enviar um PR, mas não quero perder tempo nisso se não houver chance de ele ser aceito.

Este parece ser um recurso razoável para adicionar @ethagnawl. Acho que seria necessário um nome muito longo e desagradável como dangeouslySetInnerHTML para que as pessoas estivessem totalmente conscientes do que estão fazendo, pois esse é um caso muito especial.

Minha primeira passagem em um PR abordando esse problema pode ser encontrada aqui . Eu aprecio muito o feedback dos mantenedores e / ou outros usuários que se depararam com esse problema.

Obrigado por criar aPR @ethagnawl

você poderia me lembrar novamente por que o seguinte não funciona?

// 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 Tenho certeza de que funcionará e é semelhante à solução que mencionei acima . No entanto, esse tipo de solução é difícil de documentar e potencialmente frágil (veja a solução oferecida por @TuckerWhitehouse que não funciona mais).

IMO, codificar este conceito vale a pena, pois, novamente, torna a documentação mais direta e este sinalizador também pode ser usado para fazer otimizações adicionais ignorando / noop-ing / etc. funcionalidade que não é relevante quando Gatsby está sendo usado dessa maneira.

Além disso, o uso de matchPath requer que o url no navegador reflita a página que você deseja renderizar, mas isso falha quando você injeta um site gatsby em um local desconhecido. (Meu problema original era ter gatsby atrás de um proxy reverso apache e não saber as rotas que fariam com que uma determinada página fosse renderizada).

@ethagnawl você acha que seria possível desativar o roteamento no nível da página (algo como page.__disable_client_side_routing__ = true )? Isso provavelmente resolveria o problema original que eu estava tendo também.

você acha que seria possível desativar o roteamento no nível da página

Não vejo porque não Isso seria adicional ou no lugar da minha solução proposta? Se for o último, há alguma vantagem em fazer isso no nível da página?

Eu configurei este repo :)
https://github.com/wardpeet/gatsby-plugin-static-site

não tenho certeza se isso funciona para seus casos de uso.
Por enquanto você precisa fazer

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

adicione gatsby-plugin-static-site ao seu gatsby-config.js

Deixe-me saber se isso está correto para o seu caso de uso, não tenho nenhuma intenção de oferecer suporte, então estou feliz em transferi-lo: sorriso:

Atualizei o repo porque havia algo errado no meu arquivo gitignore (obrigado @ m-allanson). Eu também publiquei no npm com meu próprio nome.

então a instalação pode ser feita

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

e adicione @wardpeet/gatsby-plugin-static-site a gatsby-config.json

Se isso estiver bom, posso adicionar alguns testes e algumas opções para desativar esse comportamento para desenvolvimento.

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Temos muitos problemas, então atualmente fechamos os problemas após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.

Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Eu gostaria que isso ficasse aberto, pois parece que está esperando uma revisão

Não tenho certeza se não está desatualizado, fiz uma correção e espero obter feedback sobre isso
https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -470075540

Se ninguém responder, acho uma boa ideia fechar este, pois provavelmente está resolvido.

@wardpeet, é possível com esse plugin desabilitar condicionalmente o roteamento do lado do cliente?

@wardpeet IIRC , sua proposta de correção é a primeira etapa no processo de (talvez, eventualmente) adicionar esse recurso como uma opção de configuração de Gatsby. Então, esse _tipo de_ sai fora da faixa no que diz respeito a este assunto e Gatsby, mas eu posso argumentar que este assunto deve permanecer aberto para continuar essa conversa.

@wardpeet o problema original era desabilitar o roteamento do lado do cliente para rotas específicas , @ethagnawl trouxe o caso de uso de desabilitar o roteamento para um site inteiro, que acredito ser o endereço do seu plugin.

Preciso desabilitar o roteamento do lado do cliente temporariamente enquanto migro um site em um CMS antigo para Gatsby. Estou fazendo uma página de cada vez antes de mudar completamente para apenas gatsby.

Tentei o plugin @wardpeet, mas parece não estar funcionando.

@brianbento você tem uma reprodução? se você pode criar um problema no repo https://github.com/wardpeet/gatsby-plugin-static-site , posso dar uma olhada no que está faltando

@wardpeet , vou ver se consigo arranjar algo. O principal problema é que sua "correção" mencionada anteriormente (https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment-465497418) não funciona quando você usa pathPrefix. Ele sempre "corrige" o endereço para o que é esperado.

@brianbento Você já tentou a solução que mencionei acima ? Isso funcionou bem para mim em dois projetos diferentes.

@ethagnawl Ainda consigo a correção de URL e, em seguida, dobra o prefixo do caminho.

Então "/" torna-se "//"depois que o canônico não corresponder.

Talvez eu esteja implementando errado. Você usou prefixo de caminho para suas páginas? Devo ter o plugin de site estático ativo?

Você usou prefixo de caminho para suas páginas?

Sim. Eu também estava usando esta filial para permitir ativos remotos. Então, é _possível_ que o branch introduziu um comportamento que fez a correção funcionar para mim e não para você.

No entanto, é mais provável que os lançamentos recentes do Gatsby (eu não acompanhei) quebraram minha "solução", já que era um hack para começar.

@ethagnawl Super útil! Obrigado! Eu sei que @DSchau fez alguns plug-ins para testar o recurso assetPrefix. Vou tentar!

Parece que a solução @wardpeet não funciona quando você também precisa usar o prefixo do caminho. Ter uma solução como a proposta __disable_client_side_routing__ que desabilitou a verificação canônica seria muito legal. Eu ficaria feliz em trabalhar nisso e enviar um PR se for considerado para fusão. Algum suporte para essa ideia, ou você acha que ela não se encaixa no roadmap?

@xavivars Eu gostaria e acho útil, com certeza.

@xavivars Eu ignorei esse recurso um tempo atrás, que foi fechado em favor de qual seria a solução de

Obrigado @ethagnawl ! Dei uma olhada em sua abordagem e era exatamente isso que eu estava pensando.

Acho que a solução @wardpeet cobre um caso de uso diferente: o aplicativo não se comporta como um SPA porque os links estão na verdade mudando o navegador location.href , então ele navega "lado do servidor". Mas eu não consegui fazer funcionar para meu caso de uso porque o redirecionamento inicial ainda está acontecendo: minha hipótese inicial é que há algum tipo de interação com prefixPath que faz com que essa condição seja avaliada como true

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

Você conseguiu fazer funcionar corretamente?

Eu poderei trabalhar mais no plug-in se alguém puder me explicar o problema real, já que meio que esqueci o que preciso consertar. Talvez a maior parte disso possa ser resolvido pela opção assetPrefix recém-fundida?

Desculpe por não entender.

@xavivars

Você conseguiu fazer funcionar corretamente?

Tanto meu hack quanto o PR enviado estavam _funcionando corretamente_ para o meu caso de uso: geração de página estática única sem redirecionamentos. Desisti do meu PR porque a equipe de Gatsby parecia preferir um plugin em vez de uma opção de configuração no nível do aplicativo.

Nunca tentei o plugin do finalizado o projeto Gatsby em que estava trabalhando quando foi publicado. Portanto, não posso comentar se isso funcionou ou não _funcionando corretamente_.

@wardpeet : o assetPrefix não corrige isso. Consegui fazê-lo funcionar usando tanto o seu plugin (para, basicamente, desativar a "navegação" do lado do cliente ao clicar) e a solução alternativa mencionada por @ethagnawl alguns meses atrás

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

Essa solução alternativa é necessária para desativar o evento "navegar" que acontece onClientEntry . Corrigimos adicionar um gancho lá e aplicar essa solução alternativa (forçando page.path para o caminho real). Mas eu não tenho ideia se isso tem algum efeito colateral, e também quanto tempo vai demorar até que pare de funcionar (não é mais do que um hack).

Idealmente, acho que esta deve ser uma configuração de nível de aplicativo, dada a quantidade de pessoas que parece estar usando o gatsby como um "gerador de página estática"

@xavivars Você tem um link para compartilhar com você?

Na verdade não, mas é basicamente isso:

Adicione o plug-in estático mencionado antes e em gastby-browser.js

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

O seguinte também funciona, embora dependa de componentes internos do gatsby:

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

O uso de https://github.com/wardpeet/gatsby-plugin-static-site & assetPrefix funciona?

Problema vinculado que fez o exemplo funcionar, não tenho certeza se é isso que você realmente precisa.
https://github.com/wardpeet/gatsby-plugin-static-site/issues/1#issuecomment -494802726

Para mim, funcionou com todas as três coisas: site estático do plugin gatsby + assetPrefix + desabilitação de "navegar" como mostrado acima

Parece que ainda tenho dificuldade em entender o que é necessário aqui. Eu poderia simplesmente corrigir o problema com gatsby-plugin-static-site & assetPrefix.

@wardpeet Você tem um link para uma demonstração que usa gatsby-plugin-static?

@ethagnawl desculpe por mantê-lo esperando.

Eu fiz uma demonstração:
https://github.com/wardpeet/gatsby-demos/tree/static-asset-prefix

site está ativo:
https://zen-wright-33c2d8.netlify.com/

Como esperado (e antecipado por @TuckerWhitehouse e @ethagnawl), uma solução frágil como a fornecida em https://github.com/gatsbyjs/gatsby/issues/4337#issuecomment -453244611 não funciona mais, devido a uma mudança em Gatsby 2.9.2, por vários motivos:

O primeiro, solucionável, é que esta linha
window.page.path = window.location.pathname;
precisa ser substituído por
window.pagePath = window.location.pathname;
a fim de evitar a mudança no lado do cliente URL.

Mas isso tem efeitos colaterais indesejados: pagePath é definido com o caminho _wrong_ e page-data.json não é mais carregado (pois depende do caminho original da página, e não daquele onde finalmente foi renderizado)

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

Parece que a única opção para fazer isso funcionar agora seria realmente introduzir uma variável como __disable_client_side_routing__ ou, pelo menos, __disable_client_side_canonical_redirect__ para encurtar esta condição: https://github.com/gatsbyjs/ gatsby / blob / master / packages / gatsby / cache-dir / production-app.js # L69

@wardpeet : você vê algum problema em introduzir tal variável de configuração?

Preferimos não permitir essas escotilhas de escape no núcleo. O que eu basicamente entendo sobre o problema é o seguinte:

Eu tenho um site gatsby e um caminho / meu-caminho-especial e no meu servidor tenho uma rota chamada / outra coisa. Se eu reescrever / algo diferente em / gatsby / my-special-path, não funcionará porque tenta alterar a página para / my-special-path?

Se sim, verei se consigo consertar no meu plugin. Você tem uma demonstração ao vivo disso?

Sim, esse é exatamente o problema. Vou tentar montar outro PR (que não adiciona algo tão invasivo como a variável de configuração global como https://github.com/gatsbyjs/gatsby/pull/15173).

Tenho algo que pode ser aceitável que irei promover como outro RP em alguns minutos

@wardpeet isso é o que eu acho que seria necessário adicionar ao Gatsby para que seu plugin pudesse ser estendido. Eu adicionei alguns exemplos e documentação sobre o PR

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

Depois de uma conversa com @DSchau no Discord, parece que os contribuidores principais

Atualmente, a única maneira que encontrei foi por meio de uma variável de configuração global (# 15173) para criar um curto-circuito na verificação de redirecionamento canônico ou permitindo modificar a URL renderizada percebida para gatsby (# 15180), de modo que a verificação de redirecionamento canônico não depende diretamente de window.location , mas em uma variável filtrável.

IMHO, o desafio é usar um plug-in para estender / substituir algo que não parece ser extensível / substituível agora (depender diretamente de window.location sem os valores injetados de qualquer lugar torna isso muito difícil para mim), mas pode haver outras maneiras de implementar esse comportamento sem modificar o código do núcleo.

@xavivars Vou mesclar https://github.com/wardpeet/gatsby-plugin-static-site/pull/4 e publicar uma correção para isso.

Uma demonstração: (a página 5 tem um redirecionamento canônico)
https://static-asset-prefix--zen-wright-33c2d8.netlify.com/

Acabei de publicar @ wardpeet / gatsby-plugin-static-site versão 0.1.0. Isso deve resolver o problema. Sinta-se à vontade para reabrir se isso não resolver todos os seus problemas.

A melhor maneira de obter melhor suporte de site estático é criar um problema no próprio plug-in. https://github.com/wardpeet/gatsby-plugin-static-site/issues/new

Alguém encontrou isso depois de usar o plugin acima?

Alguma solução alternativa está funcionando para a versão atual do GatsbyJS?

Eu tentei:
https://github.com/wardpeet/gatsby-plugin-static-site

mas não está funcionando para mim. Eu levantei um problema aqui:
https://github.com/wardpeet/gatsby-plugin-static-site/issues/13

Também criei um repositório de amostra para reproduzir o problema de redirecionamento:
https://github.com/isi-gach/gastby-static/tree/create-react-app

@ isi-gach Você se importaria de fornecer sua opinião sobre a raiz do problema (o que você está esperando, o que está vendo, o que gostaria de ver)? Alguns de nós neste tópico tentaram, mas pode ajudar a obter uma nova abordagem sobre ele.

oi @ethagnawl

Estou esperando que o URL do navegador não mude, mas estou vendo o URL mudando. No vídeo a seguir, o URL muda de /demo/index.html para /public/
https://www.youtube.com/watch?v=SxYbaDidnkY

Esse vídeo foi gravado usando o repositório de amostra que criei:
https://github.com/isi-gach/gastby-static/tree/create-react-app

Estou tentando evitar o redirecionamento usando @wardpeet/gatsby-plugin-static-site mas não parece funcionar.

Olá @ isi-gach @ethagnawl ,

Existem algumas solicitações pull abertas no plug-in @wardpeet que devem resolver o problema que você está mencionando.

Enquanto eles são mesclados, você pode usar meu fork

Olá @xavivars
Tentei npm do seu fork e agora o URL não muda, mas recebi uma página em branco:
https://www.youtube.com/watch?v=uNzk9UYVCxk

Esse vídeo foi gravado usando o seguinte repositório de amostra, substituindo o wardpeet por plug-in pelo seu:
https://github.com/isi-gach/gastby-static/tree/create-react-app

como faço para desativar o roteamento do lado do cliente apenas para uma única página?

Você pode usar isso

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

Não tenho certeza se cobre todos os casos de uso que o plug-in cobre, mas funciona bem para o meu caso.